From owner-ietf-mxcomp@mail.imc.org Sun Aug 1 02:53: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 CAA25541 for ; Sun, 1 Aug 2004 02:53: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 i716YTO2063429; Sat, 31 Jul 2004 23:34:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i716YTHI063428; Sat, 31 Jul 2004 23:34:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i716YRof063408 for ; Sat, 31 Jul 2004 23:34:27 -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 2D9AD4149D; Sat, 31 Jul 2004 23:34:27 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 31 Jul 2004 23:34:27 -0700 (PDT) Message-ID: <1246.64.142.13.68.1091342067.squirrel@harry.mail-abuse.org> In-Reply-To: <42F983F9-E359-11D8-BB8D-000A95B3BA44@hxr.us> 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> <42F983F9-E359-11D8-BB8D-000A95B3BA44@hxr.us> Date: Sat, 31 Jul 2004 23:34:27 -0700 (PDT) Subject: Re: Is the back door open? From: "Douglas Otis" To: "Andrew Newton" Cc: "IETF MARID WG" , "Michel Bouissou" 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 Andrew Newton wrote: > 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 some providers force others to publish SPF records by rejecting mail without them, then both normal and spoofing access to SPF records would raise the loads on DNS. These records would likely be "open" records. Eventually a solution of placing a Resent-From header into outbound mail could be a defensive strategy as a means to "close" the record to curtail DNS abuses. If not done in this manner, there would be massive support calls, as normal mail practices would otherwise cease functioning. I would regard this as an eventual consequences, where what may have seemed to be a small percentage of list traffic, now becomes the norm. PRA becomes little more than a channel identifier using a rather complex method to authenticate it. > 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? The SPF record would change to only require a list of EHLO domains, if to limit the allowed use the RFC2821 MAIL FROM and RFC2822 From domains. These lists could use a wildcards. If there were no record discovered, then there would be no restriction. If there was a record, then only these EHLO domains for the specific fields would be allowed. The record could look something like "marid_1 rf=*.my-domain.com;" CSV-CSA would remain an efficient means of publishing an MTA hostname client authentication and authorization, that would also be difficult to abuse. By visibly exposing an authenticated EHLO domain, together with the From field, users would be able to recognize normal channels used by various individuals making identity spoofing difficult, but adaptable. Users could then easily white-list these identities and be wary of changes in channel use. This would greatly reduce complexities of SPF, while still allowing the same feature set, for those wishing to impose external domain restrictions. From the perspective of the user, the results would be extremely similar to the scenario described as a provider's defensive strategy. One major benefit to this approach would be the ability to accredit based upon this (New Sender-ID) identity, as it would be the entity granting access, and it would also indicate where a log could be obtained to review any claims of abuse. This would also be far less disruptive to mail use and practices and, of course, related software. It would also allow a reduction in the amount of spam and increase network protections. It would be a win-win-when solution. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Sun Aug 1 23:23: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 XAA25235 for ; Sun, 1 Aug 2004 23:23: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 i7237KSq099691; Sun, 1 Aug 2004 20:07: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 i7237Khh099690; Sun, 1 Aug 2004 20:07:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7237JEY099681 for ; Sun, 1 Aug 2004 20:07:19 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7237LDv023566 for ; Sun, 1 Aug 2004 20:07:21 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 1 Aug 2004 20:07:21 -0700 Message-ID: From: "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: RE: How is SPF different from RMX? Date: Sun, 1 Aug 2004 20:07:21 -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 this respect, RMX was probably better. But it was still rejected > because > > It didn't solve the problem and was therefore gratuitous. The DNSEXT group can be regarded as an authority on requirements after they have successfully deployed DNSSEC and it is in use by 5% of the internet. As far as the IETF is concerned all working groups are peers. The fact that a group has been arround trying to finish its work for 12 years does not seem to me to be a recomendation of its expertise, quite the opposite in fact. > Setting anything is "a matter of minutes for one domain". > Try doing it > for hundreds or thousands of domains. Try a perl script. If you manage hundreds of domains you are familiar with this type of issue. > > , 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. It is pretty easy to set a system up so that your changes propagate in the right way. > 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. Its rather more domains than are using DNSSEC. > "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. ??? The argument here seems to be of the form "I don't know what the problem is going to turn out to be with this protocol but I am sure that there is one and my time is too valuable to bother looking for it". > 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. Perhaps if you read the actual documents you might be able to state how one of these calamaties might occur. Its a bit difficult to disprove a claim that is not even stated. > 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. Nonsense. We are in the process of applying a priority list of things to fix in the mail system. SPF is not the only fix that is necessary, it just happens to be first on the list. In an ideal world the IAB or IESG would be providing a priority list of things to fix. Since they have not others have decided priorities instead. If you feel that other priorities should be attended to then submit a proposal. > So, it seems that you have to track down virus operators and > put them in jail. Have you got a problem with that objective? It seems to be working to the extent of filling up the jails. There has been an indictment in the Sasser/Netsky cases, successful prosecutions in many others. Sender-ID provides some very useful features for both stopping the propagation of viruses and for catching the criminals. From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 02:39: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 CAA18223 for ; Mon, 2 Aug 2004 02:39: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 i726Pxw3049869; Sun, 1 Aug 2004 23:25: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 i726PxEs049867; Sun, 1 Aug 2004 23:25:59 -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 i726PwVa049832 for ; Sun, 1 Aug 2004 23:25:58 -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 i726PvEo003968 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Aug 2004 02:25:58 -0400 Date: Mon, 2 Aug 2004 02:25:57 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 1 Aug 2004, Hallam-Baker, Phillip wrote: > > > > In this respect, RMX was probably better. But it was still rejected > > because > > > > It didn't solve the problem and was therefore gratuitous. > > The DNSEXT group can be regarded as an authority on requirements after > they have successfully deployed DNSSEC and it is in use by 5% of the > internet. Hahahaha. Touche. > > Setting anything is "a matter of minutes for one domain". > > Try doing it > > for hundreds or thousands of domains. > > Try a perl script. If you manage hundreds of domains you are familiar > with this type of issue. I'm sure register.com and Verisign and other lowcost hosting places are thinking the same thing. So, who pays the perl programmer? Do they work for free at Verisign? > > 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. > > It is pretty easy to set a system up so that your changes propagate > in the right way. Some say otherwise. Some say it takes six months now to renumber IP addresses, and we are going to add even more work to that task. > > 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. > > Its rather more domains than are using DNSSEC. Well, I don't think DNSSEC will work either. I've said it many times. That's another poorly thought out, but desperately needed function. But I think they should keep working. When they get it to work, it will be useful. > > "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. > > ??? The argument here seems to be of the form "I don't know > what the problem is going to turn out to be with this protocol > but I am sure that there is one and my time is too valuable to > bother looking for it". Yes. Thats exactly right. I expect the protocol proponents and design engineers to do this work (ie, the people on the list who think this is a good idea), not the production network engineers (ie not the people who will have to fix things on the fly when their mail to AOL.com breaks suddenly). We can't accept "I don't know what the problem is going to turn out to be with this protocol so lets just put it into large scale universal deployment in 8 months and see what happens. I am sure that whatever problems found will have to be solved by others and my time is too valuable to bother looking for it now". > > 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. > > Perhaps if you read the actual documents you might be able to > state how one of these calamaties might occur. > > Its a bit difficult to disprove a claim that is not even stated. Doesn't seem like outsourcing is going to work at all. I already gave as an example scenario of real Av8 Internet customers who send email from: @earthlink.net Earthlink has to add all of Av8 Internet's IP address space that is or might be assigned to that customer. Possibly, if Av8 does the relay, as opposed to direct sending by the Av8/Earthlink customer, then earthlink just has to permit the AV8 Email servers that might be used by that customers. That would have to be maintained. Anytime Av8 changes a server, it has to coordinate that with Earthlink and every one of the other 30,000 ISPs out there whose customers outsource or might outsource from. > > 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. > > Nonsense. We are in the process of applying a priority list of things > to fix in the mail system. SPF is not the only fix that is necessary, > it just happens to be first on the list. > > In an ideal world the IAB or IESG would be providing a priority list > of things to fix. Since they have not others have decided priorities > instead. If you feel that other priorities should be attended to > then submit a proposal. Then get back to me when you have a system of changes that will solve the problem. I don't want to do a bunch of stuff that won't solve the problem. Been down that road far too many times in the last 8-10 years. > > So, it seems that you have to track down virus operators and > > put them in jail. > > Have you got a problem with that objective? No problem with that. That is the only solution I see. > It seems to be working to the extent of filling up the jails. > There has been an indictment in the Sasser/Netsky cases, successful > prosecutions in many others. Yes. It is not a problem finding the people who do things when the incentive to find them exists. It is not a matter of "can't find them", it is a matter frequently of "No significant cost damage so Feds won't bother to even look for them". > Sender-ID provides some very useful features for both stopping > the propagation of viruses and for catching the criminals. I think you need to substantiate that. All that is necessary to track down virus abusers is already there: A time and an IP address in the received header. Nothing else in the message is relevant (other than the virus itself, or the abuse content, that is). SMTP AUTH doesn't help with this. Sender-ID isn't going to help either, since it can always be spoofed for the same domain. Even if that weren't the case, those credentials can be stolen and used on another computer, so fixing this case isn't useful. Having fixed it, you have achieved nothing. It isn't useful at all for stopping the propogation of viruses, unless you assume that the virus writers won't adapt. This is a frequently-made, but invalid assumption. --Dean From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 02:39: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 CAA18224 for ; Mon, 2 Aug 2004 02:39:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i726PtED049797; Sun, 1 Aug 2004 23:25: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 i726Ptew049796; Sun, 1 Aug 2004 23:25:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i726PrrJ049766 for ; Sun, 1 Aug 2004 23:25:54 -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 i726PknK003965 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Aug 2004 02:25:47 -0400 Date: Mon, 2 Aug 2004 02:25:46 -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: <200407311047.19852@totor.bouissou.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Sat, 31 Jul 2004, Michel Bouissou wrote: > 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. That sounds very much like a DNS whitelist. I already have that. Don't need a special protocol for that. Ok. Lets take a likely scenario: There are roughly 30000 ISPs in the world. Lets suppose that either for good business or for anti-trust requirements, they all have to all allow their customers to outsource parts of their email system to the other ISPs. So, each ISP has to allow the servers for each other ISP to send "from:" its domain. How well does that work? Every ISP that is "trusted" can forge mail for the other ISPs. That doesn't really solve any problem at all. I'll neglect the impracticality of maintaining the records for each server for each of those 30,000 ISPs, and the problem of distributing and updating that database. (Hosts.txt we missed you, or maybe we make root servers service a special zone of the ISPs mailservers, or maybe we make the root server operators operate a parallel set of servers for this zone) Even if you trust no other ISPs, all users at that ISP can still be able to forge mail from other users at that ISP. That doesn't really solve any problem either. Oh, wait. There's one more thing: They might want to allow the customer to connect directly from the IP addressed assigned to them by the other ISP. So, not only do they need to allow every ISP's mail servers, they need to allow every IP address. So any IP address forge email from any ISP. Thats actually how it is now at many ISPs. Now we've got nothing but useless DNS requests. So, what good is SPF? That just assuming that everyone uses SPF. That isn't likely to be the case. SPF has to be used by both the sender and the recipient. The sender has to have an "approved" mail server, and the recipient has to reject mail that isn't "approved". If either the sender or the recipient do not use SPF, then email is either blocked, or forgeable. Most places won't want it blocked. Though there are certain radicals who do feel it's ok to block legitimate email, the vast majority of sites don't feel this way. The most likely scenario is that to some degree of market penetration, people will put in SPF records, but few or none will reject mail based on their absence. [cart/horse]. But whatever the case, even if there is full deployment worldwide, the abuser can still send abuse. Its just a waste of time and money. I was thinking that one of the objectives is to have a "responsible entity". Possibly a worthy objective, I am reminded of the cartoon about having to be this high to storm the castle. We might as well have an RFC that says you must be 18 to hack into computers. It would also be useless in stopping abuse. But even if we ignore that all these problems exist, and just take it as a given that everything works as envisioned: No users can forge the email from other users. Abusers wouldn't care. And it still wouldn't stop abuse. So, I'm not sure why we care that they _can_ forge email addresses. How does stopping that change anything? I've never assumed that the from: address meant anything. Ahh. I think now we are getting somewhere. People who make false assumptions (like the from: address means something) want to change the "silly net" to make their false assumptions true. Rob Austein has been trying to do this since 1986, when he didn't want to put numeric addresses in the Recieved: header. > > 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. Really? There is an increase both in database size, and in DNS load. And it means that as you add new domains, that they are each larger, incrementally. That's pretty significant, pretty fast. It doesn't take too long before a large domain hoster can't handle all the DNS traffic. They are already on the edge, many of them. So then they need to upgrade servers, local networks, wide area networks, etc. I am always amazed at the "gee, it worked for me on my littly one-host network. It must work for everyone else. Testing done." > And if a big DNS provider that manages hundreds of thousands domains needs to > upgrade some servers, it will make the industry happy. Not the ISP industry. Not the DNS industry. What industry are you talking about? > > 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. Uhh, Yes you can. > 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. You don't need a ratio of www traffic to Mail traffic. I referred to no ratio. The more records you have to request, the more traffic you'll have. > 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. I overlooked the cache effects. The more records you have to request, the more records will get flushed from the cache to make room for them, and the more often they will need to be requested again. The effect on DNS caches is also negative. This hurts performance across the board. > > > 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 : I do. > 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 I don't. Neither does register.com. They (and we) will have to create all that. > 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. Some do, some don't. Changing it isn't cheap. If we are going to change it, it better be worthwhile. I know I and a lot of other people have just about had it with frivolous "anti-spam" changes. I could go into spam history since 1994, but I think everyone here knows full well that we've been told "just do this one thing, and it'll all go away". We've done quite a few of those things, and spent a lot of money doing it, and it hasn't gone away, and it was obvious why those things would fail back then. You've had your opportunity for the "Just try it, please" song and dance. Several times over. > > 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. Designing? No. Deploying? Yes. Don't expect quick deployment of something that requires a lot of old software to be upgraded. If you want to design SPF with the intention that it will be deployed over the next 10 years, thats different. I'm hearing people say that they want to deploy it in the next 8 months. > 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. They won't run SPF, or won't be able to accept mail from SPF users. Its your 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. I wouldn't say that's "massive". There are probably more SMTP AUTH and SMTP SSL servers than that. There are some 400,000 open relays. However, I neglected to mention one thing: Such numbers are often meaningless for testing and reliability reasons. For example, a voting machine maker has recently said their machines are trustworthy because in tests, they've had 10,000 voting transactions entered and the machine counted them correctly. OF COURSE it counts correctly when no one is trying to tamper with it. I'd say that ought to be a given. Any high school freshman should be able to write a "voting" program that counts correctly. (though I guess the real machines did actually have some counting problems) Similarly, 20000 trivial users doesn't mean that the entire internet can make use of it. > > > "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 ;-) Spend your efforts getting more law enforcement attention to this problem, and it will happen. Presently, reporting virus infections or cracking to the Feds results only in dirty looks about the paperwork they have to fill out before doing nothing. Unless a lot of money is involved. Well, have fun storming the castle. Information theory will prevail once again. Abuse can't be stopped by protocol changes. But, I can see that you are not going to be convinced any more than your dozen predecessors were. Probably be another dozen schemes after this one fails. --Dean From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 03:39:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20844 for ; Mon, 2 Aug 2004 03:39:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i727SYln073572; Mon, 2 Aug 2004 00:28: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 i727SYKY073571; Mon, 2 Aug 2004 00:28:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i727SX48073504 for ; Mon, 2 Aug 2004 00:28:33 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i727SP9g007808 for ; Mon, 2 Aug 2004 08:28:25 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i727SPD9007807; Mon, 2 Aug 2004 08:28:25 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? References: From: Graham Murray Date: Mon, 02 Aug 2004 08:28:25 +0100 In-Reply-To: (Dean Anderson's message of "Mon, 2 Aug 2004 02:25:46 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson writes: > Even if you trust no other ISPs, all users at that ISP can still be able > to forge mail from other users at that ISP. That doesn't really solve any > problem either. > > Oh, wait. There's one more thing: They might want to allow the customer to > connect directly from the IP addressed assigned to them by the other ISP. > So, not only do they need to allow every ISP's mail servers, they need to > allow every IP address. So any IP address forge email from any ISP. Thats > actually how it is now at many ISPs. Now we've got nothing but useless > DNS requests. So, what good is SPF? SPF is still good for those (many) of us who do not use a 'user@isp.com' or 'user@customer.isp.com' style address and even more so for those of us who also run our own mail servers. It enables us to state 'if the email was not sent from one of these addresses, then it is a forgery and not from us'. I agree that it (and many of the other schemes being examined by MARID) does not offer quite so much protection for people who use 'user@isp.com' style addresses or those who have to send mail via their ISP's servers. But if people are concerned about forgery then they can register their own domain and publish appropriately narrow SPF records. From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 04:03:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22114 for ; Mon, 2 Aug 2004 04:03: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 i727bwmI077458; Mon, 2 Aug 2004 00:37: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 i727bw4A077457; Mon, 2 Aug 2004 00:37:58 -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 i727busD077408 for ; Mon, 2 Aug 2004 00:37:57 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 765A5280BE for ; Mon, 2 Aug 2004 09:37:49 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32346-01 for ; Mon, 2 Aug 2004 09:37:43 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 7008F28286; Mon, 2 Aug 2004 09:37:42 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: How is SPF different from RMX? Date: Mon, 2 Aug 2004 09:37:41 +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: <200408020937.41496@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 2 Août 2004 08:25, Dean Anderson a écrit : > > Ok. Lets take a likely scenario:  There are roughly 30000 ISPs in the > world. Lets suppose that either for good business or for anti-trust > requirements, they all have to all allow their customers to outsource > parts of their email system to the other ISPs.  So, each ISP has to allow > the servers for each other ISP to send "from:" its domain. Really ? So there is no point at all publishing SPF records or Sender-ID records or whatever for them, except for publishing the list of their own servers maybe, so their own servers would get a "pass" and others a "neutral". But this basically allows the planet to forge MAIL FROM bearing their domain name. If they do publish an SPF record, it should look more or less like the current AOL SPF record: aol.com text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" However, when most domains will publish more restrictive SPF records, these permissive domains will become the preferred source for email forgeries, so many sysadmins will setup local policies submitting MAIL FROM permissive domains to extra and extreme antispam checks, or treating a "neutral" as a "fail" for aol.com for example. This is surely what I will do myself. We can expect these permissive domains to shift progressively from "?all" to "~all", then "-all" -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 10:11: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 KAA08872 for ; Mon, 2 Aug 2004 10:11: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 i72DwLPB058532; Mon, 2 Aug 2004 06:58:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72DwLCB058531; Mon, 2 Aug 2004 06:58:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ddg.com (mail.ddg.com [66.93.83.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72DwJUA058509 for ; Mon, 2 Aug 2004 06:58:19 -0700 (PDT) (envelope-from awd@DDG.com) Received: from [12.9.185.77] (account awd HELO [12.9.185.77]) by ddg.com (CommuniGate Pro SMTP 4.2) with ESMTP id 1438768; Mon, 02 Aug 2004 08:58:15 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/alternative; boundary=Apple-Mail-13--668740185 Message-Id: Cc: Dean Anderson From: "Andrew W. Donoho" Subject: Isn't spam a Security Problem? (was Re: How is SPF different from RMX?) Date: Mon, 2 Aug 2004 06:58:13 -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-13--668740185 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 1, 2004, at 23:25, Dean Anderson wrote: > Ok. Lets take a likely scenario: There are roughly 30000 ISPs in the > world. Lets suppose that either for good business or for anti-trust > requirements, they all have to all allow their customers to outsource > parts of their email system to the other ISPs. So, each ISP has to > allow > the servers for each other ISP to send "from:" its domain. > > How well does that work? Every ISP that is "trusted" can forge mail > for > the other ISPs. That doesn't really solve any problem at all. I'll > neglect the impracticality of maintaining the records for each server > for > each of those 30,000 ISPs, and the problem of distributing and updating > that database. (Hosts.txt we missed you, or maybe we make root servers > service a special zone of the ISPs mailservers, or maybe we make the > root > server operators operate a parallel set of servers for this zone) > > Even if you trust no other ISPs, all users at that ISP can still be > able > to forge mail from other users at that ISP. That doesn't really solve > any > problem either. Folks, I'm a newbie lurker here so take my comments with a grain of salt. Since Mr. Anderson uses the word trust above, he has entered the realm of security considerations. It seems to me that spam is a security problem. The very first step in security is identification. SPF/SenderID looks like it implements the very stable three party security pattern. The sender is possibly a valid sender. The receiver does not know who the sender is or if they are authorized to send mail. Therefore, with SPF/SenderID, the receiver can ask a possibly independent IP address for another piece of evidence that identifies the sender IP as authorized to send mail for a domain. Like all good security, this is just one of the many mechanisms that both the sender and receiver will use to ensure valid transmissions. Other mechanisms, such as SSL/TLS or DomainKeys or S/MIME or PGP, will also help establish identification. SPF/SenderID, by helping defend brand identity, also helps stop something with financial consequences - phishing. The debate here seems to center around the cost/benefit ratio. Those of us who know that we cannot depend upon the authorities to defend our brand and reputation and must do it ourselves want to start enhancing the SMTP protocols to allow this to happen. Those of us who have built businesses that exploit current design features of SMTP that are at risk due to these changes understandably object to these changes. This debate cannot be resolved using technical issues, the basis of traditional IETF decision making. These are business concerns. As such, we should probably focus upon enabling this capability and letting the market of ideas sort this out. If SPF/SenderID has business value, it will survive. If not, MTA authors will stop asking for SPF/SenderID records and the extension will die. Those vendors whose business has to change during this experiment, as have all of our businesses during the spam deluge, will bear, perhaps, an undue burden. They should speak up now and help minimize that burden. SPF/SenderID does not end spam but it provides a useful tool for, those of us who care about our brand identity, to help minimize spam and improve email as a more trusted medium. As such, it appears to be a useful, simple addition to my email toolkit. Andrew ____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-13--668740185 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Aug 1, 2004, at 23:25, Dean Anderson wrote: Ok. Lets take a likely scenario: There are roughly 30000 ISPs in the world. Lets suppose that either for good business or for anti-trust requirements, they all have to all allow their customers to outsource parts of their email system to the other ISPs. So, each ISP has to allow the servers for each other ISP to send "from:" its domain. How well does that work? Every ISP that is "trusted" can forge mail for the other ISPs. That doesn't really solve any problem at all. I'll neglect the impracticality of maintaining the records for each server for each of those 30,000 ISPs, and the problem of distributing and updating that database. (Hosts.txt we missed you, or maybe we make root servers service a special zone of the ISPs mailservers, or maybe we make the root server operators operate a parallel set of servers for this zone) Even if you trust no other ISPs, all users at that ISP can still be able to forge mail from other users at that ISP. That doesn't really solve any problem either. Folks, I'm a newbie lurker here so take my comments with a grain of salt. Since Mr. Anderson uses the word trust above, he has entered the realm of security considerations. It seems to me that spam is a security problem. The very first step in security is identification. SPF/SenderID looks like it implements the very stable three party security pattern. The sender is possibly a valid sender. The receiver does not know who the sender is or if they are authorized to send mail. Therefore, with SPF/SenderID, the receiver can ask a possibly independent IP address for another piece of evidence that identifies the sender IP as authorized to send mail for a domain. Like all good security, this is just one of the many mechanisms that both the sender and receiver will use to ensure valid transmissions. Other mechanisms, such as SSL/TLS or DomainKeys or S/MIME or PGP, will also help establish identification. SPF/SenderID, by helping defend brand identity, also helps stop something with financial consequences - phishing. The debate here seems to center around the cost/benefit ratio. Those of us who know that we cannot depend upon the authorities to defend our brand and reputation and must do it ourselves want to start enhancing the SMTP protocols to allow this to happen. Those of us who have built businesses that exploit current design features of SMTP that are at risk due to these changes understandably object to these changes. This debate cannot be resolved using technical issues, the basis of traditional IETF decision making. These are business concerns. As such, we should probably focus upon enabling this capability and letting the market of ideas sort this out. If SPF/SenderID has business value, it will survive. If not, MTA authors will stop asking for SPF/SenderID records and the extension will die. Those vendors whose business has to change during this experiment, as have all of our businesses during the spam deluge, will bear, perhaps, an undue burden. They should speak up now and help minimize that burden. SPF/SenderID does not end spam but it provides a useful tool for, those of us who care about our brand identity, to help minimize spam and improve email as a more trusted medium. As such, it appears to be a useful, simple addition to my email toolkit. Andrew Helvetica____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-13--668740185-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 11:27: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 LAA13305 for ; Mon, 2 Aug 2004 11:27:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72F3v34062673; Mon, 2 Aug 2004 08:03: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 i72F3v5Z062672; Mon, 2 Aug 2004 08:03:57 -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 i72F3uVQ062666 for ; Mon, 2 Aug 2004 08:03:56 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([64.229.26.165]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040802150357.WRZZ21087.tomts13-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 2 Aug 2004 11:03:57 -0400 From: "John Glube" To: "'Michel Bouissou'" , "'Dean Anderson'" , "'IETF MARID WG'" Subject: RE: How is SPF different from RMX? Date: Mon, 2 Aug 2004 11:05:51 -0400 Message-ID: <001601c478a2$33e2c070$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <200408020937.41496@totor.bouissou.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i72F3uVQ062667 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The basic premise behind's Dean position as to why SPF is a waste of time, is that we don't have a UBE problem, but rather a problem with viruses. I would beg to differ and suggest we have a problem with fraudulent email, UBE volumes and viruses. Published filtering company statistics seem to suggest on a volume basis: * Roughly 20 - 30% of email is wanted and 70 - 80% is unwanted bulk email. As to fraudulent email, the same statistics suggest: * Compliance with the CAN SPAM Act of 2003 by filtered UBE is around 1 - 2% of total volume. This suggests there is an overall volume problem and a significant problem with fraudlent email. At the same time, reports also suggest of the unwanted bulk email, roughly 70 - 80% is coming from infected networks and computers. Other reports suggest to deal with spam filters, spammers have significantly cranked up volumes resulting in a literal tidal wave of spam. Further, we know from a recent study by Arial Software of over 1,600 major online publications, there is no corelation between compliance and spam volumes. This study found that while over 50% of all major online publications were not in compliance with various requirements of the Act, less than .03% of online publishers sent email after a subscriber opted out. As to solving the virus problem, Dean suggests we need to put people in jail. However, he goes on to imply unless "lots of money is involved," the Feds won't do anything. This is a gratitous swipe at law enforcement officials. The vast majority of whom, from investigators to prosecutors take their duties and responsibilities quite seriously. As to the whole question of testing and implementation, Sendmail recently issued a white paper which is a useful read on their view of what is likely to transpire. https://www.sendmail.com/smi/web_reg/sender_auth_whitepaper.jsp At page 4 of the white paper, Sendmail notes in part: "Timelines and Recommendations ... "Phase 0 – Testing: The current focus is to try these authentication systems [Sender ID and DomainKeys] with real mail on real systems to determine if the approaches proposed are robust enough to survive in the current infrastructure. This process needs the participation of large and small sites alike, as the goal is to exercise the many different paths that a message might take and see how the authentication information for those messages might break." On the question of implementation, Sendmail suggests early adoption will reach critical mass by end of 2004, with an unofficial "flag day" by sometime in the last half of 2005, signalling "the end of the old unaccountable email system." The report also notes "AOL already verifies incoming messages for authentication and gives those that pass privileged processing." Since the issuance of this report, Microsoft announced it will begin the same processs using Sender ID as of October 1, 2004. One quick comment. * The present step is to carry out "robust testing." * As Sender ID and SUBMITTER remain experimental proposals, it would be prudent for this WG to request outside review of these proposals by a panel of graybeards on an expedited basis. 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.729 / Virus Database: 484 - Release Date: 27/07/2004 From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 11:48: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 LAA14793 for ; Mon, 2 Aug 2004 11:48: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 i72FSDrn064432; Mon, 2 Aug 2004 08:28: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 i72FSDDE064431; Mon, 2 Aug 2004 08:28:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72FSCJo064425 for ; Mon, 2 Aug 2004 08:28:12 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BrejR-0004OL-1o for ietf-mxcomp@imc.org; Mon, 02 Aug 2004 10:28:13 -0500 To: "IETF MARID WG" From: wayne Reply-To: "IETF MARID WG" Date: Mon, 02 Aug 2004 09:56:43 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Will there be video of the MARID sessions? 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: Well, it is IETF-60 week. Will there be videos of the MARID sessions like there was of the BoF at IETF-59? -wayne From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 13:15: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 NAA19837 for ; Mon, 2 Aug 2004 13:15:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72H1XcF070402; Mon, 2 Aug 2004 10:01:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72H1X9j070401; Mon, 2 Aug 2004 10:01:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72H1WaO070395 for ; Mon, 2 Aug 2004 10:01:32 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i72H1X4R004166; Mon, 2 Aug 2004 10:01:33 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Aug 2004 10:01:32 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: RE: How is SPF different from RMX? Date: Mon, 2 Aug 2004 10:01:30 -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'm sure register.com and Verisign and other lowcost hosting > places are > thinking the same thing. So, who pays the perl programmer? > Do they work for free at Verisign? That business was sold. But if we were in that business then a perl script is simply the cost of doing business. Not a big deal. > Some say otherwise. Some say it takes six months now to renumber IP > addresses, and we are going to add even more work to that task. Argument by reference to anonymous source is not very credible. Give a specific example. > We can't accept "I don't know what the problem is going to > turn out to be > with this protocol so lets just put it into large scale universal > deployment in 8 months and see what happens. Why not? > I am sure that whatever > problems found will have to be solved by others and my time is too > valuable to bother looking for it now". Well if you think there might be a problem one assumes that you will have bothered to read the drafts and tell us about it. Otherwise it sounds as if you are arguing to do nothing in case we might break the net. If the IETF does nothing then Sender-ID will happen anyway and all you will have achieved is breaking the IETF. The end-users and the sysops are utterly fed up with waiting while nothing is done. > Doesn't seem like outsourcing is going to work at all. I > already gave as > an example scenario of real Av8 Internet customers who send > email from: ... This is not what I understand by the term 'outsourcing' If the users are using an earthink address they better use a method of authenticating their mail that is approved by earthlink. It probably means that they relay their outgoing email through earthlink. If they want to do different then they should get their own domain name. They can still receive on the earthlink address. > > In an ideal world the IAB or IESG would be providing a > priority list > > of things to fix. Since they have not others have decided priorities > > instead. If you feel that other priorities should be attended to > > then submit a proposal. > > Then get back to me when you have a system of changes that > will solve the problem. Since when did your opinion matter? > I don't want to do a bunch of stuff that won't solve the problem. > Been down that road far too many times in the last 8-10 years. You make it sound as if the IESG had been issuing directives to solve spam on a daily basis during that time. Fact is that you have not been asked to do one thing to solve this problem by the IETF *EVER*. Instead you have had self-appointed vigilantes taking over that role. > Yes. It is not a problem finding the people who do things when the > incentive to find them exists. It is not a matter of "can't > find them", > it is a matter frequently of "No significant cost damage so Feds won't > bother to even look for them". I am in regular contact with the Secret Service, Mail Inspectorate and the FBI. Catching the authors of MyDoom and the various gangs who launched it is a major priority. MyDoom has been used to steal rather a large amount of money. From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 13:39: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 NAA21101 for ; Mon, 2 Aug 2004 13:39: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 i72HTR9V073431; Mon, 2 Aug 2004 10: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 i72HTRXI073430; Mon, 2 Aug 2004 10:29:27 -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 i72HTQg6073423 for ; Mon, 2 Aug 2004 10:29:26 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 969112829F for ; Mon, 2 Aug 2004 19:29: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 21793-03 for ; Mon, 2 Aug 2004 19:29:26 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 8528F28282; Mon, 2 Aug 2004 19:29:26 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: A spammer subscribed to this list ? Date: Mon, 2 Aug 2004 19:29:26 +0200 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408021929.26090@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 Hi there, Interestingly enough, I have just received a "Nigerian Scam" sent to an address of my domain which actually isn't an existing address, but a Message-ID of a message I posted to this list (and only to this list) on July, 29. Interestingly, this Message-ID does not display on the IETF-mxcomp web archive, so it hasn't been harvested from there. This is the concerned message: http://www.imc.org/ietf-mxcomp/mail-archive/msg02895.html Which means that either a spammer is subscribed to this list and harvests adresses from mails sent thru this list, or that, one way or the other, a spammer put its hands on this message that I had sent here, full headers included (as the "address" was gotten from there). Here are the full headers of the Nigerian Scam I just received: Note the Received... for. <<<<< Return-Path: Received: from mail.jumpy.it (outgoing1.jumpy.it [213.215.144.9]) by totor.bouissou.net (Postfix) with ESMTP id 9EAA828282 for <200407290053.12479@totor.bouissou.net>; Mon, 2 Aug 2004 16:45:59 +0200 (CEST) Received: from [212.165.141.17] by mail.jumpy.it with HTTP; Mon, 2 Aug 2004 16:45:40 +0200 Date: Mon, 2 Aug 2004 15:45:40 +0100 Message-ID: <40FC73D50000E9A2@mail14.jumpyint.it> From: "VINCENT ANSU" Subject: URGENT TRANSFER!!!! Reply-To: vincentansu1@operamail.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; >>>>> -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 14:03: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 OAA22848 for ; Mon, 2 Aug 2004 14:03:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Hl5AM074720; Mon, 2 Aug 2004 10:47:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72Hl5ra074719; Mon, 2 Aug 2004 10:47:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Hl5oS074712 for ; Mon, 2 Aug 2004 10:47:05 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [12.105.246.84] (10.50.16.79) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Mon, 2 Aug 2004 12:47:06 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <200408021929.26090@totor.bouissou.net> References: <200408021929.26090@totor.bouissou.net> X-Mailer: Eudora [Macintosh version 6.2a3] Date: Mon, 2 Aug 2004 10:47:02 -0700 To: Michel Bouissou From: Pete Resnick Subject: Re: A spammer subscribed to this list ? Cc: "IETF MARID WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 8/2/04 at 7:29 PM +0200, Michel Bouissou wrote: >Interestingly, this Message-ID does not display on the IETF-mxcomp web archive But it does appear in the downloadable archive at: . I doubt there's a subscribed spammer. -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 14:24: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 OAA24742 for ; Mon, 2 Aug 2004 14:23: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 i72IEVfG076607; Mon, 2 Aug 2004 11:14: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 i72IEVCl076606; Mon, 2 Aug 2004 11:14:31 -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 i72IEUMi076600 for ; Mon, 2 Aug 2004 11:14:31 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 1D746280BC for ; Mon, 2 Aug 2004 20:14:34 +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 24178-03-2 for ; Mon, 2 Aug 2004 20:14:30 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 3936928282; Mon, 2 Aug 2004 20:14:30 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: A spammer subscribed to this list ? Date: Mon, 2 Aug 2004 20:14:29 +0200 User-Agent: KMail/1.6.1 References: <200408021929.26090@totor.bouissou.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200408022014.29695@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 2 Août 2004 19:47, Pete Resnick a écrit : > On 8/2/04 at 7:29 PM +0200, Michel Bouissou wrote: > >Interestingly, this Message-ID does not display on the IETF-mxcomp web > > archive > > But it does appear in the downloadable archive at: > . Interesting to know. > I doubt there's a subscribed spammer. Well, the fact remains interesting, whether the spammer got this "address" by receiving it directly in a message from this list, or by retrieving the downloadable text archive... It's also interesting noticing that the web archive takes care of masking e-mail addresses certainly for avoiding them being captured by spammers, and on the other hand, one can get from the same place the complete text archive in one single file, with complete headers of all messages, and without any masking of the addresses inside it... Rather paradoxal. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 14:24: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 OAA24802 for ; Mon, 2 Aug 2004 14:24: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 i72I9qc2076293; Mon, 2 Aug 2004 11:09:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72I9q8v076292; Mon, 2 Aug 2004 11:09:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72I9pMx076285 for ; Mon, 2 Aug 2004 11:09:51 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: A spammer subscribed to this list ? Date: Mon, 2 Aug 2004 13:09:59 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02A5B478@cliff.bai.org> Thread-Topic: A spammer subscribed to this list ? Thread-Index: AcR4uRU1ebWGb3JaTXuokeYf36OOkQAAg96w From: "Ryan Malayter" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i72I9pMx076287 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Pete Resnick] >I doubt there's a subscribed spammer. I'd be very surprised if there *weren't* quite a few spammers subscribed and lurking on this list. They're not stupid, and certainly would want to know about anything this community is doing that might cause them grief and cost them money. "Know thine enemy", and all that. Regards, Ryan From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 14:29: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 OAA25138 for ; Mon, 2 Aug 2004 14:29: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 i72IEbx8076628; Mon, 2 Aug 2004 11:14: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 i72IEb02076627; Mon, 2 Aug 2004 11:14:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72IEaFc076619 for ; Mon, 2 Aug 2004 11:14:36 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i72IEOhc016252 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Aug 2004 14:14:29 -0400 Date: Mon, 2 Aug 2004 14:14:24 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: John Glube cc: "'Michel Bouissou'" , "'IETF MARID WG'" Subject: RE: How is SPF different from RMX? In-Reply-To: <001601c478a2$33e2c070$6c62fea9@ibmrkydk2ufvdd> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Mon, 2 Aug 2004, John Glube wrote: > The basic premise behind's Dean position as to why SPF is a > waste of time, is that we don't have a UBE problem, but > rather a problem with viruses. > > I would beg to differ and suggest we have a problem with > fraudulent email, UBE volumes and viruses. > > Published filtering company statistics seem to suggest on a > volume basis: > > * Roughly 20 - 30% of email is wanted and 70 - 80% is > unwanted bulk email. > > As to fraudulent email, the same statistics suggest: > > * Compliance with the CAN SPAM Act of 2003 by filtered UBE > is around 1 - 2% of total volume. > > This suggests there is an overall volume problem and a > significant problem with fraudlent email. How do you define "fraudulent email"? I define it as mail attempting to defraud the reader of money. In a somewhat unscientific experiment, I replied to 20 Nigerian scams as soon as they came in with a nonchalant "How can I help?" expecting a reply to direct me to reveal a bank account number or some other information. Only one recieved a response, and that was from a person who said their address had been forged. Even the apparently frauds often aren't really frauds. Certainly there are frauds, but not as many as it might appear from the contents of the messages. > At the same time, reports also suggest of the unwanted bulk > email, roughly 70 - 80% is coming from infected networks > and computers. All networks are infected. It is just a matter of degree. Some are worse than others. This suggests that there are some incorrect assumptions about whether networks are infected. > Other reports suggest to deal with spam filters, spammers > have significantly cranked up volumes resulting in a > literal tidal wave of spam. I've seen this "suggested" since 1994. In truth, I've only seen this on usenet news, when the spammers war with the cancel bots. The users see thousands of messages. But this is as much the fault of the radical antispammers running the cancel bots as it is the spammers reposting their messages. Further, the single highest volume spams advertise Viagra. However, I have tried to purchase viagra from a number of these spams, on the premise that Viagra is a presription drug and I don't have a prescription and the seller probably doesn't have a license. Thats also a federal felony, no different from dealing cocaine or heroin. While some have led to websites, none have led to sales or even contacts from salesmen or even fraudulent credit card charges. These are mostly fakes. (I say 'mostly' because perhaps there is some example I didn't find) > Further, we know from a recent study by Arial Software of > over 1,600 major online publications, there is no > corelation between compliance and spam volumes. Do you have a pointer at this study? My own experience is that very little spam is genuinely commercial or even genuinely fraudulent--in the sense that someone is really trying to scam money--even the obviously fraudulent nigerian scams aren't responded to, and are really just joe-jobs. So I haven't seen, nor would I expect any correlation between compliance and volume. Though I'm not sure what you mean by a "correlation between compliance and spam volumes". Do you mean that compliant emailers send more or less volume? Do you mean that total volume is unaffected by compliance? Please explain this. > This study found that while over 50% of all major online > publications were not in compliance with various > requirements of the Act, less than .03% of online > publishers sent email after a subscriber opted out. I'll have to read that. In January, the FTC reported that 90 something percent of the commercial bulk emailers were partially compliant and 57% were fully compliant. > As to solving the virus problem, Dean suggests we need to > put people in jail. However, he goes on to imply unless > "lots of money is involved," the Feds won't do anything. > > This is a gratitous swipe at law enforcement officials. The > vast majority of whom, from investigators to prosecutors > take their duties and responsibilities quite seriously. Nonsense. This is just the way it is. The feds will tell you (they told me) that if there aren't significant financial loses, they won't prosecute. The FBI is understaffed the way it is. Public interest and funding set the priorities. There is no "swipe" in stating what the prosecution and investigation priorities are. But speaking of "gratuitous swipes" .... > As to the whole question of testing and implementation, > Sendmail recently issued a white paper which is a useful > read on their view of what is likely to transpire. > > https://www.sendmail.com/smi/web_reg/sender_auth_whitepaper.jsp > > At page 4 of the white paper, Sendmail notes in part: > > "Timelines and Recommendations ... > > "Phase 0 – Testing: The current focus is to try these > authentication systems [Sender ID and DomainKeys] with real > mail on real systems to determine if the approaches > proposed are robust enough to survive in the current > infrastructure. > > This process needs the participation of large and small > sites alike, as the goal is to exercise the many different > paths that a message might take and see how the > authentication information for those messages might break." > > On the question of implementation, Sendmail suggests early > adoption will reach critical mass by end of 2004, with an > unofficial "flag day" by sometime in the last half of 2005, > signalling "the end of the old unaccountable email system." > > The report also notes "AOL already verifies incoming > messages for authentication and gives those that pass > privileged processing." And has this proved beneficial to AOL users? Will it still be beneficial after abusers adapt to it? > Since the issuance of this report, Microsoft announced it > will begin the same processs using Sender ID as of October > 1, 2004. October 1 is 59 days away. > One quick comment. > > * The present step is to carry out "robust testing." > > * As Sender ID and SUBMITTER remain experimental proposals, > it would be prudent for this WG to request outside review > of these proposals by a panel of graybeards on an expedited > basis. No doubt, a good idea. > 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.729 / Virus Database: 484 - Release Date: 27/07/2004 > > > From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 15:48: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 PAA00142 for ; Mon, 2 Aug 2004 15:48: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 i72JWxbY083073; Mon, 2 Aug 2004 12:32:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72JWxEQ083071; Mon, 2 Aug 2004 12:32:59 -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 i72JWw4l083065 for ; Mon, 2 Aug 2004 12:32:58 -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 i72JX1DE017598 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Aug 2004 15:33:01 -0400 Date: Mon, 2 Aug 2004 15:33:01 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 2 Aug 2004, Hallam-Baker, Phillip wrote: > But if we were in that business then a perl script is simply the cost of > doing business. Not a big deal. I'll remember that quote next time I have something for Verisign to change. In fact, next time someone wants me to pay support for anything, unless of course, its support I need to provide free of charge. Then its different. Kind of reminds me of uucp days when people wanted to do dial-back: Only one site can dial-back. If both insist, either one changes their policy or they don't connect. Neither society nor networks can work that way. > > Some say otherwise. Some say it takes six months now to renumber IP > > addresses, and we are going to add even more work to that task. > > Argument by reference to anonymous source is not very credible. > Give a specific example. I think you follow Nanog, and the recent lawsuit filed over renumbering. Plaintiff claimed they didn't have enough time to renumber. Also, UUnet gives 6 months standard to return address space--personal experience. Specific enough? > > We can't accept "I don't know what the problem is going to turn out to > > be with this protocol so lets just put it into large scale universal > > deployment in 8 months and see what happens. > > Why not? If you don't or can't understand why not, then we don't have enough in common to communicate on the subject. People depend on the internet. We can't just break it. But there are some irresponsible people who disagree. Fortunately, the responsible people are starting to look over their shoulder, in case they really don't understand. But here are some pointers from the code of conduct to help you: 2 # Take all reasonable steps to minimise waste of natural resources, damage to the environment, and damage to products of human skill and industry. 4 # Avoid deploying technologies that defeat generally accepted technical principles of the Internet, as documented primarily by the Internet Engineering Task Force (IETF). In particular, avoid technologies that tend to subdivide access to the Internet rather than preserving its universal, unique, and international nature, except as required by security mechanisms mentioned in the next paragraph. The next paragraph, just in case anyone wants to add "frivolous, gratuitous but really neato change" to the definition of "security mechanisms": 5 # Pay particular attention to the protection of Internet services against disaster and against a physical or electronic attack, and to the protection of the integrity and privacy of stored or transmitted information. > > I am sure that whatever problems found will have to be solved by > > others and my time is too valuable to bother looking for it now". > > Well if you think there might be a problem one assumes that you > will have bothered to read the drafts and tell us about it. > > Otherwise it sounds as if you are arguing to do nothing in case > we might break the net. I not saying do nothing. I'm saying make sure it works, and works in more than just trivial cases. I'm also saying it had better deliver on ending abuse because 1) we've had enough of these gratuitous changes which have never delivered on their promises in the past, and 2) I'm saying that information theory says that it is impossible to make a protocol that can't be abused, so you probably should have an award winning paper ready explaining why information theory is violated. So far, you haven't come close to meeting these standards. > If the IETF does nothing then Sender-ID will happen anyway and > all you will have achieved is breaking the IETF. The end-users > and the sysops are utterly fed up with waiting while nothing is > done. Excuse me? If the IETF cancels or doesn't approve Sender-ID it will happen anyway so we better work on it or else? Sure thing, Osama. I'll get right on it. I think the sysops and end-users are totally fed-up with being fed promises that if they do this one thing, that spam will end. I think they are fed up with being taken for a ride. I have a better metaphor: Witch doctors shouldn't have promised the sysops and end users that something _could_ be done that can't be done. (a common enough mistake frequently made by marketing in modern times) The witch doctors said that if we stand on our heads it will stop the flooding, and by that they technically mean that it will keep our feet dry. Now it had better stop raining and the flood waters had better recede. And we had better not drown while we are standing on our proverbial heads. I'm the scientist who said that standing on your head will not affect the rainfall nor the drainage. And I say that standing on your head in a flood might keep your feet dry but you'll drown faster. I say its better to spend your time building rain ditches, dikes and levys, and that this standing on your head business is just so much hooey. But the witch doctors have said other things in the past: Run Cancel bots, that'll get 'em Use this blacklist Kill the IEMCC, (it came back in CAN-SPAM) Use Pop before SMTP Use SMTP AUTH Use this other blacklist Use this whitelist Try this DCC thing None of that worked. We are getting fed up with stuff that doesn't work. > > Doesn't seem like outsourcing is going to work at all. I already gave > > as an example scenario of real Av8 Internet customers who send email > > from: ... > > This is not what I understand by the term 'outsourcing' > > If the users are using an earthink address they better use a > method of authenticating their mail that is approved by > earthlink. It probably means that they relay their outgoing > email through earthlink. It doesn't, contrary to the assumptions of some, but not the actual experience of others. > If they want to do different then they should get their own > domain name. They can still receive on the earthlink address. In some cases, they did this, and in some cases earthlink hosts part of that domain. No difference. > > > In an ideal world the IAB or IESG would be providing a priority list > > > of things to fix. Since they have not others have decided priorities > > > instead. If you feel that other priorities should be attended to > > > then submit a proposal. > > > > Then get back to me when you have a system of changes that > > will solve the problem. > > Since when did your opinion matter? Silly me. Why would anyone be interested in a working system, rather than a really neato, but non-working system. > > I don't want to do a bunch of stuff that won't solve the problem. > > Been down that road far too many times in the last 8-10 years. > > You make it sound as if the IESG had been issuing directives to solve > spam on a daily basis during that time. The IESG, technically, no. Other witch doctors? yes. > Fact is that you have not been asked to do one thing to solve this > problem by the IETF *EVER*. I'd say SMTP AUTH was an IETF proposal to replace Pop-before-SMTP. And while the IETF carefully removed "spam control" from its official goal, that was in fact the goal of Pop-before-SMTP. So the IETF has had the opportunity to address spam, and is clearly not ignorant of the problem, as you know very well from participation in the DNSEXT namedroppers list where "spam control" was used to abuse some participants over the last several years. > Instead you have had self-appointed vigilantes taking over that > role. Some of those vigilantes have rather close associations with the IETF. But I've always been against vigilantism. Control of abuse involves limiting the rights and privileges of people, and that quickly becomes a goverment activity. It is never a technical activity, other than to provide evidence of the activity and who did it. Anyway, in compliance with the ISOC code of conduct rule 3: 3 # If his or her professional advice is not accepted, take all reasonable steps to ensure that all persons neglecting or over-ruling this advice are aware of the possible danger or damage which may result. I don't think many on _this_ forum agree with me to wait with large scale deployment until more positive results are known. Though enough did on DNSEXT to kill RMX. > > Yes. It is not a problem finding the people who do things when the > > incentive to find them exists. It is not a matter of "can't find > > them", it is a matter frequently of "No significant cost damage so > > Feds won't bother to even look for them". > > I am in regular contact with the Secret Service, Mail Inspectorate > and the FBI. Catching the authors of MyDoom and the various gangs who > launched it is a major priority. MyDoom has been used to steal rather > a large amount of money. We agree on something. Always good to agree on _something_. --Dean From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 16: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 QAA01412 for ; Mon, 2 Aug 2004 16:12: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 i72JucQc085828; Mon, 2 Aug 2004 12:56: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 i72JucTc085827; Mon, 2 Aug 2004 12:56:38 -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 i72JubDX085821 for ; Mon, 2 Aug 2004 12:56:37 -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 i72Jufia018020 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Aug 2004 15:56:41 -0400 Date: Mon, 2 Aug 2004 15:56:41 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 2 Aug 2004, Dean Anderson wrote: > I think you follow Nanog, and the recent lawsuit filed over renumbering. > Plaintiff claimed they didn't have enough time to renumber. Also, UUnet > gives 6 months standard to return address space--personal experience. > Specific enough? Oops. I erred. UUnet actually gives 3 years to return address space (personal experience). ARIN gives 6 months. Some people grumble that this is not enough time. --Dean From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 16:42: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 QAA04303 for ; Mon, 2 Aug 2004 16:42: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 i72KWDlD088590; Mon, 2 Aug 2004 13: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 i72KWDAM088589; Mon, 2 Aug 2004 13:32:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KWCdW088583 for ; Mon, 2 Aug 2004 13:32:12 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i72KWFsF009086; Mon, 2 Aug 2004 13:32:16 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Aug 2004 13:32:15 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: RE: How is SPF different from RMX? Date: Mon, 2 Aug 2004 13:32:08 -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'll remember that quote next time I have something for Verisign to > change. I think that there is a very big difference between a change that costs a few hours of sysadmin time and a change that increases the data volume in the .com zone by an order of magnitude. It is one thing to demand that a change be kept to a manageable proportion, quite another to demand no change at all ever. If you were arguing that the spec should be changed in a particular way to facilitate deployment that would be quite another matter. > > Argument by reference to anonymous source is not very credible. > > Give a specific example. > > I think you follow Nanog, Nope, never have. > and the recent lawsuit filed over renumbering. > Plaintiff claimed they didn't have enough time to renumber. Sure, I can see a potential cause of action there. But SPF is not going to make any difference. The cost of renumbering is in the effort required to reconfig individual machines. If it was pure DNS then people would not be getting steamed. The effect of SPF is different, there is no obligation to deploy SPF. The only consequence of not deploying is that you are going to find it harder to get your mail accepted by the major ISPs. I don't think you have a cause of action here. > If you don't or can't understand why not, then we don't have enough in > common to communicate on the subject. People depend on the > internet. We can't just break it. We can't just do nothing while the spammers break it either. Not doing anything has not worked to date and shows zero chance of working in the future. Ergo a bias in favor of action appears quite justified. > But there are some irresponsible people who disagree. > Fortunately, the responsible people are starting to look over their > shoulder, in case they really don't understand. But as you yourself admit, you are not looking over our shoulder, what you are doing is asserting that what we are doing is very likely to be broken and that the seriousness of the consequences means that you don't have to do anything to justify your assertion. I beleive that unless Sender-ID is deployed by the end of this year the entire planet earth is likely to be eaten by a giant mutant star-goat followed shortly afterwards by the collapse of the entire space time continum. Since I am sure you will agree that these consequences would be the most serious imaginable you won't be needing any justification. > But here are some pointers from the code of conduct to help you: Conduct, shmonduck, we have no time for those! Star-Goat! Star-Goat! > > 2 # Take all reasonable steps to minimise waste of natural > resources, > damage to the environment, and damage to products of human skill and > industry. 'all reasonable' does not mean never do anything that might cause people to need to change. > 4 # Avoid deploying technologies that defeat generally accepted > technical principles of the Internet, as documented primarily by the > Internet Engineering Task Force (IETF). In particular, avoid > technologies that tend to subdivide access to the Internet > rather than > preserving its universal, unique, and international nature, > except as > required by security mechanisms mentioned in the next paragraph. Since when was sending fraudulent emails a generally accepted practice? > I not saying do nothing. I'm saying make sure it works, and > works in more than just trivial cases. What you are saying is that you want to argue against the proposal but want to make your case impossible to argue against by refusing to provide more than the vaguest of arguments. Star-Goat! Star-Goat! > Excuse me? If the IETF cancels or doesn't approve Sender-ID it will > happen anyway so we better work on it or else? Sure thing, > Osama. I'll get right on it. Comparing people to a mass murderer probably counts as a personal attack. Empirically SPF was happening before this group formed. If the IETF was to go arround cancelling ideas without the slightest of justifications as you appear to be advocating it is not going to be in the business of making decisions very long. If you want to stop something you need to give very precise reasons not to do it. Vague possibilities of harm are no more of a reason for not doing something than the star-goat is a reason to do something. > Witch doctors shouldn't have promised the sysops and end users that > something _could_ be done that can't be done. You have failed to show why or how it can't be done. > I'm the scientist who said that standing on your head will > not affect the rainfall nor the drainage. Scientists do not make vague assertions and then refuse to support them. You have failed to propose any mechanism whatsoever. > But the witch doctors have said other things in the past: > Run Cancel bots, that'll get 'em > Use this blacklist > Kill the IEMCC, (it came back in CAN-SPAM) > Use Pop before SMTP > Use SMTP AUTH > Use this other blacklist > Use this whitelist > Try this DCC thing And I have been on record for many years arguing that most of those was a terrible idea at the time. I argued against ARMM before it was even launched and went amok. I argued against MAPS long before it became fashionable to do so. The only schemes that have had lasting value are authentication based schemes. > None of that worked. We are getting fed up with stuff that > doesn't work. So, it is long past time to let the real security professionals tackle the problem. > I'd say SMTP AUTH was an IETF proposal to replace > Pop-before-SMTP. And > while the IETF carefully removed "spam control" from its > official goal, > that was in fact the goal of Pop-before-SMTP. SMTP Auth seems to be a better idea in principle than POP before SMTP which was clearly a kludge. And most people seem to think that it is a good thing to be able to close down open relays and still relay legitimate email. > So the IETF has had the opportunity to address spam, and is clearly > not ignorant of the problem, as you know very well from participation > in the DNSEXT namedroppers list where "spam control" was used to > abuse some participants over the last several years. The DNSEXT group appears to believe that spam control is outside their scope. Ergo there is not much that can be deduced from conversations in that forum other than that they do not intend to consider it. > Anyway, in compliance with the ISOC code of conduct rule 3: > > 3 # If his or her professional advice is not accepted, take all > reasonable steps to ensure that all persons neglecting or > over-ruling > this advice are aware of the possible danger or damage > which may result. This statement refers to 'the possible danger or damage', the use of the definite article is surely intentional. If the idea had been to consider the mere possibility that damage might result then nothing would ever get done. > I don't think many on _this_ forum agree with me to wait with > large scale > deployment until more positive results are known. Though enough did on > DNSEXT to kill RMX. OK so because you managed to kill the idea five years ago in another forum using scare tactics you don't need to ever give reasons for your opposition again? Star-Goat! From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 18:47: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 SAA11900 for ; Mon, 2 Aug 2004 18:47:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72MYxv0099244; Mon, 2 Aug 2004 15:34: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 i72MYxoS099243; Mon, 2 Aug 2004 15:34:59 -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 i72MYtP6099234 for ; Mon, 2 Aug 2004 15:34:58 -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 i72MYvrh020650 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Aug 2004 18:34:59 -0400 Date: Mon, 2 Aug 2004 18:34:57 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 2 Aug 2004, Hallam-Baker, Phillip wrote: > > > I'll remember that quote next time I have something for Verisign to > > change. > > I think that there is a very big difference between a change that > costs a few hours of sysadmin time and a change that increases the > data volume in the .com zone by an order of magnitude. Well, I haven't said either of these things. For some it might be minutes, for others hours, for others days. For all, very likely, lost mail, and hours tracking down the problem. For all, a constant, recurring additional maintanence requirement. Cost for the abuser: a few days at most. Then nothing after that. > It is one thing to demand that a change be kept to a manageable > proportion, quite another to demand no change at all ever. If you > were arguing that the spec should be changed in a particular way > to facilitate deployment that would be quite another matter. I don't demand no change ever. I just think that there should be some benefit to the changes, and that they shouldn't be gratuitous. > > > Argument by reference to anonymous source is not very credible. > > > Give a specific example. > > > > I think you follow Nanog, > > Nope, never have. > > and the recent lawsuit filed over renumbering. > > Plaintiff claimed they didn't have enough time to renumber. > > Sure, I can see a potential cause of action there. But SPF is not > going to make any difference. The cost of renumbering is in the > effort required to reconfig individual machines. If it was pure > DNS then people would not be getting steamed. > > The effect of SPF is different, there is no obligation to > deploy SPF. The only consequence of not deploying is that you > are going to find it harder to get your mail accepted by the > major ISPs. That's a pretty major consequence. Though, I don't think its likely that major ISPs will ever be able to reject mail. Not for long. I think most likely scenario is that many of the millions of domains will remain unconfigured or misconfigured, just like in-addr is today. No large ISP was able to reject misconfigured[**] or unconfigured in-addr, either. What makes you think that they will every be able to reject non-SPF domains? That really mystifies me. [**Radical antispammers have long proposed that in-addr checks can somehow "authenticate" a source. Not only was this proven to be a flaw in the BSD r-commands, it was shown to be a false claim on both DNSEXT and DNSOP. In-addr will be impractical for IPv6 and has been replaced by Hostinfo. It was discussed that in-addr should be dropped altogether from IPv6. Also, ARIN has been considering not providing in-addr service. ARIN has gone so far as to have its lawyers investigate whether they are required to provide this service, and the lawyers say they aren't required to do so.] > > If you don't or can't understand why not, then we don't have enough in > > common to communicate on the subject. People depend on the > > internet. We can't just break it. > > We can't just do nothing while the spammers break it either. Spammers (as in Commercial Bulk Emailers) aren't breaking anything. The few that are, are handled by CAN-SPAM. But very few are violating CAN-SPAM. > Not doing anything has not worked to date and shows zero chance of > working in the future. Ergo a bias in favor of action appears quite > justified. A lot has been done, and nothing has worked. Makes one just about think you might want to prove information theory the same way the 4 color theorem was proven: by exhausting all possible combinations. > > But there are some irresponsible people who disagree. > > Fortunately, the responsible people are starting to look over their > > shoulder, in case they really don't understand. > > But as you yourself admit, you are not looking over our shoulder, > what you are doing is asserting that what we are doing is very likely > to be broken and that the seriousness of the consequences means that > you don't have to do anything to justify your assertion. In principle, thats exactly correct: The non-design community shouldn't have to prove it won't work: Rather the designers should have to prove that it will work. The IETF has at core the principle of "running code." But I am, in fact, going further and demonstrating that it won't work: the abuser can simply adapt and continue forging email, or just stop forging email and continue. All that work, by all those production engineers in deployment. And for what: Nothing. Kind of reminds me of the gopher in the movie Caddyshack. You're playing the role of Bill Murray, going around with dynamite trying to kill a gopher. The gopher just pops out another hole. You have to blow up the whole golf course, and in the end, the gopher just dances and sings "I'm all right, nobody worry about me." to the end credits. Its funny in the movies. Its less funny in real life. > I beleive that unless Sender-ID is deployed by the end of this year > the entire planet earth is likely to be eaten by a giant mutant > star-goat followed shortly afterwards by the collapse of the entire > space time continum. Since I am sure you will agree that these > consequences would be the most serious imaginable you won't be needing > any justification. Thats about all I've heard so far as justification for Sender-ID. Well, ok, that's not true. I've heard it'll solve the spam problem, just don't look under the hood or run any serious tests until after deployment. Deployment is the test. > > But here are some pointers from the code of conduct to help you: > > Conduct, shmonduck, we have no time for those! Star-Goat! Star-Goat! Ok. > > > > 2 # Take all reasonable steps to minimise waste of natural > > resources, > > damage to the environment, and damage to products of human skill and > > industry. > > 'all reasonable' does not mean never do anything that might cause > people to need to change. I didn't say that. However, "unreasonable steps" does seem excessive. > > 4 # Avoid deploying technologies that defeat generally accepted > > technical principles of the Internet, as documented primarily by the > > Internet Engineering Task Force (IETF). In particular, avoid > > technologies that tend to subdivide access to the Internet > > rather than > > preserving its universal, unique, and international nature, > > except as > > required by security mechanisms mentioned in the next paragraph. > > Since when was sending fraudulent emails a generally accepted > practice? I didn't say that either. Sending email is a generally accepted practice. Outsourcing is a generally accepted practice. And your proposal doesn't prevent sending fraudulent emails. Even if it were worthwhile to give up email and outsourcing, your proposal doesn't deliver the goods. __Quid pro Quo__ If I give you my goods, you better actually deliver your promises, rather than just make them. But you can't stop fraudulent email, and so you won't deliver up your Quid for my Quo. > > I not saying do nothing. I'm saying make sure it works, and > > works in more than just trivial cases. > > What you are saying is that you want to argue against the proposal > but want to make your case impossible to argue against by refusing > to provide more than the vaguest of arguments. Nonsense. You have to prove that you can stop abuse. I have shown that the abusers can still send abuse. That isn't a vague argument. You've offered no argument at all that the abuse will actually be stopped. > Star-Goat! Star-Goat! "Spam! Spam will flow if you don't do this! Don't ask me any questions or have me bother to test it! Just do it now! Quickly! Quickly! Spaaamm! Phillip had written: > If the IETF does nothing then Sender-ID will happen anyway and > all you will have achieved is breaking the IETF. The end-users > and the sysops are utterly fed up with waiting while nothing is > done. > > Excuse me? If the IETF cancels or doesn't approve Sender-ID it will > > happen anyway so we better work on it or else? Sure thing, > > Osama. I'll get right on it. > > Comparing people to a mass murderer probably counts as a personal attack. Extorting the IETF by saying that it cannot disapprove the Sender-ID proposal is probably a violation of the code of conduct. > Empirically SPF was happening before this group formed. If the IETF > was to go arround cancelling ideas without the slightest of justifications > as you appear to be advocating it is not going to be in the business > of making decisions very long. Slightest justification? Please be intellectually honest. There isn't the slightest justification that Sender-ID or RMX can achieve its goals. That makes them both gratuitous. > > Witch doctors shouldn't have promised the sysops and end users that > > something _could_ be done that can't be done. > > You have failed to show why or how it can't be done. Perhaps you haven't been listening. > > > I'm the scientist who said that standing on your head will > > not affect the rainfall nor the drainage. > > Scientists do not make vague assertions and then refuse to > support them. You have failed to propose any mechanism whatsoever. Law Enforcement attention to virus operators. Law Enforcement attention to CAN-SPAM violators (there are few, but they will need attention) > > But the witch doctors have said other things in the past: > > Run Cancel bots, that'll get 'em > > Use this blacklist > > Kill the IEMCC, (it came back in CAN-SPAM) > > Use Pop before SMTP > > Use SMTP AUTH > > Use this other blacklist > > Use this whitelist > > Try this DCC thing > > And I have been on record for many years arguing that most of those > was a terrible idea at the time. I argued against ARMM before it was > even launched and went amok. I argued against MAPS long before it > became fashionable to do so. So have I. > The only schemes that have had lasting value are authentication > based schemes. ?? Which ones were that? I think the only ones to have lasting value were DCC and Spam-Bayes. But these are also defeatable. They only have the lasting benefit that the abuser must continue to adapt as they adapt. Its a merry-go-round. > > None of that worked. We are getting fed up with stuff that > > doesn't work. > > So, it is long past time to let the real security professionals > tackle the problem. Yes. Real security professionals realize that a police uniform doesn't mean you are a police officer. Superficial identification is never more than superficial. > > I'd say SMTP AUTH was an IETF proposal to replace > > Pop-before-SMTP. And > > while the IETF carefully removed "spam control" from its > > official goal, > > that was in fact the goal of Pop-before-SMTP. > > SMTP Auth seems to be a better idea in principle than POP before SMTP > which was clearly a kludge. > > And most people seem to think that it is a good thing to be able to > close down open relays and still relay legitimate email. Neither Pop-before-SMTP nor SMTP AUTH had any effect. No effect whatsoever. And most of the people who thought that open relays were a bad idea have now closed up shop. They were always the ones that abused open relays. Open relay abuse has dropped to nearly nothing. Another "hoop" that didn't have any effect. > > So the IETF has had the opportunity to address spam, and is clearly > > not ignorant of the problem, as you know very well from participation > > in the DNSEXT namedroppers list where "spam control" was used to > > abuse some participants over the last several years. > > The DNSEXT group appears to believe that spam control is outside their > scope. Ergo there is not much that can be deduced from conversations > in that forum other than that they do not intend to consider it. That wasn't why RMX was killed. DNS protocol extensions is in the scope. And a protocol extension for Spam is no different than a protocol extension for AFS. (the afs extension was approved). > > Anyway, in compliance with the ISOC code of conduct rule 3: > > > > 3 # If his or her professional advice is not accepted, take all > > reasonable steps to ensure that all persons neglecting or > > over-ruling > > this advice are aware of the possible danger or damage > > which may result. > > This statement refers to 'the possible danger or damage', the use > of the definite article is surely intentional. > > If the idea had been to consider the mere possibility that damage > might result then nothing would ever get done. By some perhaps. We usually keep root passwords away from those folks. Others are more careful, and consider the consequences of what they do before they do it. I get the feeling that perhaps you are bit reckless--seat of the pants, balls-on-fire, "torpedos? Damn the torpedos" type of fellow. That OK for a developer. Or a programmer. Or a protocol designer. Its not such a good trait in a production operations person. > > I don't think many on _this_ forum agree with me to wait with > > large scale > > deployment until more positive results are known. Though enough did on > > DNSEXT to kill RMX. > > OK so because you managed to kill the idea five years ago in > another forum using scare tactics you don't need to ever give > reasons for your opposition again? It wasn't with scare tactics, and it wasn't 5 years ago. You have not provided a single rebuttal to the examples I gave previously of how an abuser can still send abuse. I demonstrated that abusers can still send abuse. You haven't refuted that, and you accuse me of being vague and using scare tactics. Please. > Star-Goat! "Spam! Spam will flow if you don't do this! Don't ask me any questions or have me bother to test it! Just do it now! Quickly! Quickly! Spaaamm! Oh my GAWD! Its full of SPAAAAAAAAAM! AIIIIHHHH" Ok, enough for me. --Dean From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 19:40:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14956 for ; Mon, 2 Aug 2004 19:40:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72NU7D9002923; Mon, 2 Aug 2004 16: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 i72NU7NL002922; Mon, 2 Aug 2004 16:30: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 i72NU6d9002915 for ; Mon, 2 Aug 2004 16:30: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 i72NbkCh020270 for ; Mon, 2 Aug 2004 16:37:46 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i72NbknB020267 for ; Mon, 2 Aug 2004 16:37:46 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 2 Aug 2004 16:37:46 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I think you follow Nanog, and the recent lawsuit filed over renumbering. > Plaintiff claimed they didn't have enough time to renumber. What does one stupid company after themselve creating situation where they forced their biggest client out and then wanting to hurt their former client as much as possible, but can't because of court order, and now crying "wolf" (did they look at the mirror?) in public has anything to do with standards for renumbering? When you renumber you have to change dns zones, you already have ip addresses in each zone that likely need to be changed. Adding one new line with ips that need to change will not change things much. Its either if you have to change zone or not that makes a different, but if you already do, its matter of proper scripting. > Also, UUnet gives 6 months standard to return address space--personal > experience. Specific enough? UUNET gives 12 months or more to renumber. ARIN gives 12 months to renumber Other ISPs have their own standards (usually less then 12 month). European people said their "unpublished" standards is up to 6 months AFTER client already left that they can continue to use old ip addresses and renumber. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 19:53: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 TAA15637 for ; Mon, 2 Aug 2004 19:53:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72NfA8I003400; Mon, 2 Aug 2004 16:41: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 i72NfAdY003399; Mon, 2 Aug 2004 16:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Nf9cO003390 for ; Mon, 2 Aug 2004 16:41:09 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i72NfBch018623; Mon, 2 Aug 2004 16:41:11 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Aug 2004 16:41:11 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: RE: How is SPF different from RMX? Date: Mon, 2 Aug 2004 16:41:08 -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 have asked repeatedly for a specific fault in Sender-ID. The only response that has been given is a repeat of the vague claim that the protocol is flawed and cannot work. The fact that other people have proposed broken solutions to the spam problem and have failed is irrelevant. None of the specific reasons for failure appear to be relevant in the context of Sender-ID. The requirements that Sender-ID seeks to meet are very precise. It provides a means by which legitimate users of a domain name may authenticate themselves to recipients in a limited set of circumstances. It is understood that failure to authenticate cannot be considered proof that the sender is false. Other authentication mechanisms to meet an extended set of circumstances are pending completion of this work. Phill From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 21:41: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 VAA21196 for ; Mon, 2 Aug 2004 21:41: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 i731PZ0n010851; Mon, 2 Aug 2004 18:25: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 i731PZDs010850; Mon, 2 Aug 2004 18:25:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i731PZoe010844 for ; Mon, 2 Aug 2004 18:25:35 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i731PcJY023214; Mon, 2 Aug 2004 18:25:38 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Aug 2004 18:25:38 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'william(at)elan.net'" , IETF MARID WG Subject: RE: How is SPF different from RMX? Date: Mon, 2 Aug 2004 18:25:38 -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 think you follow Nanog, and the recent lawsuit filed over > renumbering. > > Plaintiff claimed they didn't have enough time to renumber. > > What does one stupid company after themselve creating > situation where they > forced their biggest client out and then wanting to hurt > their former client > as much as possible, but can't because of court order, and now crying > "wolf" (did they look at the mirror?) in public has anything > to do with > standards for renumbering? I took a look at the NANOG list archives. William is putting it very mildly here. This related to a pleading for a Temporary Restraining Order to protect the customer of the ISP for a short period of time in order to allow them to perform an orderly transition. > its > matter of proper scripting. Or you tell your users to use smtp.example.com as the address for outgoing email service. Then you write an SPF rule to state that the address smtp.example.com maps to is a legitimate address. Job done now and forever. > > Also, UUnet gives 6 months standard to return address > space--personal > > experience. Specific enough? > > UUNET gives 12 months or more to renumber. ARIN gives 12 > months to renumber > Other ISPs have their own standards (usually less then 12 > month). European > people said their "unpublished" standards is up to 6 months > AFTER client > already left that they can continue to use old ip addresses > and renumber. There is a big interest in making this easy since otherwise it would create a perverse incentive for folk going out to get their own allocations in order to protect themselves from abuse by their ISP. Phill From owner-ietf-mxcomp@mail.imc.org Mon Aug 2 22:27: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 WAA22928 for ; Mon, 2 Aug 2004 22:27: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 i732GIH1014454; Mon, 2 Aug 2004 19: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 i732GIY5014453; Mon, 2 Aug 2004 19: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 i732GH5r014447 for ; Mon, 2 Aug 2004 19:16:18 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([64.229.26.165]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040803021619.TFXG6357.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 2 Aug 2004 22:16:19 -0400 From: "John Glube" To: "'Dean Anderson'" , "'Michel Bouissou'" , "'IETF MARID WG'" Subject: RE: How is SPF different from RMX? Date: Mon, 2 Aug 2004 22:18:11 -0400 Message-ID: <003601c47900$2204fe50$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i732GI5r014448 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dean, You wrote a very long message in response. I had drafted a long reply, but then realized this whole debate is getting far away from the purpose of this working group which is to provide constructive review or suggestions concerning the proposals on the table. I will therefore limit my comments as follows: * Go to http://www.arialsoftware.com to read the study. Scroll to the bottom of the page. (The study was of 1,057 companies and not 1,600 my mistake.) * I can find no report issued in January, 2004 by the FTC concerning compliance by bulk mailers as you suggest. What I can find is the report made to Congress by Muris in May, 2004 to the US Senate concerning implementation of the CAN SPAM Act of 2003 and dealing with the spam problem: http://www.ftc.gov/speeches/muris/040520spamemailtest.pdf The only thing I can find of relevance is a footnote, referencing a study dealing with falsity in spam, conducted in April, 2003: http://www.ftc.gov/reports/spam/030429spamreport.pdf In essence, the survey found roughly 2/3rds of all spam had some indicator of falsity. According to the related footnote, as of April, 2003, the FTC had 11.6 million pieces of spam as reported to it by consumers in its database. By May, 2004 this number had gone to over 100 million pieces of spam as reported by consumers. This suggests we do have a volume problem as it relates to UBE. The American Congress made a decision in December, 2003 to enact a law which focuses on regulating commercial email. Apart from giving consumers the right to opt-out, this law does not control volume levels. It delegates this task to internet access services. In essence the Act gives these service providers two years to deal with the problem. (Why do I say this? Because the FTC has to report to Congress in December, 2005 on what has happened.) We can posit lots of theories as to why Congress acted the way it did. The FTC has formed the view that an opt-in law will not control volumes. This underlines the remarks of the Commission before the Senate in May, 2004. See also the following: http://inbox2004.blogspot.com/2004/06/can-spam.html However, the situation unfolding in Australia would seem to put paid to this suggestion. http://www.aca.gov.au/aca_home/media_releases/media_enquiries/200 4/04-55.htm - and - http://www.spamhaus.org/news.lasso?article=154 But all this does not matter. At present, the proposal is sender accountability, which includes authentication, accreditation and reputation. The MARID charter, based on the work done by the Anti Spam Research Group is focused on the use of DNS to allow for accountability between mail transfer agents. The purpose of this WG is now to put forward constructive proposals in reviewing the work done to date. My own suggestion is simple. Any experimental proposal which may have significant impact on the Internet infrastructure should be reviewed by a panel of greybeards. Since Sender ID and Submitter is an experimental proposal with significant potential impact, this WG should ask a panel of greybeards to review the work on an expedited basis to facilitate the process. On the underlying philosophical question, do, I think any technical solution will solve email abuse. Nope. Never did. Why? The Internet is a human creation and humanity ain't perfect. The best we can hope for through one or more technical solutions is to bring the situation under control and to keep the situation under control through effective law enforcement, along with consumer education. No different than dealing with abusive behaviour generally, except in this instance the problem and solutions have technical components. 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.729 / Virus Database: 484 - Release Date: 27/07/2004 From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 07:24: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 HAA02577 for ; Tue, 3 Aug 2004 07: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 i73AqodS049479; Tue, 3 Aug 2004 03:52: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 i73AqoQN049478; Tue, 3 Aug 2004 03:52:50 -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 i73Aqn0Z049472 for ; Tue, 3 Aug 2004 03:52:49 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [130.129.136.122] ([::ffff:130.129.136.122]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 03 Aug 2004 06:52:50 -0400 id 0002C2C0.410F6E82.000009A5 In-Reply-To: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: "'Harry Katz'" , "'Ted Hardie'" , "'Mark Lentczner'" , IETF MARID WG From: Andrew Newton Subject: Re: IPR Disclosure for Sender-ID Date: Tue, 3 Aug 2004 06:52:49 -0400 To: "John Glube" 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 John, I have received no additional information regarding IPR for Sender-ID. I do note the following: o Reading the "Status of this Memo" section of http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt, there is a statement that all IPR has been submitted. o The text of http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt (which, incidentally, cites draft-ietf-simple-iscomposing-00) is titled "Microsoft's Statement about IPR Claimed in draft-atkinson-callerid" o The title of the draft http://www.ietf.org/internet-drafts/draft-atkinson-callerid-00.txt is "Caller ID for E-mail". o Section 3.2 of draft-atkinson-callerid-00.txt and Section 4 of draft-ietf-marid-core-02.txt discuss the same process for determining a "responsible" domain though the wording is not identical. o The title of draft-ietf-marid-core-02.txt is "Sender ID: Authenticating E-Mail". o The following web page is cited in the Caller ID IPR claim as containing a license to implement: http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx o The above web page is titled "Sender ID" and contains a link to "Caller ID for E-Mail Implementation License". Based on this, I can see how a person could reasonably assume that the patent claim for draft-atkinson-callerid-00.txt also covers draft-ietf-marid-core-02.txt. This topic is still on the agenda for the 4 August meeting. The deadline of 2 August was given so that participants could have time to read any additional material before the meeting. -andy On Aug 3, 2004, at 4:25 AM, John Glube wrote: > Andy, > > Having completed a search of the IETF's IPR notices it seems > the only filing by Microsoft to date is: > > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-calleri > d.txt > > This was filed on May 28, 2004 and concerns > draft-aktinson-caller-id. > > From the Sender-ID Schedule posted on 19.07.2004: > > "Aug. 2 - Deadline to have all IPR information to the MARID > working group mailing list. This includes patent claims, > licensing information, and trademark issues." > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02749.html > > With no filings being made and nothing being posted to the > mailing list, further to the comments of Ted Hardie on > 19.07.04 regarding the license issue: > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02748.html > > I request guidance. > > * What is the present relevance if any of the filing by > Microsoft on May 28, 2004 to draft-ietf-marid-core-02.txt > titled "Sender ID: Authenticating E-Mail" filed in July and > found at: > > http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt > > May this WG proceed forward on the basis that: > > * MS has not abandoned its original position? > > I ask this question as the MS web page dealing with Sender > ID continues to state: > > "If you are a software developer and are interested in > implementing this specification in software, please review > the terms of the Caller ID for E-Mail Implementation License > before you begin, as the patent license discusses the rights > that Microsoft would grant you or your organization." > > http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx > > On 18.07.04, Henry Katz wrote: > > "Thanks Bryce. I am drafting an FAQ to answer the questions > that have been raised. As I'm sure you can appreciate, this > needs review and approval by attorneys (plural) and other > folk here. I hope to be able to publish this FAQ to the > list within the next few days. > > I understand and appreciate the questions people have been > asking. Let me just say at this point that our intent is to > contribute our IP to this working group and to encourage > widespread implementation and adoption. I very much > appreciate everyone's patience while I gather the answers to > your questions." > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02737.html > > * MS is not making an IPR claim concerning Sender-ID and > therefore software developers who are interested in > implementing the Sender-ID specification have no need to > seek a license from MS? > > I ask this question as: > > * there has been no filing by Microsoft concerning > draft-ietf-marid-core-02.txt > > * nothing was posted to the list on August 2, 2004; > > * the following comment by Mark Lentczner on July 30, 2004 > when he wrote in part: > > "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." > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02927.html > > I appreciate your time in this matter and await your > guidance. > > John > > P.S. There is a sense of urgency. MS announced on 22.07.04 > it will begin testing Sender-ID on 01.10.04 on the > MSN and Hotmail domains. MS is urging other ISPs to follow > suit. Time is beginning to run out for this deadline. > > The IPR issue was placed on the WG Agenda for August 4. > In anticipation, on 19.07.04 the WG asked for a posting > by 02.08.04. The time line has lapsed. > > cc. Ted, Harry, Mark and the IETF Marid Mailing List > > 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.729 / Virus Database: 484 - Release Date: 27/07/2004 > > From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 07: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 HAA03510 for ; Tue, 3 Aug 2004 07:46:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73BWv0w053607; Tue, 3 Aug 2004 04:32: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 i73BWvAU053606; Tue, 3 Aug 2004 04:32:57 -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 i73BWu3x053599 for ; Tue, 3 Aug 2004 04:32:56 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BrxXI-0000e3-H6 for ietf-mxcomp@imc.org; Tue, 03 Aug 2004 06:32:58 -0500 To: "IETF MARID WG" References: <70DDD67E-D9BB-11D8-BD4A-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 03 Aug 2004 06:32:52 -0500 In-Reply-To: <70DDD67E-D9BB-11D8-BD4A-000A95B3BA44@hxr.us> (Andrew Newton's message of "Mon, 19 Jul 2004 15:40:08 -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: Schedule for Sender-ID Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.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 <70DDD67E-D9BB-11D8-BD4A-000A95B3BA44@hxr.us> Andrew Newton writes: > Several questions have been raised regarding the scheduling of the > last call of Sender-ID (marid-core, marid-protocol, marid-submitter). > > - Aug. 2 - Deadline to have all IPR information to the MARID working > group mailing list. > o this includes patent claims, licensing information, and > trademark issues Ok, yesterday was the deadline to have all IPR info to be sent to this list, but I didn't see any. It appears that nothing has been updated on either the IETF website nor the Microsoft website. It appears that the current CallerID is at least very burdensome to quite a few open source MTAs and spam filters, if not outright incompatible. So, what's up? Is MS going to be given another extention? Are we going to drop the PRA? Are we going to try and standardize on an RFC that will not be acceptable to the open source community? -wayne From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 12:54:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21223 for ; Tue, 3 Aug 2004 12:54:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GcNEK077168; Tue, 3 Aug 2004 09:38: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 i73GcNYn077167; Tue, 3 Aug 2004 09:38: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 i73GcMiM077157 for ; Tue, 3 Aug 2004 09:38:22 -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 8BCD44149B; Tue, 3 Aug 2004 09:38:23 -0700 (PDT) Received: from 130.129.132.229 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Tue, 3 Aug 2004 09:38:23 -0700 (PDT) Message-ID: <3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> In-Reply-To: <43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us> Date: Tue, 3 Aug 2004 09:38:23 -0700 (PDT) Subject: Re: IPR Disclosure for Sender-ID From: "Douglas Otis" To: "Andrew Newton" Cc: "John Glube" , "'Harry Katz'" , "'Ted Hardie'" , "'Mark Lentczner'" , "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 find it difficult to imagine the licensing terms to be reasonable for most. See: http://download.microsoft.com/download/6/0/a/60a02573-3c00-4ee1-856b-afa39c020a95/callerid_license.pdf An alternative with the _same_ feature set can be found as follows: 1) Authenticate and verify the authorization of the EHLO domain with CSV. 2) To restrict the RFC 2822 From domain, list all acceptable EHLO domains for From domain allowed in a MARID TXT record. Call the (Mailer-ID) and the TXT record the MARID Channel permissions (MCP). This would allow authentication to happen without adding a single DNS lookup. Unlike Sender-ID with DNS timeouts that fail to implement exponentional back-off while making huge demands upon DNS, or where the duration of their query may otherwise take hours. By using only names, the delegation problems are removed. A simple wildcard used in this permitted list could encompass the required scope. There would not be CIDR block lists that allows easy abuse. All the advantages, none of the disadvantages... -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 13: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 NAA25908 for ; Tue, 3 Aug 2004 13:45:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73HTZiY081473; Tue, 3 Aug 2004 10:29: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 i73HTZRl081472; Tue, 3 Aug 2004 10:29:35 -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 i73HTX22081462 for ; Tue, 3 Aug 2004 10:29:34 -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 1Bs36L-0004ve-Gq for ietf-mxcomp@imc.org; Tue, 03 Aug 2004 12:29:32 -0500 To: "IETF MARID WG" References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us> <3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 03 Aug 2004 12:29:25 -0500 In-Reply-To: <3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> (Douglas Otis's message of "Tue, 3 Aug 2004 09:38:23 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: IPR Disclosure for Sender-ID Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.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 <3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> "Douglas Otis" writes: > I find it difficult to imagine the licensing terms to be reasonable for > most. See: I agree. From the research that I have done, it appears that the SenderID license is incompatible with several important free software packages (exim, postfix, spamassassin, bogofilter, etc.). As far as I'm concerned, this makes the PRA a non-starter. Even if the PRA RFC makes it past the working group last call, I see very little chance that it would make it through the general IETF last call. I think that Microsoft's failure to come up with an acceptable license has created a very unfortunate waste of time for this working group. > An alternative with the _same_ feature set can be found as follows: > > 1) Authenticate and verify the authorization of the EHLO domain with CSV. > > 2) To restrict the RFC 2822 From domain, list all acceptable EHLO domains > for From domain allowed in a MARID TXT record. Yes, this general idea has been suggested many times by many people, including me near the beginning of the on the SPF lists and PHB during the interim meeting. I'm sure I'm not the first, nor will you be the last to see this obvious idea. So, the one I-D with the PRA algorithm could be replaced with: http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt -wayne From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 14:52:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02054 for ; Tue, 3 Aug 2004 14:52:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73IbpV3087655; Tue, 3 Aug 2004 11:37: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 i73Ibp2B087654; Tue, 3 Aug 2004 11:37:51 -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 i73IbocY087647 for ; Tue, 3 Aug 2004 11:37:50 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id B161328286 for ; Tue, 3 Aug 2004 20:37:53 +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 23910-06 for ; Tue, 3 Aug 2004 20:37:50 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id B090528292; Tue, 3 Aug 2004 20:37:50 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Schedule for Sender-ID Date: Tue, 3 Aug 2004 20:37:50 +0200 User-Agent: KMail/1.6.1 References: <70DDD67E-D9BB-11D8-BD4A-000A95B3BA44@hxr.us> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200408032037.50246@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 3 Août 2004 13:32, wayne a écrit : > So, what's up? > > Is MS going to be given another extention? Hopefully not. > Are we going to drop the PRA? Hopefully yes. > Are we going to try and standardize on an RFC that will not be > acceptable to the open source community? That would be a major failure. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 14:57:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02423 for ; Tue, 3 Aug 2004 14:57:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73IYcMo086760; Tue, 3 Aug 2004 11:34: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 i73IYcxw086759; Tue, 3 Aug 2004 11:34:38 -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 i73IYb71086737 for ; Tue, 3 Aug 2004 11:34:37 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 127FF28286 for ; Tue, 3 Aug 2004 20:34:34 +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 29691-01 for ; Tue, 3 Aug 2004 20:34:31 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 5765528292; Tue, 3 Aug 2004 20:34:31 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: IPR Disclosure for Sender-ID Date: Tue, 3 Aug 2004 20:34:30 +0200 User-Agent: KMail/1.6.1 References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200408032034.30859@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 3 Août 2004 19:29, wayne a écrit : > > > I find it difficult to imagine the licensing terms to be reasonable for > > most.  See: > > I agree.  From the research that I have done, it appears that the > SenderID license is incompatible with several important free software > packages (exim, postfix, spamassassin, bogofilter, etc.). I agree. > As far as I'm concerned, this makes the PRA a non-starter. I fully share this point of view. Sorry for this me-too style reply to the list, but I think the matter is important enough, so I express again my opinion on the matter, which I have expressed in more detail previously. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 17:34: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 RAA13998 for ; Tue, 3 Aug 2004 17:34: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 i73LJ16B001461; Tue, 3 Aug 2004 14:19: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 i73LJ1OE001460; Tue, 3 Aug 2004 14:19:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73LJ14x001454 for ; Tue, 3 Aug 2004 14:19:01 -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 E8F83414B7; Tue, 3 Aug 2004 14:19:05 -0700 (PDT) Received: from 130.129.132.229 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Tue, 3 Aug 2004 14:19:05 -0700 (PDT) Message-ID: <3048.130.129.132.229.1091567945.squirrel@harry.mail-abuse.org> In-Reply-To: References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd><43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us><3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> Date: Tue, 3 Aug 2004 14:19:05 -0700 (PDT) Subject: Re: IPR Disclosure for Sender-ID From: "Douglas Otis" To: "IETF MARID WG" Cc: "IETF MARID WG" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > "Douglas Otis" writes: > >> I find it difficult to imagine the licensing terms to be reasonable for >> most. See: > > I agree. From the research that I have done, it appears that the > SenderID license is incompatible with several important free software > packages (exim, postfix, spamassassin, bogofilter, etc.). > > As far as I'm concerned, this makes the PRA a non-starter. Even if > the PRA RFC makes it past the working group last call, I see very > little chance that it would make it through the general IETF last > call. > > I think that Microsoft's failure to come up with an acceptable license > has created a very unfortunate waste of time for this working group. > > >> An alternative with the _same_ feature set can be found as follows: >> >> 1) Authenticate and verify the authorization of the EHLO domain with >> CSV. >> >> 2) To restrict the RFC 2822 From domain, list all acceptable EHLO >> domains >> for From domain allowed in a MARID TXT record. > > Yes, this general idea has been suggested many times by many people, > including me near the beginning of the on the SPF lists and PHB during > the interim meeting. I'm sure I'm not the first, nor will you be the > last to see this obvious idea. > > So, the one I-D with the PRA algorithm could be replaced with: > >http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt This has a problem with scaling. As a means to reduce the information and to simplify publishing and support, use the CSV authorized and authenticated name for the channel, rather than repeating this address information. CSV provides a means for accreditation to be related exclusively to the polices of the domain sending the mail. This domain must be watching their logs to detect SMTP errors. If they see too many errors, these must be investigated further and matched against the abuse@ reports. The holder of the log, as denoted by the EHLO response, is the gatekeeper for the mail sent. They have the greatest effect in blocking abuse. Build upon CSV, where mail domain permission records do not need to include any IP address. As example, if a record wishes to restrict the RFC 2821 MAIL FROM and RFC 2822 From for *@big.bank.com to be emitted by SMTP servers offering the EHLO mx1.big.isp.com mx2.big.isp.com and java.ads-r-us.com ... These records could be something like: "Marid_1 rf=*.big.isp.com, *.ads-r-us.com;" This record puts a restriction on both the RFC2822 From and the return path (RFC2821 MAIL FROM). If to just to limit the MAIL FROM, then the text may be: "Marid_1 r=*.big.isp.com, *.ads-r-us.com;" If the identity of the sender includes a display something like- From: fred@some-domain.com If the ehlo domain did not offer CSV records, then the it could be: From: fred@some-domain.com This would offer a means for people to recognize the identity of the sender by both their return address and their channel identifier. If there is a crime, then the channel identifier becomes the place to look for the logs. If big.bank.com puts a restriction on their From field, one would not expect them to be sending from a list server with this domain. Even without the restriction, the user would be able to see if they were talking to someone on the same channel. This would allow the same methods for filtering, with Sender-ID. Assume that most major ISPs would have reacted by putting Resent-From: headers into outgoing mail to isolate thier customers from the problems Sender-ID cause. The EHLO domain places the same role. It is already being sent. CSV simply fixes the problem discovered with STMP EHLO domain authentication. For those domains that prevent abuse, but don't wish to restrict the From address for their domain, then only the CSV SRV records are needed for this MAIL-ID to be useable and beneficial. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 17: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 RAA15078 for ; Tue, 3 Aug 2004 17:53:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73LgWMJ003279; Tue, 3 Aug 2004 14:42: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 i73LgWur003278; Tue, 3 Aug 2004 14:42:32 -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 i73LgWO4003262 for ; Tue, 3 Aug 2004 14:42:32 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.156] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 7B3B140D9 for ; Tue, 3 Aug 2004 14:42:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <0469C730-E596-11D8-A694-000393A56BB6@glyphic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Mark Lentczner Subject: Discussing CSV Date: Tue, 3 Aug 2004 14:42:28 -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 All - On July 2nd, Marshall wrote: > 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. I have therefore kept all my comments and thoughts on CSV off list. Doug Otis' posts of the last week, especially his most recent for today, are mostly discussion of CSV, and why CSV is better than Sender-ID or any other proposal. Is CSV now open for discussion again? If so, I have a fair bit to say, especially on the issue of CSV vs. the other proposals. Chairs? - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 18:49:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19285 for ; Tue, 3 Aug 2004 18:49:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Mb5YT007452; Tue, 3 Aug 2004 15:37: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 i73Mb5xs007451; Tue, 3 Aug 2004 15:37:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Mb52N007442 for ; Tue, 3 Aug 2004 15:37:05 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 Aug 2004 15:37:15 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i73Mb3au009043 for ; Tue, 3 Aug 2004 15:37:04 -0700 (PDT) Received: from fenton-w2k01.cisco.com (sjc-vpn4-387.cisco.com [10.21.81.131]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i73N7DkZ024383 for ; Tue, 3 Aug 2004 16:07:16 -0700 Message-Id: <4.3.2.7.2.20040803153731.042cd770@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 15:38:24 -0700 To: "IETF MARID WG" From: Jim Fenton Subject: Re: Will there be video of the MARID sessions? In-Reply-To: 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:"1091574436.773392"; x:"432000"; a:"rsa-sha1"; b:"0:319"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"prPKgnfep5+YAdYjgHXrQP12JwN//soYejUxAJr9/byLQrb4CbS+PLLovK9Uc" "GRtzzCf413C/Dlpc68JUT1GVpJlcw65Srb7/2O4lGu7eEFVYh1CfOTXylXERy" "lE1GAVsvdx6JlVAVbBqSqV1ksdFvh3b3o5b30P6Zh45RboXwo="; c:"Date: Tue, 03 Aug 2004 15:38:24 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: Will there be video of the MARID sessions?" 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 09:56 AM 8/2/2004 -0500, wayne wrote: >Well, it is IETF-60 week. Will there be videos of the MARID sessions >like there was of the BoF at IETF-59? On http://www.ietf.org/meetings/agenda_60.html it doesn't have a star next to the session name, indicating a multicast session, so I suspect not. -Jim From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 18:51: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 SAA19393 for ; Tue, 3 Aug 2004 18:51:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73MYLmB007301; Tue, 3 Aug 2004 15:34: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 i73MYLgl007300; Tue, 3 Aug 2004 15:34:21 -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 i73MYIt2007292 for ; Tue, 3 Aug 2004 15:34:18 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id F141628286 for ; Wed, 4 Aug 2004 00:34:22 +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 00851-04 for ; Wed, 4 Aug 2004 00:34:09 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 23B9428290; Wed, 4 Aug 2004 00:34:09 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: IPR Disclosure for Sender-ID Date: Wed, 4 Aug 2004 00:34:08 +0200 User-Agent: KMail/1.6.1 References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <3048.130.129.132.229.1091567945.squirrel@harry.mail-abuse.org> In-Reply-To: <3048.130.129.132.229.1091567945.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: <200408040034.08677@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 3 Août 2004 23:19, Douglas Otis a écrit : > > These records could be something like: > "Marid_1 rf=*.big.isp.com, *.ads-r-us.com;" About CSV, I have taken a quick look at the drafs (sorry, I haven't had the time to read them thoroughly), and I have a question, and a remark : - Question : SPF currently has the extremely useful and flexible "exists" mechanism, that, combined with its built-in macro-expansion, allows for designing very fine-grained and flexible exceptions to the general SPF rule for a given domain, i.e. per user and subnet. Let's say big-company.com has an SPF record listing their main outgoing mail servers, they can easily include supplementary records that would list field-people posting from a given ISP server, or a local office people using their own local SMTP server, etc. This can be most useful in a number of situations. Does CSV have provisions for such a mechanism, or an equivalent ? Now for the remark : I am strongly opposing to the idea of would-become- mandatory "accreditation services". I'm opposing to it both for philosophical reasons, and practical reasons. First, "accreditation services" will turn into businesses, which will translate into cost, which means that every domain that will want to send mail out will have to support this new cost : having to pay a commercial "accreditation" company to get listed there, if they want their mail to be accepted. This will introduce costs that many non-profit, personal or vany domains will not be able to afford, and I oppose the idea that anybody should have to pay a commercial company for being allowed to send mail. The advantage of current blacklist systems is that no one has to pay for getting blacklisted ;-) and, if some blacklists are commercial, such as MAPS, you need to pay to use and query them, not to be listed in them or not... Also, big companies that send large amounts of email will be well-know and listed by most, if not all, accreditation services, where little domains, small businesses and individuals that send a very small amout of mail will mostly be "unknown" everywhere, and the acceptance of their mail might suffer from this. IMHO, one should be deemed innocent until proved guilty, and the "accreditation services" system turn the things upside-down : One will be presumed guilty unless listed as innocent. Bad, bad, bad. The advantage of blacklists, on the opposite, is that, if ever you get listed, there is probably a reason, and if you're not listed you're presumed innocent. Much better. Comments ? -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 19:33: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 TAA21723 for ; Tue, 3 Aug 2004 19:33:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73NJVn4010868; Tue, 3 Aug 2004 16: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 i73NJVqZ010867; Tue, 3 Aug 2004 16:19:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73NJVxG010861 for ; Tue, 3 Aug 2004 16:19:31 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i73NJYxt013661 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 Aug 2004 19:19:34 -0400 Date: Tue, 3 Aug 2004 19:19:34 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: "'william(at)elan.net'" , IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 2 Aug 2004, Hallam-Baker, Phillip wrote: > > > > I think you follow Nanog, and the recent lawsuit filed ove > > > renumbering. Plaintiff claimed they didn't have enough time to > > > renumber. > > > > What does one stupid company after themselve creating situation where > > they forced their biggest client out and then wanting to hurt their > > former client as much as possible, but can't because of court order, > > and now crying "wolf" (did they look at the mirror?) in public has > > anything to do with standards for renumbering? > > I took a look at the NANOG list archives. William is putting it > very mildly here. > > This related to a pleading for a Temporary Restraining Order > to protect the customer of the ISP for a short period of time > in order to allow them to perform an orderly transition. My apologies. Everyting that is obvious to me isn't obvious to everyone. Plainly, if you have more things to migrate, it will take longer to migrate, and thus it will take longer to renumber, and you will have more lawsuits and/or ISP will be forced to provide more time to renumber. This reduces the amount of IP Address space that is available since a greater amount of space is in transition longer and thus can't be used. > Or you tell your users to use smtp.example.com as the address > for outgoing email service. Then you write an SPF rule to state > that the address smtp.example.com maps to is a legitimate > address. > > Job done now and forever. Or you just reject Sender-ID and keep the renumbering problem the same as it is. Now and forever. From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 19:34: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 TAA21750 for ; Tue, 3 Aug 2004 19:33: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 i73NJMlY010854; Tue, 3 Aug 2004 16:19: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 i73NJMW3010853; Tue, 3 Aug 2004 16:19:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73NJLSm010844 for ; Tue, 3 Aug 2004 16:19:22 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i73NJNa8013658 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 Aug 2004 19:19:26 -0400 Date: Tue, 3 Aug 2004 19:19:23 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 2 Aug 2004, Hallam-Baker, Phillip wrote: > > I have asked repeatedly for a specific fault in Sender-ID. The only response > that has been given is a repeat of the vague claim that the protocol is > flawed and cannot work. Wrong and misleading as well. I have given you a large number of specific faults: (I'll summarize) 1) Abuser can forge addresses at domain 2) Abuser can use stolen credential 3) DNS cache problems (more records per domain, same cache size) 4) DNS load (more records per domain) 5) Ongoing Maintenance issues 6) Migration issues 7) IP Renumbering issues 8) Lost non-spam emails 9) Lack of universal compliance.* [* I didn't use this name before. This is the in-addr problem I referred to earlier. It is unlikely that entire net will comply, just like attempts at using in-addr for antispam. Too many sites worldwide don't have it. Unless everyone does it, it isn't any good for anyone. And like in-addr, having it doesn't mean it isn't spam, anyway.] I think there might be more. But #1 is the show-stopper. You haven't solved any problems involving email abuse. Commercial emailers aren't aren't forging emails. Perhaps if you'd actually read my emails it would help. > The fact that other people have proposed broken solutions to the spam > problem and have failed is irrelevant. None of the specific reasons for > failure appear to be relevant in the context of Sender-ID. The very long list of previous failed proposals is relevant because we are no longer interested in "just trying something" that ___might___ possibly stop spam. > The requirements that Sender-ID seeks to meet are very precise. It provides > a means by which legitimate users of a domain name may authenticate > themselves to recipients in a limited set of circumstances. It is understood > that failure to authenticate cannot be considered proof that the sender is > false. It doesn't meet this goal. Senders can still forge email from other users at a domain. > Other authentication mechanisms to meet an extended set of circumstances are > pending completion of this work. No "authentication mechanisms" can stop viruses from using stolen credentials. Strong, public key per-user authentication systems have been proposed and dismissed as failing to solve the problem. Lesser authentication mechanisms won't solve the problem any better. From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 19:52: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 TAA23040 for ; Tue, 3 Aug 2004 19:52:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Ndoeq012095; Tue, 3 Aug 2004 16:39:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73NdnBq012094; Tue, 3 Aug 2004 16:39:49 -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 i73NdnDk012085 for ; Tue, 3 Aug 2004 16:39:49 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 393D7E05C9; Tue, 3 Aug 2004 19:39:53 -0400 (EDT) Date: Tue, 3 Aug 2004 19:39:53 -0400 From: John Leslie To: Mark Lentczner Cc: IETF MARID WG Subject: Re: Discussing CSV Message-ID: <20040803233953.GA91949@verdi> References: <0469C730-E596-11D8-A694-000393A56BB6@glyphic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0469C730-E596-11D8-A694-000393A56BB6@glyphic.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark Lentczner wrote: > On July 2nd, Marshall wrote: >> 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. > > I have therefore kept all my comments and thoughts on CSV off list. It is certainly appropriate to comment directly to the authors in order to honor this reuest. (And I will note that Mark has done so.) > Doug Otis' posts of the last week, especially his most recent for > today, are mostly discussion of CSV, and why CSV is better than > Sender-ID or any other proposal. 1. Marshall requested "a few weeks". Dave Crocker and I are willing to put off discussion a small bit longer; but I can't blame Doug for feeling the request may have expired. 2. Doug really isn't "discussing CSV", though he keeps mentioning it. He's mostly disussing what he sees as failings of the various flavors of SPF. 3. Regardless of Marshall's request, it is not helpful (IMHO) to censor ourselves to the extent of failing to post anything that mentions CSV. > Is CSV now open for discussion again? I don't believe CSV has ever _not_ been open for discussion; but probably _extensive_ discussion of it is better done with the authors privately for another day or so. Of course, YMMV, and I fully intend to respect requests of the chairs. > If so, I have a fair bit to say, especially on the issue of CSV vs. > the other proposals. IMHO, it would be helpful to discuss these issues on-list. Of course, I (and the other authors, so far as I know) will be happy to receive comments off-list as well. > Chairs? It's not really fair to ask the chairs to rule on this until the close of tomorrow afternoon's session... -- John Leslie From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 20:05: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 UAA23808 for ; Tue, 3 Aug 2004 20:05: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 i73NrWHm012938; Tue, 3 Aug 2004 16: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 i73NrW2Z012937; Tue, 3 Aug 2004 16:53:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73NrW1f012931 for ; Tue, 3 Aug 2004 16:53:32 -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, 3 Aug 2004 16:53:37 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Aug 2004 16:53:37 -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, 3 Aug 2004 16:53:37 -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, 3 Aug 2004 16:53:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPR Disclosure for Sender-ID Date: Tue, 3 Aug 2004 16:53:32 -0700 Message-ID: Thread-Topic: IPR Disclosure for Sender-ID Thread-Index: AcR5SAq1nemc3//WSeOD/+CCzLjAWgAbOXug From: "Harry Katz" To: "Andrew Newton" , "John Glube" Cc: "Ted Hardie" , "Mark Lentczner" , "IETF MARID WG" X-OriginalArrivalTime: 03 Aug 2004 23:53:38.0054 (UTC) FILETIME=[1883AA60:01C479B5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i73NrW1f012932 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit As you know, Sender ID is the result of a merger of various elements of SPF and Microsoft's Caller ID for E-mail proposal. Microsoft has filed the IPR disclosure for Caller ID, and we will file a disclosure as soon as we reasonably can - very shortly - for that portion of Sender ID where Microsoft still has IPR to contribute, namely draft-ietf-marid-core-02. > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, August 03, 2004 3:53 AM > To: John Glube > Cc: Harry Katz; 'Ted Hardie'; 'Mark Lentczner'; IETF MARID WG > Subject: Re: IPR Disclosure for Sender-ID > > John, > > I have received no additional information regarding IPR for Sender-ID. > > I do note the following: > o Reading the "Status of this Memo" section of > http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.t > xt, there is a statement that all IPR has been submitted. > o The text of > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt > (which, incidentally, cites draft-ietf-simple-iscomposing-00) > is titled "Microsoft's Statement about IPR Claimed in > draft-atkinson-callerid" > o The title of the draft > http://www.ietf.org/internet-drafts/draft-atkinson-callerid-00 > .txt is "Caller ID for E-mail". > o Section 3.2 of draft-atkinson-callerid-00.txt and > Section 4 of draft-ietf-marid-core-02.txt discuss the same > process for determining a "responsible" domain though the > wording is not identical. > o The title of draft-ietf-marid-core-02.txt is "Sender ID: > Authenticating E-Mail". > o The following web page is cited in the Caller ID IPR > claim as containing a license to implement: > http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx > o The above web page is titled "Sender ID" and contains a > link to "Caller ID for E-Mail Implementation License". > > Based on this, I can see how a person could reasonably assume > that the patent claim for draft-atkinson-callerid-00.txt also > covers draft-ietf-marid-core-02.txt. > > This topic is still on the agenda for the 4 August meeting. > The deadline of 2 August was given so that participants could > have time to read any additional material before the meeting. > > -andy > > > On Aug 3, 2004, at 4:25 AM, John Glube wrote: > > > Andy, > > > > Having completed a search of the IETF's IPR notices it > seems the only > > filing by Microsoft to date is: > > > > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-calleri > > d.txt > > > > This was filed on May 28, 2004 and concerns > draft-aktinson-caller-id. > > > > From the Sender-ID Schedule posted on 19.07.2004: > > > > "Aug. 2 - Deadline to have all IPR information to the MARID working > > group mailing list. This includes patent claims, licensing > > information, and trademark issues." > > > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02749.html > > > > With no filings being made and nothing being posted to the mailing > > list, further to the comments of Ted Hardie on > > 19.07.04 regarding the license issue: > > > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02748.html > > > > I request guidance. > > > > * What is the present relevance if any of the filing by > Microsoft on > > May 28, 2004 to draft-ietf-marid-core-02.txt titled "Sender ID: > > Authenticating E-Mail" filed in July and found at: > > > > http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt > > > > May this WG proceed forward on the basis that: > > > > * MS has not abandoned its original position? > > > > I ask this question as the MS web page dealing with Sender ID > > continues to state: > > > > "If you are a software developer and are interested in implementing > > this specification in software, please review the terms of > the Caller > > ID for E-Mail Implementation License before you begin, as > the patent > > license discusses the rights that Microsoft would grant you or your > > organization." > > > > http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx > > > > On 18.07.04, Henry Katz wrote: > > > > "Thanks Bryce. I am drafting an FAQ to answer the > questions that have > > been raised. As I'm sure you can appreciate, this needs review and > > approval by attorneys (plural) and other folk here. I hope > to be able > > to publish this FAQ to the list within the next few days. > > > > I understand and appreciate the questions people have been asking. > > Let me just say at this point that our intent is to > contribute our IP > > to this working group and to encourage widespread > implementation and > > adoption. I very much appreciate everyone's patience while > I gather > > the answers to your questions." > > > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02737.html > > > > * MS is not making an IPR claim concerning Sender-ID and therefore > > software developers who are interested in implementing the > Sender-ID > > specification have no need to seek a license from MS? > > > > I ask this question as: > > > > * there has been no filing by Microsoft concerning > > draft-ietf-marid-core-02.txt > > > > * nothing was posted to the list on August 2, 2004; > > > > * the following comment by Mark Lentczner on July 30, 2004 when he > > wrote in part: > > > > "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." > > > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02927.html > > > > I appreciate your time in this matter and await your guidance. > > > > John > > > > P.S. There is a sense of urgency. MS announced on 22.07.04 it will > > begin testing Sender-ID on 01.10.04 on the MSN and Hotmail > domains. MS > > is urging other ISPs to follow suit. Time is beginning to > run out for > > this deadline. > > > > The IPR issue was placed on the WG Agenda for August 4. > > In anticipation, on 19.07.04 the WG asked for a posting by > 02.08.04. > > The time line has lapsed. > > > > cc. Ted, Harry, Mark and the IETF Marid Mailing List > > > > 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.729 / Virus Database: 484 - Release Date: 27/07/2004 > > > > > > From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 20:07:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24019 for ; Tue, 3 Aug 2004 20:07: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 i73NnHVI012783; Tue, 3 Aug 2004 16: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 i73NnHFZ012782; Tue, 3 Aug 2004 16:49:17 -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 i73NnG6N012774 for ; Tue, 3 Aug 2004 16:49:17 -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 97539414B7; Tue, 3 Aug 2004 16:49:17 -0700 (PDT) Received: from 130.129.132.229 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Tue, 3 Aug 2004 16:49:17 -0700 (PDT) Message-ID: <3072.130.129.132.229.1091576957.squirrel@harry.mail-abuse.org> In-Reply-To: <200408040034.08677@totor.bouissou.net> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <3048.130.129.132.229.1091567945.squirrel@harry.mail-abuse.org> <200408040034.08677@totor.bouissou.net> Date: Tue, 3 Aug 2004 16:49:17 -0700 (PDT) Subject: Re: IPR Disclosure for Sender-ID 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 mardi 3 Août 2004 23:19, Douglas Otis a écrit : >> >> These records could be something like: >> "Marid_1 rf=*.big.isp.com, *.ads-r-us.com;" > > About CSV, I have taken a quick look at the drafs (sorry, I haven't had > the time to read them thoroughly), and I have a question, and a remark : > > - Question : SPF currently has the extremely useful and flexible "exists" > mechanism, that, combined with its built-in macro-expansion, allows for > designing very fine-grained and flexible exceptions to the general SPF > rule for a given domain, i.e. per user and subnet. If using CSV, any exceptions would be per hostname. As an alternative to using the exists, which checks for yet another DNS record, simply set up differing subdomains with different rules. Although the same games are possible when referring to a EHLO domain list, I am philosophically opposed to expecting DNS queries to replace the domain's task of user authentication. DNS does not scale well enough to do this task iteratively, nor can these records grow to the extent needed to allow this range of exceptions. > Let's say big-company.com has an SPF record listing their main outgoing > mail servers, they can easily include supplementary records that would > list field-people posting from a given ISP server, or a local office > people using their own local SMTP server, etc. They could also setup a subdomain that adds this new domain. > This can be most useful in a number of situations. > > Does CSV have provisions for such a mechanism, or an equivalent ? CSV identifies the channel. This channel name can scale well if there is a desire to restrict mail fields. The manner these EHLO domains are referenced allows a great deal of flexibility. I would suggest a type of wildcard would find the TXT record, and within the TXT record would be a list of wildcarded names. DNS allows exceptions to a wildcard. This would mean that if there is a record for staff.big-bank.com, this record would be seen. If there is no record for staff but just a general record, then *.big-bank.com could return this query. > Now for the remark : I am strongly opposing to the idea of would-become- > mandatory "accreditation services". CSV does not require or mandate an accreditation service. This was added to allow for a large market of such services to help reduce the number of services inspected if to discovery an affiliation. > I'm opposing to it both for philosophical reasons, and practical reasons. > > First, "accreditation services" will turn into businesses, which will > translate into cost, which means that every domain that will want to send > mail out will have to support this new cost : having to pay a commercial > "accreditation" company to get listed there, if they want their mail to be > accepted. CSV allows each MTA to maintain their own name database. If it is a new name, offer highly reduced bandwidth. A simple scheme is used to control the bandwidth for cable users as example. This can regulate to any data rate without changing the content of the packet, without dropping packets, and requires only a very small amount of memory to achieve this. > This will introduce costs that many non-profit, personal or vany domains > will not be able to afford, and I oppose the idea that anybody should have > to pay a commercial company for being allowed to send mail. If you do not use such a service, you still benefit. BATV will help. There is nothing that requires anyone use an accreditation service. It is completely optional. > The advantage of current blacklist systems is that no one has to pay for > getting blacklisted ;-) and, if some blacklists are commercial, such as > MAPS, you need to pay to use and query them, not to be listed in them or > not... What? There is no relationship between a MAPS client and those that get listed. There are several large ISPs that would testify to that! The millions of dollars spent servicing legal defenses (never going anywhere) forced MAPS into a paid service. > Also, big companies that send large amounts of email will be well-know and > listed by most, if not all, accreditation services, where little domains, > small businesses and individuals that send a very small amout of mail will > mostly be "unknown" everywhere, and the acceptance of their mail might > suffer from this. > > IMHO, one should be deemed innocent until proved guilty, and the > "accreditation services" system turn the things upside-down : One will be > presumed guilty unless listed as innocent. Bad, bad, bad. > > The advantage of blacklists, on the opposite, is that, if ever you get > listed, there is probably a reason, and if you're not listed you're > presumed innocent. Much better. > > Comments ? There are companies that follow the whitelisting model. As a matter to reduce legal exposure, MAPS would like to change this to be a simple statement of past behavior, good or bad. The longer a domain exists without problems, the better the domain will look. The current DNA proposal does not reflect where I would hope this to be going. John has stated he is open to changes. This is an area that needs work. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 20:25: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 UAA25153 for ; Tue, 3 Aug 2004 20:25: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 i740AfW3013739; Tue, 3 Aug 2004 17:10: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 i740Afpm013738; Tue, 3 Aug 2004 17:10:41 -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 i740AeLK013730 for ; Tue, 3 Aug 2004 17:10:40 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 7454F28286 for ; Wed, 4 Aug 2004 02:10:45 +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 04927-01-2 for ; Wed, 4 Aug 2004 02:10:42 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id B3A2128290; Wed, 4 Aug 2004 02:10:42 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: IPR Disclosure for Sender-ID Date: Wed, 4 Aug 2004 02:10:42 +0200 User-Agent: KMail/1.6.1 References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <200408040034.08677@totor.bouissou.net> <3072.130.129.132.229.1091576957.squirrel@harry.mail-abuse.org> In-Reply-To: <3072.130.129.132.229.1091576957.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: <200408040210.42271@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 4 Août 2004 01:49, Douglas Otis a écrit : > > > > - Question : SPF currently has the extremely useful and flexible "exists" > > mechanism, that, combined with its built-in macro-expansion, allows for > > designing very fine-grained and flexible exceptions to the general SPF > > rule for a given domain, i.e. per user and subnet. > > If using CSV, any exceptions would be per hostname. As an alternative to > using the exists, which checks for yet another DNS record, simply set up > differing subdomains with different rules. [...] > They could also setup a subdomain that adds this new domain. When you buy a pair of shoes, do you actually look for shoes that fit right to your feet, of do you try to force your feet into a given pair ? A technical solution needs to fit with user needs. You can't ask a company "Oh, you just need to change the way your email system works, create a dozen of subdomains, change all of your email addresses, and print new business cards, and then it will be right for CSV". SPF allows a kind of flexibility that permits adapting the SPF records to the existing infrastructure, far better than having to adapt the infrastructure to fit the requirements of the new authentication system. If a MARID system (any flavour) necessitates that a number of domains have to change their infrastructure architecture significantly for using it, it will be a show-stopper. > > The advantage of current blacklist systems is that no one has to pay for > > getting blacklisted ;-) and, if some blacklists are commercial, such as > > MAPS, you need to pay to use and query them, not to be listed in them or > > not... > > What? There is no relationship between a MAPS client and those that get > listed. There are several large ISPs that would testify to that! The > millions of dollars spent servicing legal defenses (never going anywhere) > forced MAPS into a paid service. I never said that there was a relationship between MAPS clients and those that get listed. You completely misunderstood my meaning, or I didn't express myself clearly enough (sorry, english is not my language...). (Parenthese: BTW, my own perfectly static and never-spammed IP got listed by MAPS-DUL last month. It was unlisted within 24 hours after I complained, but it _did_ cause me trouble, and for all the users of the domains I manage as well. A friend's perfectly static IP (at the other end of France) got listed by MAPS-DUL the same day, but it took him more than a week to in the end get unlisted. He was really, but really, really pissed off with this. End of off-topic parenthese) -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 20:43:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26571 for ; Tue, 3 Aug 2004 20:43: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 i740UH6C015291; Tue, 3 Aug 2004 17:30: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 i740UHQS015290; Tue, 3 Aug 2004 17:30:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740UGu9015284 for ; Tue, 3 Aug 2004 17:30:16 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i740UJqZ025278; Tue, 3 Aug 2004 17:30:19 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Aug 2004 17:30:19 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: RE: How is SPF different from RMX? Date: Tue, 3 Aug 2004 17:30:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Wrong and misleading as well. I have given you a large number > of specific faults: (I'll summarize) > > 1) Abuser can forge addresses at domain This is a risk, not a specific threat. it appears that you are referring to the fact that forwarded mail can only authenticate to the last sender, not the original sender. This is an understood issue for which other controls are relevant. > 2) Abuser can use stolen credential This claim makes no sense whatsoever in the context of Sender-ID since there is no private key coresponding to the DNS record, there is no knowledge that can be stolen. The vulnerabilities to DNS and BGP spoofing are understood and are out of scope. > 3) DNS cache problems (more records per domain, same cache size) Irrelevant. > 4) DNS load (more records per domain) Irrelevant. > 5) Ongoing Maintenance issues Vague. > 6) Migration issues Vague and irrelevant. > 7) IP Renumbering issues Utterly irrelevant. > 8) Lost non-spam emails Not an issue, all Sender-ID does is to provide a means of whitelising good email, it is not a mechanism for rejecting bad emails, that > 9) Lack of universal compliance.* Uninterested. From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 20:53: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 UAA27331 for ; Tue, 3 Aug 2004 20:53: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 i740Yll2015533; Tue, 3 Aug 2004 17:34: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 i740YlHk015532; Tue, 3 Aug 2004 17:34:47 -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 i740Yk9Q015526 for ; Tue, 3 Aug 2004 17:34:46 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id E534628286 for ; Wed, 4 Aug 2004 02:34:51 +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 03687-07 for ; Wed, 4 Aug 2004 02:34:39 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 1DAF228290; Wed, 4 Aug 2004 02:34:39 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: IPR Disclosure for Sender-ID Date: Wed, 4 Aug 2004 02:34: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: <200408040234.38622@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 4 Août 2004 01:53, Harry Katz a écrit : > > As you know, Sender ID is the result of a merger of various elements of > SPF and Microsoft's Caller ID for E-mail proposal. Microsoft has filed > the IPR disclosure for Caller ID, and we will file a disclosure as soon > as we reasonably can - very shortly - for that portion of Sender ID > where Microsoft still has IPR to contribute, namely > draft-ietf-marid-core-02. On July 18, Harry Katz had written: > Thanks Bryce. I am drafting an FAQ to answer the questions that have > been raised. As I'm sure you can appreciate, this needs review and > approval by attorneys (plural) and other folk here. I hope to be able > to publish this FAQ to the list within the next few days. > > I understand and appreciate the questions people have been asking. Let > me just say at this point that our intent is to contribute our IP to > this working group and to encourage widespread implementation and > adoption. I very much appreciate everyone's patience while I gather the > answers to your questions. On July 15, Harry Katz had written: > These are good questions. I've added them to the list I'm working on > with our attorneys. On July 14, Harry Katz had written: > A perfectly reasonable request. I'm working with our attorneys now to > draft an answer. So what ? As Wayne noticed, August 2 was the deadline to have all IPR info to this sent to this list, yet we didn't see any. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 20:56: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 UAA27621 for ; Tue, 3 Aug 2004 20:56:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740avId015755; Tue, 3 Aug 2004 17:36:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i740avFw015754; Tue, 3 Aug 2004 17:36:57 -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 i740asu2015748 for ; Tue, 3 Aug 2004 17:36:56 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id C5E57E05D8; Tue, 3 Aug 2004 20:37:00 -0400 (EDT) Date: Tue, 3 Aug 2004 20:37:00 -0400 From: John Leslie To: Michel Bouissou Cc: IETF MARID WG Subject: Re: IPR Disclosure for Sender-ID Message-ID: <20040804003700.GB91949@verdi> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <3048.130.129.132.229.1091567945.squirrel@harry.mail-abuse.org> <200408040034.08677@totor.bouissou.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408040034.08677@totor.bouissou.net> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michel Bouissou wrote: > > About CSV, I have taken a quick look at the drafts (sorry, I haven't had > the time to read them thoroughly), and I have a question, and a remark : I prefer to answer the question privately: anyone else wanting my answer, feel free to ask. > Now for the remark : I am strongly opposing to the idea of would-become- > mandatory "accreditation services". I believe accreditation services are expected to be part of any MARID proposal, not just CSV, so I'll respond to this part on-list. > I'm opposing to it both for philosophical reasons, and practical reasons. > > First, "accreditation services" will turn into businesses, which will > translate into cost, which means that every domain that will want to send > mail out will have to support this new cost : having to pay a commercial > "accreditation" company to get listed there, if they want their mail to > be accepted. If there is any "mandate" to use accreditation services, it won't be coming from MARID. However, burying our heads in the sand won't help: At best, MARID can verify that a domain intends to authorize particular actions by MTAs: we can say nothing about whether this authorization gives the receiver good reason to trust that MTA. There must be accreditation services (by whatever name we call them) to provide that critical information link. CSV drafts discuss how to make accreditation scalable (and, IMHO, easier to live with). I don't believe the chairs ever inteded to stifle discussion of accreditation services; so I'm happy to discuss those issues on-list. Yes, there will be costs associated with getting accreditation services to (favorably) list you. I believe we can minimize those costs; and I believe we can make it possible for many domains to avoid even minimal costs, so long as they're "well-behaved". But I don't believe we can avoid accreditation services altogether. > This will introduce costs that many non-profit, personal or vanity > domains will not be able to afford, I specifically dispute that. Unless we do nothing at all _and_ an unlikely series of events all happen, nobody's going to be forced to register with one central expensive accreditation service. The horror of having to register with multiple expensive accreditation services can't (IMHO) get much worse than it already is. My recommendation, however, is to design scalable accreditation processes sooner, not later, so as to reduce the current horror of trying to get multiple "free" accreditation services to de-list you. > and I oppose the idea that anybody should have to pay a commercial > company for being allowed to send mail. Conceivably, Michel would actually prefer to spend time trying to convince a swarm of "free" services to de-list an IP range, rather than to pay a few dollars to one accreditation service. Personally, I doubt that's the majority opinion... > The advantage of current blacklist systems is that no one has to pay > for getting blacklisted ;-) and, if some blacklists are commercial, > such as MAPS, you need to pay to use and query them, not to be listed > in them or not... (I'm not clear who is "advantaged" by this.) > Also, big companies that send large amounts of email will be well-known > and listed by most, if not all, accreditation services, To the extent they pay for it, yes. Currently, most accreditation services only list large companies if they behave poorly. There's essentially no business case for charging to de-list them: it opens you to too many lawsuits; instead the best business practice is to make yourself hard to find -- thus, de-listing is "free" but nearly impossible. :^( > where little domains, small businesses and individuals that send a > very small amount of mail will mostly be "unknown" everywhere, and > the acceptance of their mail might suffer from this. From what I know of MAPS, they're capable of handling millions of domains with low (but non-zero) email volume, and reacting quickly to just those domains that become the source of problems; and their business case isn't based on charging either for initial listing _or_ for de-listing. I see no reason other accreditation services wouldn't build similar business plans. I discuss this issue in the CSV FAQ at: http://www.jlc.net/MARID/CSV/FAQ.html > IMHO, one should be deemed innocent until proved guilty, and the > "accreditation services" system turn the things upside-down : One > will be presumed guilty unless listed as innocent. Bad, bad, bad. I don't see that kind of "accreditation service" as useful -- though I agree it's going to happen. I believe we can best avoid it by offering a better alternative. > The advantage of blacklists, on the opposite, is that, if ever you > get listed, there is probably a reason, Evidently, Michel hasn't experienced blacklisting as I have. Indeed, there probably "is" a reason; but that doesn't mean anyone will ever be able to tell you what the reason is -- and even if they do, it's often something over which you have zero control. > and if you're not listed you're presumed innocent. Much better. Much better for spammers, yes. I won't give you "much better" for innocent domains, however, since you never know when you may get listed somewhere and you usually won't know what to do about it when it happens. At most, it's "temporarily better" for innocent parties... -- John Leslie From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 21:03: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 VAA27955 for ; Tue, 3 Aug 2004 21:03: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 i740lou9016666; Tue, 3 Aug 2004 17:47:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i740lohX016665; Tue, 3 Aug 2004 17:47:50 -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 i740lnOe016657 for ; Tue, 3 Aug 2004 17:47:49 -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 i740tbRo029155; Tue, 3 Aug 2004 17:55:37 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i740taDN029152; Tue, 3 Aug 2004 17:55:36 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 3 Aug 2004 17:55:36 -0700 (PDT) From: "william(at)elan.net" To: Harry Katz cc: Andrew Newton , John Glube , Ted Hardie , Mark Lentczner , IETF MARID WG Subject: RE: IPR Disclosure for Sender-ID In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 3 Aug 2004, Harry Katz wrote: > As you know, Sender ID is the result of a merger of various elements of > SPF and Microsoft's Caller ID for E-mail proposal. Microsoft has filed > the IPR disclosure for Caller ID, and we will file a disclosure as soon > as we reasonably can - very shortly - for that portion of Sender ID > where Microsoft still has IPR to contribute, namely > draft-ietf-marid-core-02. Is this my understanding then that previous IPR is no longer valid now as it applies to new versions of MARID draffts and thus should be considered to have expired (or will expire along with original drafts)? Is Microsoft failure to file IPR so far (considering its not really a very large "paper" to write) has something to do with that Microsoft is not certain if the remaining portion of the MARID core still falls under your pending patent? If it becomes an issue with our schedule and that we need to move forward (i.e. that draft document has to be sent to RFC editor, this is fast working WG after all) is Microsoft willing to leave with situation that failure to file IPR by certain date will constitute de-facto agreement that resuling MARID work is not covered by any Microsoft patents? If IPR is filed, there is certain portion of constituency that expressed opinion that existing terms of Microsoft Caller-ID license are not acceptable because they conflict with requirements of some open-source licenses and if this continues to be the case, these people may want to block curent MARID documents document during last call in order to review them on if we can provide similar proposal that does not have any IPR claims. So it would be helpfull to have Microsoft IPR before any last-call dates so that we at least could have some discussion and it would be helpfull if Microsoft considers changing license terms to be compatible with all major open-source licenses. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 21:20:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28967 for ; Tue, 3 Aug 2004 21:20: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 i7418t5E018326; Tue, 3 Aug 2004 18:08:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7418tkW018325; Tue, 3 Aug 2004 18:08:55 -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 i7418r6m018309 for ; Tue, 3 Aug 2004 18:08:54 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 53F9428286 for ; Wed, 4 Aug 2004 03:08:59 +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 05552-01-2 for ; Wed, 4 Aug 2004 03:08:55 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 7CB5928290; Wed, 4 Aug 2004 03:08:55 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: IPR Disclosure for Sender-ID Date: Wed, 4 Aug 2004 03:08:55 +0200 User-Agent: KMail/1.6.1 References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <200408040034.08677@totor.bouissou.net> <20040804003700.GB91949@verdi> In-Reply-To: <20040804003700.GB91949@verdi> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200408040308.55135@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 4 Août 2004 02:37, John Leslie a écrit : > > If there is any "mandate" to use accreditation services, it won't be > coming from MARID. However, burying our heads in the sand won't help: > At best, MARID can verify that a domain intends to authorize particular > actions by MTAs: we can say nothing about whether this authorization > gives the receiver good reason to trust that MTA. > > There must be accreditation services (by whatever name we call them) > to provide that critical information link. Do we actually need to have "good reasons to trust a MTA" to start accepting mail from it, or do we barely need to be able to stop accepting mail from ill-behaved domains once they're flagged as "bad" ? The current major problem with spam comes from the zombies everywhere, and the systematically forged Return-Path, From: and Received: headers. Once we have a system that ensures that mail is not forged, and comes from a MTA that is authorized by the domain to which it belongs, I believe we have enough. If this domain is ill-behaved, it will rather soon get blacklisted at spamhaus.org, ROKSO, (put the name of your favourite spam-operations blacklist here), and we can soon stop accepting mail from it. I don't believe that spammers can eternally keep on purchasing tens of throw-away domains and change hosting or "their legitimate spam-sending servers" everyday. In this regard, reactive blacklists seems to me to be more useful than "accreditation services". > Yes, there will be costs associated with getting accreditation services > to (favorably) list you. I believe we can minimize those costs; and I > believe we can make it possible for many domains to avoid even minimal > costs, so long as they're "well-behaved". Hummm... I think we yet have to see this. And I sincerely wonder if every little business and shop-around-the-corner will get its domain listed by such "accreditation services". If they don't (and they mostly won't), then accreditation services won't be of that much use, as you will never be able to reject mail from all-the-domains- that-are-not-listed, just as today it is impractical to reject mail from all the MTAs which doesn't have any PTR in-addr record. > But I don't believe we can avoid accreditation services altogether. > > > This will introduce costs that many non-profit, personal or vanity > > domains will not be able to afford, > > I specifically dispute that. Unless we do nothing at all _and_ an > unlikely series of events all happen, nobody's going to be forced to > register with one central expensive accreditation service. The horror > of having to register with multiple expensive accreditation services > can't (IMHO) get much worse than it already is. ? > > and I oppose the idea that anybody should have to pay a commercial > > company for being allowed to send mail. > > Conceivably, Michel would actually prefer to spend time trying to > convince a swarm of "free" services to de-list an IP range, rather than > to pay a few dollars to one accreditation service. Personally, I doubt > that's the majority opinion... The best would be not to be listed at all ;-) I already have lost some hours a couple of times trying to get delisted, sometimes from some ISPs "internal" blacklists that had listed a complete /16 or the like, and usually, being polite and professional is enough to succeed quickly. Blacklists that keep you listed for no reason and refuse to delist you forever, yes, there are some (check my IP at openrbl.org, you'll find ONE that keeps a /16 listed and refuses to hear about delisting innocents), but such unprofessional blacklists are seldom used by serious companies for mail filtering. > > IMHO, one should be deemed innocent until proved guilty, and the > > "accreditation services" system turn the things upside-down : One > > will be presumed guilty unless listed as innocent. Bad, bad, bad. > > I don't see that kind of "accreditation service" as useful -- > though I agree it's going to happen. I believe we can best avoid it > by offering a better alternative. ...which would be...? > > The advantage of blacklists, on the opposite, is that, if ever you > > get listed, there is probably a reason, > > Evidently, Michel hasn't experienced blacklisting as I have. As you have, I don't know, but yes, and enough for me anyway ;-) -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 21:22:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29097 for ; Tue, 3 Aug 2004 21:22:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7414J9n017849; Tue, 3 Aug 2004 18:04: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 i7414JlN017848; Tue, 3 Aug 2004 18:04:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from dns.zenatech.com ([208.44.124.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7414IFF017834 for ; Tue, 3 Aug 2004 18:04:18 -0700 (PDT) (envelope-from tek@spamacid.net) Received: from dttp2 (loubnan.com [208.44.124.221]) (authenticated (0 bits)) by dns.zenatech.com (8.12.10/8.11.10) with ESMTP id i744Ilf0019425 for ; Wed, 4 Aug 2004 00:18:48 -0400 Message-Id: <200408040418.i744Ilf0019425@dns.zenatech.com> Reply-To: From: "Tek" To: "'IETF MARID WG'" Subject: RE: Will there be video of the MARID sessions? Date: Tue, 3 Aug 2004 21:04:22 -0400 Organization: Safe E Messaging, LLC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4.3.2.7.2.20040803153731.042cd770@mira-sjc5-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR5yI7VMbpAFJWVTOe1QpDQoME6VgAChNIQ Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > On http://www.ietf.org/meetings/agenda_60.html it doesn't > have a star next to the session name, indicating a multicast > session, so I suspect not. Actually, I've contacted the recording folks earlier and, as evidenced by the email below, the first session is scheduled now for a multicast room. Hence, it will be available on multicast. As for the other session, they will attempt (aka try their best, but may still not be able) to record it and make it available online along with the rest of the IETF sessions (later on). Thank you Marcia and Joel. -Tek -----------cut------------cut-----------cut------------- > From: Marcia Beaulieu [mailto:mbeaulie@foretec.com] > Sent: Tuesday, July 13, 2004 5:28 PM > To: Tek > Cc: Joel Jaeggli; Marcia Beaulieu > Subject: Re: multicast: IETF 60 in San Diego (fwd) > > Tek, > > I just noticed my typo on my message regarding Marid. > > Marid is NOW scheduled to be in a multicast room! I was only able to > put the 0930 session in multicast, not the second session at 1530, two > groups had already requested to be in the multicast room. > > Marcia From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 21:53: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 VAA00882 for ; Tue, 3 Aug 2004 21:53: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 i741gbSR022834; Tue, 3 Aug 2004 18:42: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 i741gbhP022833; Tue, 3 Aug 2004 18:42: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 i741gbuB022823 for ; Tue, 3 Aug 2004 18:42:37 -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 A8E68414B7; Tue, 3 Aug 2004 18:42:38 -0700 (PDT) Received: from 130.129.132.229 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Tue, 3 Aug 2004 18:42:38 -0700 (PDT) Message-ID: <3050.130.129.132.229.1091583758.squirrel@harry.mail-abuse.org> In-Reply-To: <200408040210.42271@totor.bouissou.net> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <200408040034.08677@totor.bouissou.net> <3072.130.129.132.229.1091576957.squirrel@harry.mail-abuse.org> <200408040210.42271@totor.bouissou.net> Date: Tue, 3 Aug 2004 18:42:38 -0700 (PDT) Subject: Re: IPR Disclosure for Sender-ID 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 mercredi 4 Août 2004 01:49, Douglas Otis a écrit : >> > >> > - Question : SPF currently has the extremely useful and flexible >> > "exists" mechanism, that, combined with its built-in macro-expansion, >> > allows for designing very fine-grained and flexible exceptions to the >> > general SPF rule for a given domain, i.e. per user and subnet. >> >> If using CSV, any exceptions would be per hostname. As an alternative >> to using the exists, which checks for yet another DNS record, simply set >> up differing subdomains with different rules. [...] > >> They could also setup a subdomain that adds this new domain. > > When you buy a pair of shoes, do you actually look for shoes that fit > right to your feet, of do you try to force your feet into a given pair ? > > A technical solution needs to fit with user needs. You can't ask a company > "Oh, you just need to change the way your email system works, create a > dozen of subdomains, change all of your email addresses, and print new > business cards, and then it will be right for CSV". You are referring to a desire to restrict the use of an address to their servers. This may be good for a large enterprise such as a bank wishing to constrain where these messages may emerge. This restriction depends upon the receiving MTA checking for this request, or it means nothing. The normal use of mail today does not offer this restriction. Whether there is such a constraint, making the EHLO domain visible would still be helpful in guarding against spoofing. The feet needing shoes do not wish to have a nail poking them in the heel. SPF or Sender-ID puts a burden upon those using mail in a normal fashion. That would be sending mail without regard to the point of access. SPF or Sender-ID allows this mode, but at a high cost. Domains not imposing this new restriction should then expect their DNS record to be used as a spam exploit. If big-bank.com wants to have exceptions to this rule, then yes, I am suggesting this be done by using a subdomain. I would not expect a mail list name would need to appear on someone's business card. > SPF allows a kind of flexibility that permits adapting the SPF records to > the existing infrastructure, far better than having to adapt the > infrastructure to fit the requirements of the new authentication system. SPF and Sender-ID breaks forwarding as example. Sender-ID decided to limit the time these extensions may cause, but this solution ignores the UDP exponential back-off requirement. DNS records must be constrained and not allowed to grow to such an extent. One or two sequential lookups per message is far better than hundreds as now defined. SPF limited recursion and not the number. For a very brief period, Sender-ID limited the number of queries. This is out of control, in my opinion. If big-bank.com wants to have different rules for different users, giving these users a different subdomain is not asking to much. SPF and Sender-ID want all forwarding and "exploding" list servers to change. That is a shoe that does not fit. > If a MARID system (any flavour) necessitates that a number of domains have > to change their infrastructure architecture significantly for using it, it > will be a show-stopper. You are describing the effect of imposing a restriction on a domain, but are then unhappy with problems this restriction may cause. It seems fair to have those making the changes, endure the impact. Sender-ID and SPF impose their change on others, and ask domains, without any desire to make these restrictions, to suffer. Employing CSV and making a visible "Mailer-ID" will not impact anyone, but will stop spoofing, phishing, and curtail Trojans. That can not be said of Sender-ID or SPF. Frankly, any large enterprise that wants to nail down where their emails emerge should also have VPN to allow these messages to come from the machines they designate. >> > The advantage of current blacklist systems is that no one has to pay >> > for getting blacklisted ;-) and, if some blacklists are commercial, >> > such as MAPS, you need to pay to use and query them, not to be listed >> > in them or not... >> >> What? There is no relationship between a MAPS client and those that get >> listed. There are several large ISPs that would testify to that! The >> millions of dollars spent servicing legal defenses (never going >> anywhere) forced MAPS into a paid service. > > I never said that there was a relationship between MAPS clients and those > that get listed. You completely misunderstood my meaning, or I didn't > express myself clearly enough (sorry, english is not my language...). There is no relationship with those that don't as well. > (Parenthese: > BTW, my own perfectly static and never-spammed IP got listed by MAPS-DUL > last month. It was unlisted within 24 hours after I complained, but it > _did_ cause me trouble, and for all the users of the domains I manage as > well. A friend's perfectly static IP (at the other end of France) got > listed by MAPS-DUL the same day, but it took him more than a week to in > the end get unlisted. He was really, but really, really pissed off with > this. > End of off-topic parenthese) Yes, vetting by address sucks in a big way. I will say that the DUL list is responsible for stopping the majority of the abuse, but is also responsible for much of our service overhead. The information we get from ISPs is not always perfect. Many don't know what is assigned. The CSV approach would not step on the toes of the innocent as does address blacklisting addresses. Blacklisting, as will CSV, curtails spam. Proponents of Sender-ID must not claim to provide a reduction in spam, spoofing, or phishing. CSV can provide a reduction in spam, phishing, and spoofing, without any additional records added to impose domain restrictions. Just show the user the and that would be a world of improvement over today's problems. It would not require any changes to anyone's use of mail, as does Sender-ID. If you wish to add the ability to contrain what EHLO can post a From domain, then those making this change may need to do things a bit differently, but that is only fair. These records will never become a spam exploit as will Sender-ID or SPF records. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 22:01: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 WAA01205 for ; Tue, 3 Aug 2004 22:01: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 i741m33t023085; Tue, 3 Aug 2004 18:48: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 i741m3KD023084; Tue, 3 Aug 2004 18:48:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts36-srv.bellnexxia.net (tomts36.bellnexxia.net [209.226.175.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i741m23t023077 for ; Tue, 3 Aug 2004 18:48:02 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040804014805.CGEG4787.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd>; Tue, 3 Aug 2004 21:48:05 -0400 From: "John Glube" To: "'IETF MARID WG'" Cc: "'Meng Weng Wong'" , "'Mark Lentczner'" , "'Harry Katz'" , "'Jim Lyon'" , "'Hallam-Baker, Phillip'" , "'Dave Crocker'" , "'Carl S. Gutekunst'" Subject: A suggestion concerning Sender-ID/Submitter Date: Tue, 3 Aug 2004 21:50:04 -0400 Message-ID: <000001c479c5$5d1d3550$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: <0469C730-E596-11D8-A694-000393A56BB6@glyphic.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 i741m23t023079 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Based on some questions I asked Andy earlier today, it seems the WG is entitled to reasonably presume MS is asserting: (i) a defensive patent over the PRA algorithm; and (ii) will require software developers who wish to implement this algorithm to enter into a royalty free license: http://www.imc.org/ietf-mxcomp/mail-archive/msg02984.html The license form is found at: http://download.microsoft.com/download/6/0/a/60a02573-3c00-4ee1-8 56b-afa39c020a95/callerid_license.pdf On July 26, 2004, Phillip Hallam-Baker wrote in response to a post by Richard Stallman: "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." http://www.imc.org/ietf-mxcomp/mail-archive/msg02843.html Since nothing new was filed by 02.08.04: * Is their any room left for the Unified Theory which Meng eloquently put to the SPF discuss list? Under this approach, and applying it to where we are today, SPF would be the protocol used by senders to publish their sender policy. Receivers could then use this data to authenticate domains based on SPF/SRS, CSV/CSA/DNA or Sender ID/Submitter. (I appreciate this would require some work with the existing drafts.) * Unified Marid could then become a draft protocol, broken out into its component parts. One standard for senders. Three standards for receivers. On 19.07.04 David Crocker wrote in response to a post by Margaret Olson: "There is an ietf movement to get cross-area reviews early in the specification process. This is intended to uncover significant design and operations issues quickly. 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 http://graybeards.net/sirs/index.html." http://www.imc.org/ietf-mxcomp/mail-archive/msg02751.html To date there has been no uptake on Dave's suggestion. To supplement the Unified approach, would it make sense for the WG to have a senior IETF review of SPF as the sender standard, along with a review of SPF/SRS and Sender-ID/Submitter as receiving standards on an expedited basis? (I have excluded CSV/CSA/DNA as it is my understanding from follow up posts by Dave this review is already underway and may now be complete.) * By taking this approach, instead of outright rejecting Sender-ID/Submitter, it would leave receivers free to adopt that protocol which best suits their specific needs. The open source community and those portions of the corporate sector which found the MS license requirement incompatible with their needs could proceed forward on the receiving side with SPF/SRS or CSV/CSA/DNA. Those who were willing to accept the MS license could proceed on the receiving side with Sender-ID/Submitter. Using SPF as the unifying standard for senders would avoid fragmentation while leaving receivers free to choose that protocol which best suits their needs. I appreciate the WG meeting at the 60th IETF is scheduled for tomorrow. Also, I acknowledge time is very short. However, is it not better to have all hands in the same tent? I put forward these suggestions to facilitate discussion at the meeting. John P.S. I would love to be at the meeting. However, unfortunately for personal reasons I am stuck here in Toronto. So, best wishes to all. Cheers, John cc. Meng, Mark, Harry, Jim, Dave, Phillip, Carl 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.729 / Virus Database: 484 - Release Date: 27/07/2004 From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 23:05: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 XAA05805 for ; Tue, 3 Aug 2004 23:05: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 i742oNpP027313; Tue, 3 Aug 2004 19:50: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 i742oNh8027312; Tue, 3 Aug 2004 19:50:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i742oMVw027306 for ; Tue, 3 Aug 2004 19:50:22 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i742vr8n032030; Tue, 3 Aug 2004 19:57:53 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i742vrY1032027; Tue, 3 Aug 2004 19:57:53 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 3 Aug 2004 19:57:53 -0700 (PDT) From: "william(at)elan.net" To: John Glube cc: "'IETF MARID WG'" , "'Meng Weng Wong'" , "'Mark Lentczner'" , "'Harry Katz'" , "'Jim Lyon'" , "'Hallam-Baker, Phillip'" , "'Dave Crocker'" , "'Carl S. Gutekunst'" Subject: Re: A suggestion concerning Sender-ID/Submitter In-Reply-To: <000001c479c5$5d1d3550$6c62fea9@ibmrkydk2ufvdd> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm in complete agreement with what John just wrote. I believe we should proceed with Unified SPF and allow for senders and receivers to decide which identities they want to provide email policy records for. Each identity should be defined in its own IETF document and if there are any IPR claims for certain identity and licensing is not acceptable to publisher or to recepient, then they don't have to verify that identity. On Tue, 3 Aug 2004, John Glube wrote: > > Based on some questions I asked Andy earlier today, it seems > the WG is entitled to reasonably presume MS is asserting: > (i) a defensive patent over the PRA algorithm; and (ii) will > require software developers who wish to implement this > algorithm to enter into a royalty free license: > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02984.html > > The license form is found at: > > http://download.microsoft.com/download/6/0/a/60a02573-3c00-4ee1-8 > 56b-afa39c020a95/callerid_license.pdf > > On July 26, 2004, Phillip Hallam-Baker wrote in response to > a post by Richard Stallman: > > "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." > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02843.html > > Since nothing new was filed by 02.08.04: > > * Is their any room left for the Unified Theory which Meng > eloquently put to the SPF discuss list? > > Under this approach, and applying it to where we are today, > SPF would be the protocol used by senders to publish their > sender policy. Receivers could then use this data to > authenticate domains based on SPF/SRS, CSV/CSA/DNA or Sender > ID/Submitter. > > (I appreciate this would require some work with the existing > drafts.) > > * Unified Marid could then become a draft protocol, broken > out into its component parts. One standard for senders. > Three standards for receivers. > > On 19.07.04 David Crocker wrote in response to a post by > Margaret Olson: > > "There is an ietf movement to get cross-area reviews early > in the specification process. This is intended to uncover > significant design and operations issues quickly. > > 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 > http://graybeards.net/sirs/index.html." > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02751.html > > To date there has been no uptake on Dave's suggestion. > > To supplement the Unified approach, would it make sense for > the WG to have a senior IETF review of SPF as the sender > standard, along with a review of SPF/SRS and > Sender-ID/Submitter as receiving standards on an expedited > basis? > > (I have excluded CSV/CSA/DNA as it is my understanding from > follow up posts by Dave this review is already underway and > may now be complete.) > > * By taking this approach, instead of outright rejecting > Sender-ID/Submitter, it would leave receivers free to adopt > that protocol which best suits their specific needs. > > The open source community and those portions of the > corporate sector which found the MS license requirement > incompatible with their needs could proceed forward on the > receiving side with SPF/SRS or CSV/CSA/DNA. > > Those who were willing to accept the MS license could > proceed on the receiving side with Sender-ID/Submitter. > > Using SPF as the unifying standard for senders would avoid > fragmentation while leaving receivers free to choose that > protocol which best suits their needs. > > I appreciate the WG meeting at the 60th IETF is scheduled > for tomorrow. Also, I acknowledge time is very short. > > However, is it not better to have all hands in the same > tent? > > I put forward these suggestions to facilitate discussion > at the meeting. > > John > > P.S. I would love to be at the meeting. However, > unfortunately for personal reasons I am stuck here in > Toronto. So, best wishes to all. Cheers, John > > cc. Meng, Mark, Harry, Jim, Dave, Phillip, Carl > > 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.729 / Virus Database: 484 - Release Date: 27/07/2004 From owner-ietf-mxcomp@mail.imc.org Tue Aug 3 23:16:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06621 for ; Tue, 3 Aug 2004 23:16:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7435XPI028793; Tue, 3 Aug 2004 20:05: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 i7435X5s028792; Tue, 3 Aug 2004 20:05:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7435XAS028786 for ; Tue, 3 Aug 2004 20:05:33 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i743DPwd032400; Tue, 3 Aug 2004 20:13:25 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i743DOaZ032397; Tue, 3 Aug 2004 20:13:25 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 3 Aug 2004 20:13:24 -0700 (PDT) From: "william(at)elan.net" To: Dean Anderson cc: "Hallam-Baker, Phillip" , IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 3 Aug 2004, Dean Anderson wrote: > My apologies. Everyting that is obvious to me isn't obvious to everyone. I suspect many here who are not subscribed to main and some other ietf lists can't imagine how much this sentence is applicable in reverse (replace "is" with "isnt" and other way around) to many of the posts I've seen from Dean Anderson. Sorry for OT and of course "My apologies" P.S. For the future lets not use "everything" and "obvious" in statements or even just in same sentence. There would not be so many discussions on this list if everything was so obvious :) --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 00:39: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 AAA10560 for ; Wed, 4 Aug 2004 00:39: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 i744KZiD034225; Tue, 3 Aug 2004 21:20: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 i744KZY0034224; Tue, 3 Aug 2004 21:20:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts36-srv.bellnexxia.net (tomts36.bellnexxia.net [209.226.175.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i744KXTe034218 for ; Tue, 3 Aug 2004 21:20:34 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040804042039.EJLD4787.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd>; Wed, 4 Aug 2004 00:20:39 -0400 From: "John Glube" To: "'Harry Katz'" , "'Andrew Newton'" , "'IETF MARID WG'" Cc: "'Ted Hardie'" , "'Mark Lentczner'" , "'Hallam-Baker, Phillip'" Subject: RE: IPR Disclosure for Sender-ID Date: Wed, 4 Aug 2004 00:22:37 -0400 Message-ID: <000001c479da$ad1e6be0$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 i744KYTe034219 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Harry, I appreciate the awkward position MS finds itself in. The Sender-ID protocol remains a work in progress. Therefore, since it is unclear whether MS will have IPR to contribute or not at the end of the day, you suggest the WG needs to wait until the product is finished before MS makes a formal claim, if any. However, unfortunately, this kind of leaves the WG in the position of "Does she love me or does she love me not? That is the question." Why do I say this? It goes back to the license form which comes with the IPR. It seems the license form put forward by MS is an anathema to many in the WG. See as an example the post made by Phillip on 26.07.08, when he wrote: "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." http://www.imc.org/ietf-mxcomp/mail-archive/msg02843.html In fairness, the guidance we had this morning was: "The WG can reasonably presume MS is claiming a defensive patent on Sender-ID and will ask for a license in the form found at Microsoft's site." (I am summarizing.) The chair also indicated a discussion of the license would remain on the agenda. I suggest the questions now before the WG are: * Since MS did not file anything further by August 2, 2004 and as it is reasonable to make the presumption as suggested by the chair there is an IPR claim, with no proposal for a revised license from MS, should the WG simply reject Sender-ID? (I reference Phillip's post, since he states the position was put to MS, "play now or forget it," with the date for playing being August 2, 2004. I acknowledge Phillip is one individual and so the issue remains open.) * MS now says "we don't know whether we will have any IPR to contribute until we know the final form of Sender-ID. Therefore, let's proceed with further work on Sender-ID and when we see the final form, MS can file any appropriate IPR with the license request." From what I have read, subject to the position put by Phillip being formally adopted by the WG, I don't see Sender-ID proponents agreeing to drop the PRA algorithm, although it could be removed from Sender-ID as per Carl's suggestion and put into a separate draft. http://www.imc.org/ietf-mxcomp/mail-archive/msg02905.html Presumably this decision can be made at the WG meeting in the morning. If it is accepted, then MS can tell the WG, we no longer have an IPR claim viz Sender-ID and Sender-ID nee SPF can move forward. If it is decided to not remove the PRA algorithm from Sender-ID, then MS knows the position and can make its IPR claim. In turn, the WG can make its response and all of this can happen at the meeting. Besides, is it appropriate to go through the exercise of doing all the work and then finding out, yes MS is claiming IPR and a license and the WG then responding "forget it as the license is unacceptable." In other words, unless the PRA algorithm is moved to its own draft protocol, the WG and MS remain confronted with the issue as noted above by Phillip, either "play now or forget it" with the deadline for playing now originally having been August 2, 2004. Do not misunderstand me. I am not trying to make life difficult. But, I suggest MS put its cards on the table by not filing anything further on August 2, 2004. Before proceeding further down the Sender-ID road, I suggest the WG needs to respond. The existing uncertainty affects decision making by those who are considering sender authentication. As an example, I can't make a recommendation to a group of business owners who are primarily online newsletter publishers along with a number of 3rd party permission based email service providers, sellers of web hosting and the like and then find out "oh gee sorry, Sender-ID and Submitter are now off the table. Forget SPF as the sender standard, the protocol is CSV. The time and expense you went through, it’s a waste." In the meantime, time is marching on. Some receivers have started doing SPF checks. Other receivers have suggested they will be starting to make checks in the early fall. Open source filters are starting to include SPF checks. Many business people want to get moving, but ... with this cloud hanging over the situation, it makes it very difficult to make a prudent business decision. The solution? The WG can say to MS: * "Thanks but no thanks," or, * Move the PRA to its own draft (so side stepping the license issue and the related concerns), let Sender-ID nee SPF proceed as the tracking standard without any IPR claim from MS and if folks want to be really brave otherwise incorporate the following proposal: http://www.imc.org/ietf-mxcomp/mail-archive/msg03007.html Trusting these suggestions help to resolve the situation and move the issue forward. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html -----Original Message----- From: Harry Katz [mailto:hkatz@exchange.microsoft.com] Sent: August 3, 2004 7:54 PM To: Andrew Newton; John Glube Cc: Ted Hardie; Mark Lentczner; IETF MARID WG Subject: RE: IPR Disclosure for Sender-ID As you know, Sender ID is the result of a merger of various elements of SPF and Microsoft's Caller ID for E-mail proposal. Microsoft has filed the IPR disclosure for Caller ID, and we will file a disclosure as soon as we reasonably can - very shortly - for that portion of Sender ID where Microsoft still has IPR to contribute, namely draft-ietf-marid-core-02. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.729 / Virus Database: 484 - Release Date: 27/07/2004 From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 04:59: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 EAA19626 for ; Wed, 4 Aug 2004 04:59:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i748kf9T025308; Wed, 4 Aug 2004 01:46: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 i748kfBp025307; Wed, 4 Aug 2004 01:46:41 -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 i748kcJK025281 for ; Wed, 4 Aug 2004 01:46:40 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39707) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1BsHPu-0001yI-P8 for ietf-mxcomp@imc.org; Wed, 04 Aug 2004 09:46:34 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BsHPu-0003wy-FS; Wed, 04 Aug 2004 09:46:34 +0100 Date: Wed, 4 Aug 2004 09:46:34 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 2 Aug 2004, Hallam-Baker, Phillip wrote: > > I have asked repeatedly for a specific fault in Sender-ID. The only response > that has been given is a repeat of the vague claim that the protocol is > flawed and cannot work. http://www.imc.org/ietf-mxcomp/mail-archive/msg02817.html http://www.imc.org/ietf-mxcomp/mail-archive/msg02818.html 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 Wed Aug 4 10:05:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06385 for ; Wed, 4 Aug 2004 10:05: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 i74DmCWb079402; Wed, 4 Aug 2004 06:48:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74DmCEh079401; Wed, 4 Aug 2004 06:48:12 -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 i74Dm9Zh079393 for ; Wed, 4 Aug 2004 06:48:10 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BsM7m-00045Z-00 for ; Wed, 04 Aug 2004 15:48:10 +0200 Received: from a064106.dialin.hansenet.de ([213.191.64.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Aug 2004 15:48:10 +0200 Received: from nobody by a064106.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Aug 2004 15:48:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: SPF/FROM-HDR (was: IPR Disclosure for Sender-ID) Date: Wed, 04 Aug 2004 15:42:36 +0200 Organization: Lines: 47 Message-ID: <4110E7CC.5796@xyzzy.claranet.de> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us> <3056.130.129.132.229.1091551103.squirrel@harry.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: a064106.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote in mxcomp (MARID): > http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt That's the first time I see this. It's not on the page with the MARID drafts (see ), it's not on , IIRC it was not published on the SPF announce list, and if it was mentioned on the SPF-discuss list I must have missed it: | Comments on this draft are welcome. In the interests of | openness, before contacting the authors directly, please | post to the spf-discuss mailing list. The date says July 12 2004. The algorithm is incompatible with SPF classic, therefore it cannot be used with existing v=spf1 sender policies. | There are no changes in semantics to existing protocols That's not true. IP okay for xyzzy: SPF classic SPF/FROM-HDR MAIL FROM: PASS PASS only if whitelisted 2822 From: don't care (FAIL => test MAIL FROM) IP not okay for xyzzy: SPF classic SPF/FROM-HDR MAIL FROM: UNKNOWN (UNKNOWN in step 3) 2822 From: don't care FAIL (step 5) IP okay for spam@test: SPF classic SPF/FROM-HDR MAIL FROM: FAIL don't care 2622 From: don't care PASS (step 1) I'm not really interested in the 1st example, because I don't use arbitrary 2822 From headers with a SPF-protected MAIL FROM. But the 2nd example is real and almost the same problem as with Sender-Id. In fact it's even worse because Sender-Id at least allowed to use a matching Sender: to bypass its 2822 From:-test. And the 3rd example is evil, SPF/FROM-HDR results in a PASS, but the bounce for this spam is later sent to a 3rd party (?) What's the purpose of step 2 spf_test(To:,IP) ? Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 11:17:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11113 for ; Wed, 4 Aug 2004 11:17:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74F40Ar085322; Wed, 4 Aug 2004 08:04: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 i74F40MG085321; Wed, 4 Aug 2004 08:04:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74F3xnM085313 for ; Wed, 4 Aug 2004 08:03:59 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BsNIw-0000ds-8g for ietf-mxcomp@imc.org; Wed, 04 Aug 2004 10:03:58 -0500 To: "IETF MARID WG" References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us> <3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> <4110E7CC.5796@xyzzy.claranet.de> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 04 Aug 2004 10:03:46 -0500 In-Reply-To: <4110E7CC.5796@xyzzy.claranet.de> (Frank Ellermann's message of "Wed, 04 Aug 2004 15:42:36 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: SPF/FROM-HDR (was: IPR Disclosure for Sender-ID) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.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 <4110E7CC.5796@xyzzy.claranet.de> Frank Ellermann writes: > wayne wrote in mxcomp (MARID): > >> http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt > > That's the first time I see this. It's not on the page with > the MARID drafts (see ), > it's not on , IIRC it was not > published on the SPF announce list, and if it was mentioned on > the SPF-discuss list I must have missed it: This I-D is not on the page of MARID drafts because it is not an official MARID document. You are correct that it wasn't announce anywhere. This I-D is part of the "Unified-SPF" group of I-Ds that Meng et al talked about publishing several weeks back. It was decided that that the Unified-SPF I-Ds should be delayed until after the work from this group had progressed a little further. Unfortunately, due to some miscommunication, I didn't hear about the decision to delay until after I had already submitted the Unified-SPF/From: draft. Since only two parts of the Unified-SPF I-Ds have been published (the marid-protocal I-D and the Unified-SPF/From: I-D), none of us have made a big deal over the existence of the Unified-SPF/From: I-D. I mentioned it in response to Doug's post simply to point out that his general idea has been talked about quite a bit and, in fact, work has already progressed on the idea of checking only the From: header and whitelisting exceptions. > | Comments on this draft are welcome. In the interests of > | openness, before contacting the authors directly, please > | post to the spf-discuss mailing list. > > The date says July 12 2004. The algorithm is incompatible with > SPF classic, therefore it cannot be used with existing v=spf1 > sender policies. The Unified-SPF/From: algorithm is not intended to replace the SPF-classic algorithm (Unified-SPF/MAILFROM). I think that Meng, Mark and I are all of the opinion that existing SPF records can be used with the various Unified-SPF checks. This is really no different than Sender ID checking existing SPF records. (Equivalent functionality to marid-core was written up as the Unified-SPF/PRA I-D.) > | There are no changes in semantics to existing protocols > > That's not true. This line was copied from boilerplate versions of the Unified-SPF I-Ds. I believe that what Mark meant by it is that it doesn't change things like RFC2822 or RFC2821. > IP okay for xyzzy: SPF classic SPF/FROM-HDR > MAIL FROM: PASS PASS only if whitelisted > 2822 From: don't care (FAIL => test MAIL FROM) > > I'm not really interested in the 1st example, because I don't > use arbitrary 2822 From headers with a SPF-protected MAIL FROM. This is a common case for mailing lists and such. Yes, the Unified-SPF/From: I-D requires you to whitelist mailing lists that you have subscribed to. > IP not okay for xyzzy: SPF classic SPF/FROM-HDR > MAIL FROM: UNKNOWN (UNKNOWN in step 3) > 2822 From: don't care FAIL (step 5) > > But the 2nd example is real and almost the same problem as with > Sender-Id. In fact it's even worse because Sender-Id at least > allowed to use a matching Sender: to bypass its > 2822 From:-test. I'm not sure what exactly the problem with this is. If I understand things correctly, someone used MSA.test to submit a message claiming to be from valid@xyzzy, but xyzzy doesn't say that MSA.test is an ok source for such email. > IP okay for spam@test: SPF classic SPF/FROM-HDR > MAIL FROM: FAIL don't care > 2622 From: don't care PASS (step 1) > > And the 3rd example is evil, SPF/FROM-HDR results in a PASS, > but the bounce for this spam is later sent to a 3rd party (?) The idea of the Unified-SPF suite of I-Ds was that you would check any and all identities that you want to. Your choices are Unified-SPF/MAILFROM, Unified-SPF/HELO, Unified-SPF/PTR, Unified-SPF/PRA and Unified-SPF/From:. If you want to protect both the MAIL FROM and the From: header, you would need to do both Unified-SPF/MAILFROM and either Unified-SPF/PRA or Unified-SPF/From:. > What's the purpose of step 2 spf_test(To:,IP) ? Bye, Frank Whitelisting the To: address is something that SpamAssassin does. It allows many emails sent through mail forwarders to be whitelisted. If I send email to , and it gets passed onto ; Wed, 4 Aug 2004 11:20:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74F3liU085308; Wed, 4 Aug 2004 08:03: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 i74F3l3s085307; Wed, 4 Aug 2004 08:03:47 -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 i74F3lrB085301 for ; Wed, 4 Aug 2004 08:03:47 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [130.129.129.89] ([::ffff:130.129.129.89]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 04 Aug 2004 11:03:47 -0400 id 0019767E.4110FAD3.00007B25 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <000001c479c5$5d1d3550$6c62fea9@ibmrkydk2ufvdd> References: <000001c479c5$5d1d3550$6c62fea9@ibmrkydk2ufvdd> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7C46DCEF-E627-11D8-9BB9-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: A suggestion concerning Sender-ID/Submitter Date: Wed, 4 Aug 2004 11:03:47 -0400 To: John Glube , "'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 Aug 3, 2004, at 9:50 PM, John Glube wrote: > To date there has been no uptake on Dave's suggestion. Marshall and I have taken this input as well as input from the MARID presentation at the Apps Open Area meeting and will be soliciting for reviews that fit within our schedule. -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 11:33: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 LAA11792 for ; Wed, 4 Aug 2004 11:33: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 i74FH8MS086475; Wed, 4 Aug 2004 08:17:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74FH8vn086474; Wed, 4 Aug 2004 08:17:08 -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 i74FH4gb086467 for ; Wed, 4 Aug 2004 08:17:07 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 3843B28290 for ; Wed, 4 Aug 2004 17:17: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 13025-03 for ; Wed, 4 Aug 2004 17:17:04 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 7375228292; Wed, 4 Aug 2004 17:17:04 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: SPF/FROM-HDR (was: IPR Disclosure for Sender-ID) Date: Wed, 4 Aug 2004 17:17:03 +0200 User-Agent: KMail/1.6.1 References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <4110E7CC.5796@xyzzy.claranet.de> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200408041717.03989@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 4 Août 2004 17:03, wayne a écrit : > > Whitelisting the To: address is something that SpamAssassin does.  It > allows many emails sent through mail forwarders to be whitelisted.  If > I send email to , and it gets passed onto > with forwarder.tld.  Since user@isp.tld has been involved with the > creation and running of this forwarding relationship, they can easily > whitelist it. If you whitelist the "To: " corresponding to your address at the forwarder, you will whitelist all the spam sent to this address, won't you ? Unless you rely on the forwarder itself to perform the checks and reject failures in the first place...? It is most probable that the address @your_forwarder is the address that you publicly communicate the most as "this is my permanent address", where your actual destination address @your_isp may vary when you change ISP, and you may want to keep it private. A lot of people proceed this way... Thus, the address @your_forwarder will be the address that will receive the bigest quantity of spam, viruses and forgeries... Did I miss something ? -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 11:49:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12875 for ; Wed, 4 Aug 2004 11:49:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74FcY6I088693; Wed, 4 Aug 2004 08:38: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 i74FcYoN088692; Wed, 4 Aug 2004 08:38:34 -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 i74FcXxC088649 for ; Wed, 4 Aug 2004 08:38:33 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i74FcNdJ010048 for ietf-mxcomp@imc.org; Wed, 4 Aug 2004 17:38:23 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i7462tmF002160 for ietf-mxcomp@imc.org; Wed, 4 Aug 2004 08:02:55 +0200 From: Hadmut Danisch Date: Tue, 3 Aug 2004 23:02:54 -0700 To: ietf-mxcomp@imc.org Subject: Re: A spammer subscribed to this list ? Message-ID: <20040804060254.GA1982@danisch.de> References: <792DE28E91F6EA42B4663AE761C41C2A02A5B478@cliff.bai.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02A5B478@cliff.bai.org> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 02, 2004 at 01:09:59PM -0500, Ryan Malayter wrote: > > I'd be very surprised if there *weren't* quite a few spammers subscribed > and lurking on this list. They're not stupid, and certainly would want > to know about anything this community is doing that might cause them > grief and cost them money. > In the early days of the asrg mailing list, there were spammers subscribed without any doubt. And they weren't just listening. Some people were trying to jam the mailing list with high bandwidth blabla and spreading wrong technical informations (wrong quoting of technical proposals and other e-mails). I'm pretty sure that some of them were at least related to spammers (maybe authors of spamming software). So why shouldn't it be any different here? Whatever you do, expect the spammers to be prepared. I am, btw, under the impression that spam is getting 'better'. They conform to SMTP protocols better than they used to, and they are forging better (e.g. Received lines). And the contents are getting better in the way of presentation. Many spam messages I receive are not that dull 'buy viagra cheap' anymore, but highly professional HTML messages which look very well. I just saw a report in the Fox 6 News about the increasing problem with Phishing, and a new special task force of the San Diego police department (would have been nice to invite them for a talk at IETF). The forged mails they were showing were also of high quality. Spam is not that idiot's message anymore as it used to be about 5 years ago. Its becoming a tool of highly professional criminals. Whoever is behind that kind of crime and spending so much time to produce good looking spams and phishing mails, will definitely take care to be informed about what's going on in spam fighting. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 11: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 LAA13189 for ; Wed, 4 Aug 2004 11:53: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 i74FhP5v089279; Wed, 4 Aug 2004 08:43: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 i74FhPQn089278; Wed, 4 Aug 2004 08:43:25 -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 i74FhOTB089269 for ; Wed, 4 Aug 2004 08:43:24 -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 1BsNvE-00016Z-VR for ietf-mxcomp@imc.org; Wed, 04 Aug 2004 10:43:27 -0500 To: "IETF MARID WG" References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <4110E7CC.5796@xyzzy.claranet.de> <200408041717.03989@totor.bouissou.net> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 04 Aug 2004 10:43:20 -0500 In-Reply-To: <200408041717.03989@totor.bouissou.net> (Michel Bouissou's message of "Wed, 4 Aug 2004 17:17:03 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: SPF/FROM-HDR (was: IPR Disclosure for Sender-ID) Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.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) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i74FhPTB089271 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In <200408041717.03989@totor.bouissou.net> Michel Bouissou writes: > Le mercredi 4 Août 2004 17:03, wayne a écrit : >> >> Whitelisting the To: address is something that SpamAssassin does.  It >> allows many emails sent through mail forwarders to be whitelisted. > > If you whitelist the "To: " corresponding to your address at the forwarder, > you will whitelist all the spam sent to this address, won't you ? Yes, this is also true for SPF-classic (Unified-SPF/MAILFROM) and SenderID (Unified-SPF/PRA). > Unless you rely on the forwarder itself to perform the checks and reject > failures in the first place...? Right, mailing lists and forwarders need to do a good job of spam filtering and in my opinion, that includes SPF checks. However, if someone chooses to use a poorly run forwarder, or simply wants no spam filtering done for the forwarded address, that is up to them. > Did I miss something ? Nope. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 12: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 MAA13607 for ; Wed, 4 Aug 2004 12:00:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74FlTKN089595; Wed, 4 Aug 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 i74FlT27089594; Wed, 4 Aug 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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74FlTHF089584 for ; Wed, 4 Aug 2004 08:47:29 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i74FlOtD006752; Wed, 4 Aug 2004 08:47:24 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Aug 2004 08:47:24 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Tony Finch'" , "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: RE: How is SPF different from RMX? Date: Wed, 4 Aug 2004 08:47:22 -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 Mon, 2 Aug 2004, Hallam-Baker, Phillip wrote: > > > > I have asked repeatedly for a specific fault in Sender-ID. > The only response > > that has been given is a repeat of the vague claim that the > protocol is > > flawed and cannot work. > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02817.html > http://www.imc.org/ietf-mxcomp/mail-archive/msg02818.html More proof by non-existent reference. These are pointers to issues that have already been raised, are not considered critical and in any case fall far short of the claims made by Dean of Death of the Internet: News at 11. Sure this form of authentication is not going to work for everyone. Nobody has ever claimed complete coverage. For those Sender-ID serves it is cheap and efficient. Claims that a system will not work are of a very different order to claims that the system will bring down the Internet. From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 12:36:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16863 for ; Wed, 4 Aug 2004 12:36: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 i74GKkYI092894; Wed, 4 Aug 2004 09:20:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GKkgV092893; Wed, 4 Aug 2004 09:20:46 -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 i74GKjLD092884 for ; Wed, 4 Aug 2004 09:20:45 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46871) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1BsOVR-00061W-TN for ietf-mxcomp@imc.org; Wed, 04 Aug 2004 17:20:45 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BsOVR-0000IK-PD; Wed, 04 Aug 2004 17:20:45 +0100 Date: Wed, 4 Aug 2004 17:20:45 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 4 Aug 2004, Hallam-Baker, Phillip wrote: > > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02817.html > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02818.html > > These are pointers to issues that have already been raised, are not > considered critical and in any case fall far short of the claims > made by Dean of Death of the Internet: News at 11. Not critical?! I'm expecting deployment of SPF and Sender-ID to cause significant problems for my site, and I neither publish nor check these DNS records. A protocol that causes problems for sites that do not participate is seriously flawed. Many of the work-arounds for the problems caused by designated sender protocols weaken the protocols themselves (e.g. trusted-forwarder.org or inserting a Resent-From: mailer-daemon@example.com header before every Received: header) or weaken other existing security mechanisms (e.g. SRS and open relays). Of course the fundamental reason for the flaw is obvious: a trivial failure to apply the end-to-end principle. 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 Wed Aug 4 12:52: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 MAA18240 for ; Wed, 4 Aug 2004 12:52: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 i74GVt9g093827; Wed, 4 Aug 2004 09: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 i74GVtmb093826; Wed, 4 Aug 2004 09:31:55 -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 i74GVsBq093819 for ; Wed, 4 Aug 2004 09:31:54 -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 i74GVsQ6023997; Wed, 4 Aug 2004 09:31:54 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Aug 2004 09:31:54 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hadmut Danisch'" , ietf-mxcomp@imc.org Subject: RE: A spammer subscribed to this list ? Date: Wed, 4 Aug 2004 09:31: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: > In the early days of the asrg mailing list, there were spammers > subscribed without any doubt. And they weren't just listening. Some > people were trying to jam the mailing list with high bandwidth blabla > and spreading wrong technical informations (wrong quoting of technical > proposals and other e-mails). I'm pretty sure that some of them were > at least related to spammers (maybe authors of spamming software). I agree with Hadmut's analysis here. > So why shouldn't it be any different here? Whatever you do, expect the > spammers to be prepared. I am on a number of anti-phishing mailing lists and even though they are by invitation only and have very highly controlled distributions we assume that there is information leakage. Sure the bad guys are reading. There are clearly people who are playing both sides of the fence. We have to think in terms of the attacks that they will attempt. We are not designing a system here that depends on secrecy of the design for its security. There are mechanisms that people could in theory use to obtain a false assurance that an email is authentic. These are known to involve BGP and DNS attacks that are already the subject of concern and mitigation. There are also means by which a message can be sent that makes it appear that the recipient cannot expect authentication to work without additional data. This is not a concern at this point since there is no requirement to implement MARID at all and the worst case is no different from the status quo, the messages end up going through spam filtering. I am not concerned about spammers discovering this information, it has been discussed repeatedly. I am however concerned about spammers spreading FUD to derail the process, and as is quite clear, it is not even necessary for the spammer to mail to the list to do this, nor is this necessarily the most effective means of doing so. Some of these guys are expert social engineers. So consider this for an attack. You call up someone who is known for being somewhat obssessional on a particular issue and wind him up with a line about how MARID is the work of Voldemort. Just a thought. From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 12:52:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18338 for ; Wed, 4 Aug 2004 12:52:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GcQrE094238; Wed, 4 Aug 2004 09: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 i74GcQHt094237; Wed, 4 Aug 2004 09:38:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GcPnG094231 for ; Wed, 4 Aug 2004 09:38:25 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i74GcOMw008132; Wed, 4 Aug 2004 09:38:24 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Aug 2004 09:38:24 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Tony Finch'" , "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: RE: How is SPF different from RMX? Date: Wed, 4 Aug 2004 09:38: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 Wed, 4 Aug 2004, Hallam-Baker, Phillip wrote: > > > > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02817.html > > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02818.html > > > > These are pointers to issues that have already been raised, are not > > considered critical and in any case fall far short of the claims > > made by Dean of Death of the Internet: News at 11. > > Not critical?! I'm expecting deployment of SPF and Sender-ID to cause > significant problems for my site, and I neither publish nor > check these > DNS records. A protocol that causes problems for sites that do not > participate is seriously flawed. Critical means that it will take down the net. What you describe is called inconvenience. That is very different. Sysop inconvenience is one of the motivations for MARID. It is much easier to get onto the whitelist of a major ISP if you advertise your IP addresses through MARID and it is much easier for them to maintain their lists. If you do not participate in MARID it has no effect on your infrastructure. Other people may not be willing to accept your mail but that is already a major issue for most ISPs. > Of course the fundamental reason for the flaw is obvious: a trivial > failure to apply the end-to-end principle. End to end security has been widely discredited as brittle and undeployable. It is a great objective but attempting to insist on end-to-end or nothing has empirically been an abysmal failure. From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 13:11:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19646 for ; Wed, 4 Aug 2004 13:11:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74H0BVD096117; Wed, 4 Aug 2004 10:00:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74H0BUT096116; Wed, 4 Aug 2004 10:00:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts36-srv.bellnexxia.net (tomts36.bellnexxia.net [209.226.175.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74H0AXM096109 for ; Wed, 4 Aug 2004 10:00:10 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040804170012.MSBV4787.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd>; Wed, 4 Aug 2004 13:00:12 -0400 From: "John Glube" To: "'IETF MARID WG'" , "'Frank Ellermann'" Cc: "'Andrew Newton'" , "'Meng Weng Wong'" , "'Mark Lentczner'" , "'Dave Crocker'" , "'Harry Katz'" , "'Jim Lyon'" Subject: RE: SPF/FROM-HDR (was: IPR Disclosure for Sender-ID) Date: Wed, 4 Aug 2004 13:02:09 -0400 Message-ID: <000001c47a44$c77a1c90$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 i74H0AXM096111 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Frank The drafts Wayne is referencing were discussed on the SPF discuss list in June and July. These drafts did not make it to the IETF table. Instead we had revised SPF, Sender-ID and Submitter. With the realization we continued to have an IPR and licensing issue with the existing Sender-ID draft, Wayne suggested a substitution. Last night I raised the Unified theory as a work around to many of these problems. http://www.imc.org/ietf-mxcomp/mail-archive/msg03007.html This morning, Andy kindly informed the list the chairs had decided to solicit reviews of Sender-ID within the time frame of the WG schedule. The Agenda calls for discussion of the IPR issue and the PRA algorithm this afternoon. I made a further post early this morning concerning these issues, following up on Harry's comments concerning Microsoft's difficulties filing an IPR. http://www.imc.org/ietf-mxcomp/mail-archive/msg03010.html In this post I referenced dealing with the issues raised at the meeting in the morning. This was an error on my part. If the Unified Theory is to be the work around, subject to guidance from the WG chairs, it seems it has to come forward during the review of the IPR and PRA algorithm in the afternoon. In turn this would allow the chairs to solicit reviews within the WG's time frame of at least the 'Sender-ID' portion. This in turn would facilitate finalizing the needed drafts so the WG can meet its time lines. Also, one other point. Should people decide to proceed in this direction, instead of calling it Unified Marid or Unified SPF why not call it Unified Sender-ID? I apologize if these matters have already been discussed at the meeting and I am raising something which is not necessary. John cc. Andy, Meng, Mark, Dave, Harry and Jim John Glube Toronto, Canada --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.729 / Virus Database: 484 - Release Date: 27/07/2004 From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 13:15:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20025 for ; Wed, 4 Aug 2004 13:15:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74H4cB5096321; Wed, 4 Aug 2004 10:04: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 i74H4cXF096320; Wed, 4 Aug 2004 10:04:38 -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 i74H4bwE096314 for ; Wed, 4 Aug 2004 10:04:37 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i74H4ecL012252 for ietf-mxcomp@imc.org; Wed, 4 Aug 2004 19:04:40 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i74H5VAU002999 for ietf-mxcomp@imc.org; Wed, 4 Aug 2004 19:05:31 +0200 From: Hadmut Danisch Date: Wed, 4 Aug 2004 10:05:31 -0700 To: ietf-mxcomp@imc.org Subject: Another question on draft-ietf-marid-submitter-02 Message-ID: <20040804170531.GA2974@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, another question about draft-ietf-marid-submitter-02: e.g. the message is sent with MAIL FROM: SUBMITTER=bbb@bbb.bbb then bounce messages etc. are sent to aaa@aaa.aaa, isn't it? Is that what it is supposed to be? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 13: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 NAA20309 for ; Wed, 4 Aug 2004 13: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 i74H7ML2096660; Wed, 4 Aug 2004 10:07: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 i74H7MoY096659; Wed, 4 Aug 2004 10:07:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74H7LCC096653 for ; Wed, 4 Aug 2004 10:07:22 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [130.129.131.144] (10.50.0.55) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Wed, 4 Aug 2004 12:07:20 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02A5B478@cliff.bai.org> References: <792DE28E91F6EA42B4663AE761C41C2A02A5B478@cliff.bai.org> X-Mailer: Eudora [Macintosh version 6.2a3] Date: Wed, 4 Aug 2004 10:07:16 -0700 To: "Ryan Malayter" From: Pete Resnick Subject: RE: A spammer subscribed to this list ? Cc: "IETF MARID WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 8/2/04 at 1:09 PM -0500, Ryan Malayter wrote: > >[Pete Resnick] >>I doubt there's a subscribed spammer. > >I'd be very surprised if there *weren't* quite a few spammers >subscribed and lurking on this list. Well, of course. I didn't mean to imply that there weren't spammers on the list; just that receiving spam which could only come by reading the mail on the list is not by itself an indication of such. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 13:37: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 NAA21929 for ; Wed, 4 Aug 2004 13:37: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 i74HRm2I099155; Wed, 4 Aug 2004 10:27: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 i74HRman099154; Wed, 4 Aug 2004 10:27:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HRlGc099145 for ; Wed, 4 Aug 2004 10:27:48 -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 A1DC4132CD1; Wed, 4 Aug 2004 13:30:02 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 940D1637; Wed, 4 Aug 2004 13:27:47 -0400 (EDT) Date: Wed, 4 Aug 2004 13:27:47 -0400 From: Meng Weng Wong To: Hadmut Danisch Cc: ietf-mxcomp@imc.org Subject: Re: Another question on draft-ietf-marid-submitter-02 Message-ID: <20040804172747.GA28401@dumbo.pobox.com> References: <20040804170531.GA2974@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804170531.GA2974@danisch.de> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 04, 2004 at 10:05:31AM -0700, Hadmut Danisch wrote: | | e.g. the message is sent with | | MAIL FROM: SUBMITTER=bbb@bbb.bbb | | then bounce messages etc. are sent to aaa@aaa.aaa, isn't it? | | Is that what it is supposed to be? | yes, that is correct. if SUBMITTER is provided, you do an SPF query against it; only a PASS result is acceptable; if you get anything else, you reject. if SUBMITTER is not provided, you fall back to the MAIL FROM value; if you get a FAIL result, you reject. You do the fallback because you expect that the sender is in fact SUBMITTER aware but because the PRA == MAIL-FROM the sender chooses to reduce MAIL FROM: SUBMITTER= to just MAIL FROM:. SUBMITTER was considered superior to SRS because it was expected to be easier for forwarders. From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 13:42: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 NAA22307 for ; Wed, 4 Aug 2004 13:42: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 i74HUaeU099350; Wed, 4 Aug 2004 10:30: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 i74HUamU099349; Wed, 4 Aug 2004 10:30:36 -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 i74HUZQH099341 for ; Wed, 4 Aug 2004 10:30:36 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57432) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1BsPb0-0003Nj-Rz for ietf-mxcomp@imc.org; Wed, 04 Aug 2004 18:30:34 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BsPb0-0000xL-NV; Wed, 04 Aug 2004 18:30:34 +0100 Date: Wed, 4 Aug 2004 18:30:34 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 4 Aug 2004, Hallam-Baker, Phillip wrote: > > > Of course the fundamental reason for the flaw is obvious: a trivial > > failure to apply the end-to-end principle. > > End to end security has been widely discredited as brittle and > undeployable. It is a great objective but attempting to insist on > end-to-end or nothing has empirically been an abysmal failure. CSV and BATV have the same deployment and scaling characteristics as designated sender protocols, but they do not have the same problems. This is because they both work within protocol layers, not across them, and are end-to-end within those layers. CSV works at the single hop MTA-MTA layer, and authenticates identities that are relevant at that level: IP addresses and host names. STARTLS work here also (but has poorer deployment characteristics). The end points happen to coincide with the end points of the TCP connection. BATV works at the envelope layer, where the end-points and identities to be authenticated are email addresses. In particular note that error handling at this layer is by means of the return path, which does not change through alias-forwarding. Any security protocol at this layer should have the same coverage as the error handling (i.e. the same end-points) which is obvoisly the case for BATV because it embeds a security token in the error reporting address. The next layer up is the message header which has wider end-points because certain kinds of forwarding (mailing lists and re-sending) preserve important parts of the header whilst replacing the envelope. DomainKeys works at this layer. Finaly there's the message body which has yet wider end-points because of encapsulation forwarding (message/rfc822 MIME parts etc) and other copying around. PGP and S/MIME work at this layer. The problem with designated sender schemes is that they mix up the first two layers, assuming that the end-points are the same and that identities at one layer can be used to authenticate identities at another. Therefore they are broken as designed. If you apply the principles of security design correctly then you get much stronger guarantees. For example, BATV can guarantee to a recipient that a message was submitted by a particular person (or someone who knows their password), whereas designated sender schemes only tell you that any of thousands of people able to use an MTA sent the message -- they don't even authenticate the domain properly! This is also why BATV can stop collateral spam dead without co-operation from anyone else, whereas designated sender schemes only stop it as a second-order effect and are powerless against first-order forged bounces. How I plan to provide proof of SMTP AUTH to the final recipient: http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/cam.txt 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 Wed Aug 4 13:47: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 NAA22973 for ; Wed, 4 Aug 2004 13:47:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HaY3g099791; Wed, 4 Aug 2004 10:36: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 i74HaYq5099790; Wed, 4 Aug 2004 10:36:34 -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 i74HaX8b099784 for ; Wed, 4 Aug 2004 10:36:34 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i74HaYDL013233; Wed, 4 Aug 2004 19:36:34 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i74HbBEa003453; Wed, 4 Aug 2004 19:37:11 +0200 From: Hadmut Danisch Date: Wed, 4 Aug 2004 10:37:11 -0700 To: Meng Weng Wong Cc: ietf-mxcomp@imc.org Subject: Re: Another question on draft-ietf-marid-submitter-02 Message-ID: <20040804173711.GA3418@danisch.de> References: <20040804170531.GA2974@danisch.de> <20040804172747.GA28401@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804172747.GA28401@dumbo.pobox.com> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 04, 2004 at 01:27:47PM -0400, Meng Weng Wong wrote: > On Wed, Aug 04, 2004 at 10:05:31AM -0700, Hadmut Danisch wrote: > | > | e.g. the message is sent with > | > | MAIL FROM: SUBMITTER=bbb@bbb.bbb > | > | then bounce messages etc. are sent to aaa@aaa.aaa, isn't it? > | > | Is that what it is supposed to be? > | > > yes, that is correct. So I will still receive thousands of bounce messages because spammers are abusing my address for sending messages? Until now they used MAIL FROM: from now on they will use MAIL FROM: SUBMITTER=spammer@farfar.away and I'll still receive all that bounce rubbish? Wasn't this all supposed to solve this problem? Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 13:49: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 NAA23165 for ; Wed, 4 Aug 2004 13:49: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 i74Hb8Yn099830; Wed, 4 Aug 2004 10:37: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 i74Hb8QD099826; Wed, 4 Aug 2004 10:37:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from 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 i74Hb8RQ099811 for ; Wed, 4 Aug 2004 10:37:08 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58192) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1BsPhN-0004MZ-Rj for ietf-mxcomp@imc.org; Wed, 04 Aug 2004 18:37:09 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BsPhN-0001cX-Nl; Wed, 04 Aug 2004 18:37:09 +0100 Date: Wed, 4 Aug 2004 18:37:09 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Meng Weng Wong cc: ietf-mxcomp@imc.org Subject: Re: Another question on draft-ietf-marid-submitter-02 In-Reply-To: <20040804172747.GA28401@dumbo.pobox.com> Message-ID: References: <20040804170531.GA2974@danisch.de> <20040804172747.GA28401@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 4 Aug 2004, Meng Weng Wong wrote: > > SUBMITTER was considered superior to SRS because it was > expected to be easier for forwarders. SUBMITTER requires more invasive changes than SRS. 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 Wed Aug 4 13:58: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 NAA23893 for ; Wed, 4 Aug 2004 13:58:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HngXw000984; Wed, 4 Aug 2004 10:49:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74Hng8V000983; Wed, 4 Aug 2004 10:49:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Hnghp000977 for ; Wed, 4 Aug 2004 10:49:42 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59499) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1BsPtW-0008IF-Bh for ietf-mxcomp@imc.org; Wed, 04 Aug 2004 18:49:42 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BsPtW-0002tO-95; Wed, 04 Aug 2004 18:49:42 +0100 Date: Wed, 4 Aug 2004 18:49:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Hadmut Danisch cc: ietf-mxcomp@imc.org Subject: Re: Another question on draft-ietf-marid-submitter-02 In-Reply-To: <20040804173711.GA3418@danisch.de> Message-ID: References: <20040804170531.GA2974@danisch.de> <20040804172747.GA28401@dumbo.pobox.com> <20040804173711.GA3418@danisch.de> 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, 4 Aug 2004, Hadmut Danisch wrote: > > So I will still receive thousands of bounce messages because spammers > are abusing my address for sending messages? Not if you use BATV. 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 Wed Aug 4 14:04: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 OAA24439 for ; Wed, 4 Aug 2004 14:04:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HtHt1001462; Wed, 4 Aug 2004 10:55: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 i74HtHZh001461; Wed, 4 Aug 2004 10:55:17 -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 i74HtG9U001453 for ; Wed, 4 Aug 2004 10:55:16 -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 870E3132CD6; Wed, 4 Aug 2004 13:57:33 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 7A83A637; Wed, 4 Aug 2004 13:55:18 -0400 (EDT) Date: Wed, 4 Aug 2004 13:55:18 -0400 From: Meng Weng Wong To: Hadmut Danisch Cc: Meng Weng Wong , ietf-mxcomp@imc.org Subject: Re: Another question on draft-ietf-marid-submitter-02 Message-ID: <20040804175518.GM3243@dumbo.pobox.com> References: <20040804170531.GA2974@danisch.de> <20040804172747.GA28401@dumbo.pobox.com> <20040804173711.GA3418@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804173711.GA3418@danisch.de> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 04, 2004 at 10:37:11AM -0700, Hadmut Danisch wrote: | | So I will still receive thousands of bounce messages because spammers | are abusing my address for sending messages? | | Until now they used | MAIL FROM: | from now on they will use | MAIL FROM: SUBMITTER=spammer@farfar.away | | and I'll still receive all that bounce rubbish? | IF the strategy for SUBMITTER is "assume innocent until proven guilty", then the answer (crossing your fingers) is that RHSBLs will list spammer@farfar.away quickly. I would prefer the following: IF the strategy for SUBMITTER is to limit its use to forwarding scenarios ONLY --- and I am going farther than Harry Katz's presentation --- then a receiver can in theory define a whitelist of recognized aliases for a given RCPT. Any SUBMITTER address that is not in that list can be rejected. This strategy means that mobile scenarios, etc etc can NOT do MAIL FROM: SUBMITTER= they MUST do MAIL FROM: The joe@blackberry.net is a sender-side alias for joe@legal.example.com. I would prohibit sender-side aliasing for SUBMITTER. I would prefer to only allow receiver-side aliasing for SUBMITTER: MAIL FROM: SUBMITTER= RCPT TO: I would like to see a world where SUBMITTER if present is ALWAYS a forwarding alias recognized by the RCPT. From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 14:05:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24608 for ; Wed, 4 Aug 2004 14:05: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 i74Ht9oq001448; Wed, 4 Aug 2004 10: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 i74Ht9gp001447; Wed, 4 Aug 2004 10:55:09 -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 i74Ht83Z001440 for ; Wed, 4 Aug 2004 10:55:09 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id D482028290 for ; Wed, 4 Aug 2004 19:55: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 19866-04 for ; Wed, 4 Aug 2004 19:55:09 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 5375628292; Wed, 4 Aug 2004 19:55:09 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Another question on draft-ietf-marid-submitter-02 Date: Wed, 4 Aug 2004 19:55:08 +0200 User-Agent: KMail/1.6.1 References: <20040804170531.GA2974@danisch.de> <20040804172747.GA28401@dumbo.pobox.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200408041955.08881@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 4 Août 2004 19:37, Tony Finch a écrit : > > > SUBMITTER was considered superior to SRS because it was > > expected to be easier for forwarders. > > SUBMITTER requires more invasive changes than SRS. Yes, it does. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 14:10: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 OAA24897 for ; Wed, 4 Aug 2004 14:10:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74I1966001906; Wed, 4 Aug 2004 11:01: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 i74I19Ut001905; Wed, 4 Aug 2004 11:01:09 -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 i74I18xt001898 for ; Wed, 4 Aug 2004 11:01:09 -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 B6A41132CDB; Wed, 4 Aug 2004 14:03:23 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id EF36960E; Wed, 4 Aug 2004 14:01:08 -0400 (EDT) Date: Wed, 4 Aug 2004 14:01:08 -0400 From: Meng Weng Wong To: Tony Finch Cc: Hadmut Danisch , ietf-mxcomp@imc.org Subject: Re: Another question on draft-ietf-marid-submitter-02 Message-ID: <20040804180108.GB28401@dumbo.pobox.com> References: <20040804170531.GA2974@danisch.de> <20040804172747.GA28401@dumbo.pobox.com> <20040804173711.GA3418@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 04, 2004 at 06:49:42PM +0100, Tony Finch wrote: | | On Wed, 4 Aug 2004, Hadmut Danisch wrote: | > | > So I will still receive thousands of bounce messages because spammers | > are abusing my address for sending messages? | | Not if you use BATV. | The argument for BATV/SES in more detail is this: There will always be some fraction of non-compliant receivers. Even if 90% of the world does the right thing and rejects correctly if the MARID check fails, thus abating the bounce blowback problem, there will still be 10% who are oblivious to all the work we are doing and will continue to do the blowback thing, which suggests that if a sender is really concerned about blowback they will do something unilaterally, orthogonal to MARID, and that unilateral thing looks like SES which has been reinvented as BATV. An implementation of SES is described here. http://asarian-host.net/srs/sendmailsrs.htm If you take SRS, remove the idea that only forwarders have to do it, and add the idea that senders always do it, you get SES. From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 14:32: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 OAA26592 for ; Wed, 4 Aug 2004 14:32: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 i74IKSOX004043; Wed, 4 Aug 2004 11:20: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 i74IKSJG004042; Wed, 4 Aug 2004 11:20:28 -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 i74IKRLn004027 for ; Wed, 4 Aug 2004 11:20:27 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id A7BA928290; Wed, 4 Aug 2004 20:20:30 +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 20582-02; Wed, 4 Aug 2004 20:20:27 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id A83CB28292; Wed, 4 Aug 2004 20:20:27 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Another question on draft-ietf-marid-submitter-02 Date: Wed, 4 Aug 2004 20:20:27 +0200 User-Agent: KMail/1.6.1 References: <20040804170531.GA2974@danisch.de> <20040804180108.GB28401@dumbo.pobox.com> In-Reply-To: <20040804180108.GB28401@dumbo.pobox.com> Cc: Meng Weng Wong MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200408042020.27198@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 4 Août 2004 20:01, Meng Weng Wong a écrit : > > An implementation of SES is described here. > > http://asarian-host.net/srs/sendmailsrs.htm > > If you take SRS, remove the idea that only forwarders have > to do it, and add the idea that senders always do it, you > get SES. I had suggested a couple of days ago by private mail to one of the SRS developpers that, before SRS gets widely implemented, we might want to redesign it slightly to allow shorter, and more "human-understandable" Return-Path for mail that we would SRS and that is not actually a forward, but comes straight out of our own domain. The current scheme is : - One forwarding hop => SRS0 - 2 or more forwarding hops => SRS1 But if we SRS mail coming straigth out of our own domain, this currently produces a MAIL FROM which is both redundant, inelegant and not very readable, such as : SRS0=k0kO=K2=bouissou.net=michel@bouissou.net So I suggest that we might want to add an additional SRS type for "0 forwarding step" I would suggest to renumber for being more logical, and use SRS0 : 0 Forwarding step SRS1 : 1 Forwarding step (would be the equivalent of current SRS0) SRS2 : 2 or more forwarding steps (would be the equivalent of current SRS1) If we were to renumber SRS, now would be the good time to do it, as there are quite probably very few implementations on production in the field. The syntax for an SRS0 address would be the same as for an SRS1 address, except that the domain would be ommited from the LH part (being redundant), and the hash would be calculated over the complete address (not on the LH part alone) That would give SRS0 addresses of the form: SRS0=k0kO=K2=michel@bouissou.net Shorter, and easier to read. This would'nt add much complexity, proceeding as follows: - Forward SRS : - Processing an address which is not already SRSn: If the sender's MAIL FROM domain equals our own domain, create an SRS0 address, otherwise create an SRS1 address. - Processing an address which is already an SRSn address: Create an SRS2 address (using the same system as in use for current SRS1) - Reverse-SRS : Decode according to SRSn type. Comments ? -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 15: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 PAA29066 for ; Wed, 4 Aug 2004 15: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 i74IpfXm005936; Wed, 4 Aug 2004 11:51:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74IpfrH005935; Wed, 4 Aug 2004 11:51:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Ipcp7005928 for ; Wed, 4 Aug 2004 11:51:40 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 60B3617109 for ; Wed, 4 Aug 2004 14:59:31 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) In-Reply-To: Your message of "Wed, 04 Aug 2004 09:31:46 PDT." Date: Wed, 04 Aug 2004 14:59:31 -0400 Message-Id: <20040804185931.60B3617109@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hallam-Baker, Phillip" wrote: > There are mechanisms that people could in theory use to obtain a > false assurance that an email is authentic. To change the topic slightly, while the use of MARID may ensure that the email is authentic, that information isn't very useful. We already know that spammers think their email is authentic. What *is* useful is using MARID to find email that *isn't* authentic. e.g. I've talked to people who say that 90% of the SPF records they see are from spammers. Why? Because people are using SPF in conjunction with anti-spam systems like Spamassassin, and giving *positive* scores to email which passes SPF. The end result is that spammers can *gain* by publishing SPF records, as their spam is more likely to get through. If, instead, Spamassassin (and similar systems) were to give *zero* additional score for a sender which passes SPF, then spammers would have nothing to gain by publishing those records. SPF could still be used in conjunction with Spamassassin, to take messages which fail SPF, and either reject them, or give them high negative scores. The practice of having positive scores in spamassassin for SPF records should be strongly discouraged. It ensures that spammers can gain from using SPF/MARID, and contributes to the spam problem. To put it another way, if a site publishes SPF records, you still have no idea whether or not you can trust email from that site. But you *can* decide that email which doesn't pass SPF for a site is definitely untrustworthy. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 15:35: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 PAA02605 for ; Wed, 4 Aug 2004 15:34: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 i74JNP87008709; Wed, 4 Aug 2004 12:23:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74JNPYh008708; Wed, 4 Aug 2004 12:23:25 -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 i74JNIZo008692 for ; Wed, 4 Aug 2004 12:23:18 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i74JNKiE015931; Wed, 4 Aug 2004 21:23:20 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i74JO64t001822; Wed, 4 Aug 2004 21:24:06 +0200 From: Hadmut Danisch Date: Wed, 4 Aug 2004 12:24:06 -0700 To: Alan DeKok Cc: ietf-mxcomp@imc.org Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) Message-ID: <20040804192406.GA1722@danisch.de> References: <20040804185931.60B3617109@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804185931.60B3617109@mail.nitros9.org> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, On Wed, Aug 04, 2004 at 02:59:31PM -0400, Alan DeKok wrote: > > e.g. I've talked to people who say that 90% of the SPF records they > see are from spammers. > > Why? Because people are using SPF in conjunction with anti-spam > systems like Spamassassin, and giving *positive* scores to email which > passes SPF. The end result is that spammers can *gain* by publishing > SPF records, as their spam is more likely to get through. That's a very interesting point. It means that spammers have (partly) changed their behavior and started to use their own domains for sender addresses. Does anyone have examples of such domains? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 15:59: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 PAA04438 for ; Wed, 4 Aug 2004 15:59:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JiZsb010165; Wed, 4 Aug 2004 12: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 i74JiZGf010164; Wed, 4 Aug 2004 12:44:35 -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 i74JiW5Q010146 for ; Wed, 4 Aug 2004 12:44:33 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BsRgY-0003wu-62 for ietf-mxcomp@imc.org; Wed, 04 Aug 2004 14:44:33 -0500 To: "IETF MARID WG" References: <20040804185931.60B3617109@mail.nitros9.org> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 04 Aug 2004 14:44:26 -0500 In-Reply-To: <20040804185931.60B3617109@mail.nitros9.org> (Alan DeKok's message of "Wed, 04 Aug 2004 14:59:31 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) 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 <20040804185931.60B3617109@mail.nitros9.org> "Alan DeKok" writes: > "Hallam-Baker, Phillip" wrote: >> There are mechanisms that people could in theory use to obtain a >> false assurance that an email is authentic. > > To change the topic slightly, while the use of MARID may ensure that > the email is authentic, that information isn't very useful. We > already know that spammers think their email is authentic. What *is* > useful is using MARID to find email that *isn't* authentic. Positive authentication is useful for whitelists. > e.g. I've talked to people who say that 90% of the SPF records they > see are from spammers. > > Why? Because people are using SPF in conjunction with anti-spam > systems like Spamassassin, and giving *positive* scores to email which > passes SPF. The end result is that spammers can *gain* by publishing > SPF records, as their spam is more likely to get through. I caught the very end of the ASRG audio session yesterday and I heard someone giving this claim. I think this claim is completely bogus. First off, the current version of spamassassin doesn't check SPF records, it is the yet-to-be-released version 3.0 that will do it. Secondly, see the following quote: > If, instead, Spamassassin (and similar systems) were to give *zero* > additional score for a sender which passes SPF, then spammers would > have nothing to gain by publishing those records. SPF could still be > used in conjunction with Spamassassin, to take messages which fail > SPF, and either reject them, or give them high negative scores. That is *exactly* what Spamassassin does. I have no idea where the assumption that the Spamassassin folks are clueless came from. They understood these issues when they were participating in the SPF mailing lists last year. > To put it another way, if a site publishes SPF records, you still > have no idea whether or not you can trust email from that site. But > you *can* decide that email which doesn't pass SPF for a site is > definitely untrustworthy. Publishing SPF records alone does not make a domain trustworthy. It does, however, let you safely decide whether the domain is worth whitelisting or blacklisting. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 16:43: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 QAA06903 for ; Wed, 4 Aug 2004 16:43: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 i74KIbXp012954; Wed, 4 Aug 2004 13:18: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 i74KIbiE012953; Wed, 4 Aug 2004 13:18:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74KIamm012947 for ; Wed, 4 Aug 2004 13:18:36 -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 i74KIeru031368 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 4 Aug 2004 13:18:40 -0700 Date: Wed, 4 Aug 2004 13:18:40 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: IETF MARID WG Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) In-Reply-To: Message-ID: References: <20040804185931.60B3617109@mail.nitros9.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, 4 Aug 2004, wayne wrote: > > If, instead, Spamassassin (and similar systems) were to give *zero* > > additional score for a sender which passes SPF, then spammers would > > have nothing to gain by publishing those records. SPF could still be > > used in conjunction with Spamassassin, to take messages which fail > > SPF, and either reject them, or give them high negative scores. > > That is *exactly* what Spamassassin does. I have no idea where the > assumption that the Spamassassin folks are clueless came from. They > understood these issues when they were participating in the SPF > mailing lists last year. Yes, hopefully they have learned to avoid mistakes like this after the wild swing in scores (first positive then negative) to things like Habeus and (unverified) PGP signatures. -Rand From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 16:59: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 QAA07810 for ; Wed, 4 Aug 2004 16:59: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 i74KmPu3015691; Wed, 4 Aug 2004 13:48: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 i74KmPTs015690; Wed, 4 Aug 2004 13:48:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74KmO5d015679 for ; Wed, 4 Aug 2004 13:48:25 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 0DBE594028; Wed, 4 Aug 2004 22:48:27 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 17CDD94007; Wed, 4 Aug 2004 22:48:26 +0200 (CEST) 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 i74KmPjI1377344; Wed, 4 Aug 2004 22:48:25 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 7A4F6102C5; Wed, 4 Aug 2004 22:48:25 +0200 (CEST) Date: Wed, 4 Aug 2004 22:48:25 +0200 From: Stephane Bortzmeyer To: Alan DeKok Cc: ietf-mxcomp@imc.org Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) Message-ID: <20040804204825.GA2551@nic.fr> References: <20040804185931.60B3617109@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804185931.60B3617109@mail.nitros9.org> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 04, 2004 at 02:59:31PM -0400, Alan DeKok wrote a message of 36 lines which said: > The practice of having positive scores in spamassassin for SPF > records should be strongly discouraged. Wether MARID encourage or discourages it will make no difference. Scores of the various tests in SpamAssassin are not determined by an human trying to guess wether "sex" should be more an indication of spam than "viagra", or less. Scores are determined by using the actual tests against a corpus of spam and a corpus of ham. See http://wiki.apache.org/spamassassin/HowScoresAreAssigned. So, scores do not depend (too much) on human opinion or prejudice. Wether SPF "pass" is a good spam marker or not will be determined automatically. Do note that, at the present time, the scores of all SPF-related tests are very low (probably reflecting the small number of SPF-enabled domains). See http://spamassassin.apache.org/tests.html and search for SPF. From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 17: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 RAA08233 for ; Wed, 4 Aug 2004 17:07: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 i74KtMxE016300; Wed, 4 Aug 2004 13:55: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 i74KtMmt016299; Wed, 4 Aug 2004 13:55:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74KtM0W016271 for ; Wed, 4 Aug 2004 13:55:22 -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 0E02C414B7; Wed, 4 Aug 2004 13:55:06 -0700 (PDT) Received: from 130.129.132.229 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Wed, 4 Aug 2004 13:55:06 -0700 (PDT) Message-ID: <3058.130.129.132.229.1091652906.squirrel@harry.mail-abuse.org> In-Reply-To: <20040804172747.GA28401@dumbo.pobox.com> References: <20040804170531.GA2974@danisch.de> <20040804172747.GA28401@dumbo.pobox.com> Date: Wed, 4 Aug 2004 13:55:06 -0700 (PDT) Subject: Re: Another question on draft-ietf-marid-submitter-02 From: "Douglas Otis" To: "Meng Weng Wong" Cc: "Hadmut Danisch" , 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 > > On Wed, Aug 04, 2004 at 10:05:31AM -0700, Hadmut Danisch wrote: > | > | e.g. the message is sent with > | > | MAIL FROM: SUBMITTER=bbb@bbb.bbb > | > | then bounce messages etc. are sent to aaa@aaa.aaa, isn't it? > | > | Is that what it is supposed to be? > | > > yes, that is correct. > > if SUBMITTER is provided, you do an SPF query against it; > only a PASS result is acceptable; if you get anything else, > you reject. > > if SUBMITTER is not provided, you fall back to the MAIL FROM > value; if you get a FAIL result, you reject. You do the > fallback because you expect that the sender is in fact > SUBMITTER aware but because the PRA == MAIL-FROM the sender > chooses to reduce > MAIL FROM: SUBMITTER= > to just > MAIL FROM:. > > SUBMITTER was considered superior to SRS because it was > expected to be easier for forwarders. This is not as defined in the Submitter specification with respect to error results. The Submitter draft does not indicate a fall-back to MAIL FROM. It only requires Submitter, if the PRA is different than the MAIL FROM and Submitter is supported. This Fall Back can only make this assumption if Submitter is supported, but then it is not a suggested mode. Submitter is not superior to BATV. If the outcome of arm-twisting MTAs into publishing Sender-ID records, the only logical recourse would be to include a Resent-From header to permit customers to continue their normal practices. If that becomes the normal case, then using and exposing the EHLO domain to the user from the Received header would be of equal user value to that of a PRA identity. CSV would also give enforcement the domain of where to make a request for a log. The advantage to switching to the CSV EHLO domain would be a deterministic load on the receiver (no additional DNS query), and the ability to accredit the machine that allowed the mail to be sent. Only a single identity could be selected, as opposed to the PRA algorithm which could be one of many, where only one may normally be seen. (I would suggest some character used to terminate the EHLO domain to indicate a successful authentication and authorization process. There is some general text within the CSV Intro draft to this respect, but it should be made specific.) -Doug From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 18:16: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 SAA13483 for ; Wed, 4 Aug 2004 18:16: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 i74M2SBM021292; Wed, 4 Aug 2004 15:02: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 i74M2SNg021291; Wed, 4 Aug 2004 15:02:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74M2SpT021284 for ; Wed, 4 Aug 2004 15:02:28 -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 BE833414B7; Wed, 4 Aug 2004 14:10:31 -0700 (PDT) Received: from 130.129.132.229 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Wed, 4 Aug 2004 14:10:31 -0700 (PDT) Message-ID: <3066.130.129.132.229.1091653831.squirrel@harry.mail-abuse.org> In-Reply-To: References: <20040804185931.60B3617109@mail.nitros9.org> Date: Wed, 4 Aug 2004 14:10:31 -0700 (PDT) Subject: Re: Interaction with anti-spam systems (was Re: A spammersubscribed to this list ? ) From: "Douglas Otis" To: "IETF MARID WG" Cc: "IETF MARID WG" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Wayne wrote: > In <20040804185931.60B3617109@mail.nitros9.org> "Alan DeKok" > writes: > > > Positive authentication is useful for whitelists. > ... > > I caught the very end of the ASRG audio session yesterday and I heard > someone giving this claim. I think this claim is completely bogus. > > First off, the current version of spamassassin doesn't check SPF > records, it is the yet-to-be-released version 3.0 that will do it. > > Secondly, see the following quote: > >> If, instead, Spamassassin (and similar systems) were to give *zero* >> additional score for a sender which passes SPF, then spammers would >> have nothing to gain by publishing those records. SPF could still be >> used in conjunction with Spamassassin, to take messages which fail >> SPF, and either reject them, or give them high negative scores. > > That is *exactly* what Spamassassin does. I have no idea where the > assumption that the Spamassassin folks are clueless came from. They > understood these issues when they were participating in the SPF > mailing lists last year. > ... > > Publishing SPF records alone does not make a domain trustworthy. It > does, however, let you safely decide whether the domain is worth > whitelisting or blacklisting. Do not expect Sender-ID to ever allow blacklisting. Sender-ID is too complex and relies upon the security of mail channel which does not exist. The Sender-ID records contain a series of possible domains, and the PRA allows for the evaluation of less recent headers. Where the message had emerged remains unknown. If to blacklist a domain, it must be verified where the mail was sent. The point behind this type of negative listing is to improve policies related to access. As many domains may share an MTA server, the only policy enforcement that makes sense is the ISP forcing use of this MTA. Any other downstream domain could claim to be one of these Sender-ID identities. Sender-ID makes assumptions that are not valid, if this is used to blacklist. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 19:47:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21003 for ; Wed, 4 Aug 2004 19:47:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74NQ08X028075; Wed, 4 Aug 2004 16:26: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 i74NQ0id028074; Wed, 4 Aug 2004 16:26:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74NQ0Pl028068 for ; Wed, 4 Aug 2004 16:26:00 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 4 Aug 2004 16:26:04 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Aug 2004 16:26:03 -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, 4 Aug 2004 16:26:03 -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, 4 Aug 2004 16:25:57 -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="----_=_NextPart_001_01C47A7A.662270BC" Subject: Slide decks from MARID meetings Date: Wed, 4 Aug 2004 16:25:59 -0700 Message-ID: Thread-Topic: Slide decks from MARID meetings Thread-Index: AcR6emUa77z1BSgeRxiPfPSwTgvgLQ== From: "Harry Katz" To: "IETF MARID WG" X-OriginalArrivalTime: 04 Aug 2004 23:25:57.0787 (UTC) FILETIME=[6554C6B0:01C47A7A] 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_01C47A7A.662270BC Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C47A7A.662270BC" ------_=_NextPart_002_01C47A7A.662270BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the slides that I presented this morning and that Jim is presenting as I hit send. ------_=_NextPart_002_01C47A7A.662270BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Here = are the slides=20 that I presented this morning and that Jim is presenting as I hit=20 send.
------_=_NextPart_002_01C47A7A.662270BC-- ------_=_NextPart_001_01C47A7A.662270BC Content-Type: application/vnd.ms-powerpoint; name="IETF60 - Responsible Submitter.ppt" Content-Transfer-Encoding: base64 Content-Description: IETF60 - Responsible Submitter.ppt Content-Disposition: attachment; filename="IETF60 - Responsible Submitter.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOgAAAAAAAAAA EAAAPAAAAAEAAAD+////AAAAADsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8P AOgDaw4AAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAACgAAAAAAAAABAAAAAAEAAQ8A 8gMUAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUHTAAAAAAAtw9EAAAAQQByAGkAYQBsAAAAvJYT AMjKDDC8lhMAAAAAADAA0g9UqRMAVKkTABSvRwXclhMAB8kMMNyWEwAAAAAADwDVBwAABAAAAKQP CAAAAIAAQAAAAP//AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xIA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwAL BLgAAAAPAADwsAAAAAAABvBYAAAACCQAAAoAAAAqAAAACQAAAAEAAAAHAAAAAgAAAAQAAAADAAAA BAAAAAQAAAAEAAAABQAAAAYAAAAGAAAABwAAAAcAAAAHAAAACAAAAAQAAAAJAAAACAAAAIMAC/Aw AAAAgQEEAAAIgwEAAAAIhkEAAAAAvwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIQAAe8RAA AAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQ BzMBAAAfABQEHAAAAAAAFQQUAAAAupOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAA AAEAAAD9AzQAAABHAAAAZAAAAEcAAABkAAAAAAAAAOAOkgX0lhMAB8kMMAAAAAAAAAAAGv7//5r/ //8BABMAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAA AGQAAABkAAAAZAAAACCXEwCRdwwwVKkTAPCuRwUAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMUAAAA AgAABAwAAAAAAAAAAAAAAAIAAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLExAAAAAAAA0ECAAAAADAAAAAwAAAPwDZDwwAAAAAANoPBAAAAAAALQBPANkPDAAAAAAA 2g8EAAAADQA9AA8A8A/ICgAAAADzAxQAAAADAAAAAAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAA AAAAqA9GAAAAUmVzcG9uc2libGUgU3VibWl0dGVyC0FuIFNNVFAgU2VydmljZSBFeHRlbnNpb24L C0lFVEYgNjALU2FuIERpZWdvLCBDQQAAoQ8eAAAARwAAAAAAAAAAABYAAAAAAAIAKAAxAAAAAAAC ABgAEACfDwQAAAAFAAAAAACoDyMAAABIYXJyeSBLYXR6DU1pY3Jvc29mdCBDb3JwLg04LzQvMjAw NAAAoQ8WAAAAJAAAAAAAABAAAFoAJAAAAAAAAgAYAAAA8wMUAAAABAAAAAAAAAACAAAAAQEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPEgAAAFNlbmRlciBJRCBPdmVydmlldxAAnw8EAAAAAQAAAAAAqA+U AQAATWVyZ2VyIG9mIGVsZW1lbnRzIG9mIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpIGFu ZCBDYWxsZXIgSUQgZm9yIEUtbWFpbA0zIEludGVybmV0IERyYWZ0cw1kcmFmdC1pZXRmLW1hcmlk LWNvcmUtMDINQWxnb3JpdGhtIGZvciBkZXRlcm1pbmluZyB0aGUgcHVycG9ydGVkIHJlc3BvbnNp YmxlIGFkZHJlc3MgYW5kIGZvciBldmFsdWF0aW5nIHJlc3VsdHMgb2Ygc3Bvb2YgdGVzdA1kcmFm dC1pZXRmLW1hcmlkLXByb3RvY29sLTAwDVRoZSBTUEYgcmVjb3JkIGZvcm1hdCBhbmQgdGVzdCBw cm90b2NvbA1kcmFmdC1pZXRmLW1hcmlkLXN1Ym1pdHRlci0wMg1TTVRQIFNlcnZpY2UgZXh0ZW5z aW9uIGZvciBpbmRpY2F0aW5nIHRoZSByZXNwb25zaWJsZSBzdWJtaXR0ZXIgb2YgYW4gZS1tYWls IG1lc3NhZ2UAAKEPmAAAAF8AAAAAAAAAAAAZAAAAAQAAAAAAZQAAAAIAAAAAAB0AAAABAAAAAAAo AAAAAgAAAAAAHgAAAAEAAAAAAFUAAAACAAAAAABfAAAAAAACABwAGQAAAAAEAgAABBgAZQAAAAAE AgAABBQAHQAAAAAIAgAACBgAKAAAAAAIAgAACBQAHgAAAAAMAgAADBgAVQAAAAAQAgAAEBQAAADz AxQAAAAFAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8JAAAAU1VCTUlUVEVSEACf DwQAAAABAAAAAACoDwIBAABFeHRlbnNpb24gdG8gU01UUCBNQUlMIGNvbW1hbmQNTGV0cyBTTVRQ IGNsaWVudCBkZWNsYXJlIHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzIChQUkEpIGluIGFu IFNNVFAgIGNvbW1hbmQNTGV0cyBTTVRQIHNlcnZlciBwZXJmb3JtIHNwb29mIGNoZWNraW5nIGJl Zm9yZSBtZXNzYWdlIGJvZHkgaXMgc2VudCBhY3Jvc3MgdGhlIEludGVybmV0DU11c3QgbWF0Y2gg dGhlIFBSQSBhcyBkZXJpdmVkIGZyb20gUkZDMjgyMiBtZXNzYWdlIGhlYWRlcnMAAKEPFAAAAAMB AAAAAAAQAABaAAMBAAAAAAAAAADzAxQAAAAGAAAABAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8YAAAARXhhbXBsZTogTWFpbCBTdWJtaXNzaW9uEACfDwQAAAABAAAAAACqDwoAAAABAAAA AQAAAAAAAADzAxQAAAAHAAAABAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8VAAAARXhh bXBsZTogTWFpbGluZyBMaXN0EACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAAI AAAABAAAAAIAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAARXhhbXBsZTogTW9iaWxlIFVz ZXIQAJ8PBAAAAAEAAAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAAkAAAAAAAAAAgAAAAYBAAAA AAAAAACfDwQAAAAAAAAAAACoDxYAAABDaGFuZ2VzIGluIC0wMiBWZXJzaW9uEACfDwQAAAABAAAA AACoD2kDAABTZWN0aW9uIDQuMQ1TdHJlbmd0aGVuZWQgY29uZm9ybWFuY2UgcmVxdWlyZW1lbnRz OyBTVUJNSVRURVIgbm93IG1hbmRhdG9yeSB3aGVuIE1BSUwgRlJPTSBkaWZmZXJzIGZyb20gUFJB IGFuZCByZWNvbW1lbmRlZCB3aGVuIE1BSUwgRlJPTSBpcyBpZGVudGljYWwgdG8gUFJBLg1SZW1v dmVkIHdvcmRpbmcgYWJvdXQgbWFraW5nIHVzZSBvZiBTVUJNSVRURVIgZXh0ZW5zaW9uIG1hbmRh dG9yeSBhdCBzb21lIGZ1dHVyZSB0aW1lLg1Nb3ZlZCB0aGUgcHJvY2VkdXJhbCBkZXNjcmlwdGlv bnMgZm9yIGluaXRpYWwgbWVzc2FnZSBzdWJtaXNzaW9uIGFuZCBzdWJzZXF1ZW50IG1lc3NhZ2Ug cmV0cmFuc21pc3Npb24gdG8gdGhlIG5vbi1ub3JtYXRpdmUgRXhhbXBsZXMgc2VjdGlvbi4NU2Vj dGlvbiA0LjINUmVtb3ZlZCB0aGUgd29yZGluZyBhYm91dCBwcm9jZWR1cmVzIHRvIGJlIHVzZWQg YXQgc29tZSBmdXR1cmUgdGltZSB3aGVuIHVzZSBvZiB0aGUgU1VCTUlUVEVSIGV4dGVuc2lvbiBi ZWNvbWVzIG1hbmRhdG9yeQ1TaWduaWZpY2FudCByZXdvcmRpbmcgdG8gc2ltcGxpZnkgYW5kIGNs YXJpZnkgdGhlIHZlcmlmaWNhdGlvbiBwcm9jZXNzIGFuZCBlcnJvciBtZXNzYWdlcy4NU2VjdGlv biA0LjMNQ2xhcmlmaWVkIHRoZSB3b3JkaW5nIHRvIGluY2x1ZGUgYWxsIGNhc2VzIG9mIG1lc3Nh Z2UgdHJhbnNtaXNzaW9uIHRvIGEgbm9uLVNVQk1JVFRFUiBhd2FyZSBzZXJ2ZXIuDVNlY3Rpb24g NQ1DaGFuZ2VkIGV4YW1wbGUgYWRkcmVzc2VzIHRvIGJlIGNvbXBsaWFudCB3aXRoIFJGQyAyNjA2 DVNlY3Rpb24gNg1SZXdvcmRpbmcgYW5kIGZvY3VzIG9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IHNwZWNpZmljIHRvIHRoaXMgcHJvcG9zYWwAAKEP7AAAAAwAAAAAAAAQAABQAHgBAAABAAAQAABQ AAwAAAAAAAAQAABQANUAAAABAAAQAABQAAwAAAAAAAAQAABQAGQAAAABAAAQAABQAAoAAAAAAAAQ AABQADgAAAABAAAQAABQAAoAAAAAAAAQAABQAEkAAAABAAAQAABQAAwAAAAAAAIAEgB4AQAAAAAC ABAADAAAAAAEAgAABBIA1QAAAAAEAgAABBAADAAAAAAIAgAACBIAZAAAAAAIAgAACBAACgAAAAAM AgAADBIAOAAAAAAMAgAADBAACgAAAAAQAgAAEBIASQAAAAAUAgAAFBAAAADqAwAAAAAPAPgDpAkA AAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAwwYADwByAAAAD///8AAAAAAICAgAAAAAAA u+DjADMzmQAAmZkAmcwAAGAA8AcgAAAA////AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlmAABg APAHIAAAAP///wAAAAAAgICAAAAAAACZzP8AzMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAAAJaW lgAAAAAA////AI3G/wAAZswAAKgAAGAA8AcgAAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA/1BQ AP+ZAABgAPAHIAAAAACAgAD///8AAFpYAP//mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACAAAAA ////AFwfAADf0pMAzDMAAL55YAD//5kA06IZAGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNmzAAA sAAAZsz/AP/nAQBgAPAHIAAAAAAAAAD///8AM2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADwByAA AABoa10A////AHd3dwDR0csAkJCCAICeqAD/zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA//// AGBZewBmZv8Amcz/AP//mQBgAPAHIAAAAFI+JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACMnqAA AACjDz4AAAABAP/9PwAAACIgAABkAAAAAP8BAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD/ //////8sAAAAAAMAABAAow98AAAABQD//T8AAQAiIAAAZAAAAAD/AABkABQAAADYAAAAQAIAAAAA BwAAAP//7wAAAAAA////////IAAAAAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAY AIAFAAATIPADYAMAAAIAFACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/ AABkAB4AAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////DAAAAAABAAAABQAAIAEgAQAAAAAA BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAA AAAAAAEAAQkAAAAAAQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkA AAAAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAA AAAAAAIAGAACAAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAA AAAAAAACABgAAQAAAAAAAAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAA DwAMBNYEAAAPAALwzgQAABAACPAIAAAABgAAAAYEAAAPAAPwZgQAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMA C/A2AAAAfwABAAUAgAD8zEcFhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAAAQBHBQ8ADfBUAAAAAACfDwQA AAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAA AAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8BYBAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEA BQCAAATSRwWBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAPADIAFg FRMPDwAR8BAAAAAAAMMLCAAAAAEAAAACAEcFDwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENs aWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1G b3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwA AAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8ABPC2AAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwAB AAUAgACE2UcFgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyAB YAaKEA8AEfAQAAAAAADDCwgAAAACAAAABwFHBQ8ADfA+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAq AAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADgAAAPgPBAAAAAAAAAAPAATwuAAAABIACvAIAAAA BQQAAAAKAACDAAvwMAAAAH8AAQAFAIAABNxHBYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACAAAEPAIAAAAXg+wB9AOihAPABHwEAAAAAAAwwsIAAAAAwAAAAkCRwUPAA3wQAAAAAAA nw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAABAAIAAAAAAAIADgAAAPoPBAAA AAAAAAAPAATwuAAAABIACvAIAAAABgQAAAAKAACDAAvwMAAAAH8AAQAFAIAAsOdHBYEBBAAACIMB AAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXg8gEGAVihAPABHwEAAAAAAAwwsI AAAABAAAAAgCRwUPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAI AAACAAIAAAAAAAIADgAAANgPBAAAAAAAAAAPAATwSAAAABIACvAIAAAAAQQAAAAMAACDAAvwMAAA AIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA ////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABf AF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAANp5xAFwNCUNIAC6DxwAAABEAGUAZgBhAHUA bAB0ACAARABlAHMAaQBnAG4ADwDwA/oFAAABAPEDCAAAAAAAAIAAAA0wDwAMBHoFAAAPAALwcgUA AJAACPAIAAAABwAAAAckAAAPAAPwCgUAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAAJAAABQAAAA8ABPDIAAAAEgAK8AgAAAACJAAAAAoAAIMAC/AwAAAAfwABAAUAgADo D90FgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAAAAAAAAUAcgAQ8A EfAQAAAAAADDCwgAAAAAAAAACgLdBQ8ADfBQAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8U AAAAAgAAAAAAAAAAAAIAAAAAAAIADAAAAPkPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAPAATw ygAAABIACvAIAAAAAyQAAAAKAACDAAvwMAAAAH8AAQAFAIAATEuOBYEBBAAACIMBAAAACL8BAQAR AMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAAACPCd8QIAEPABHwEAAAAAAAwwsIAAAAAQAAAAcA 3QUPAA3wUgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAA AAIADAAAAPgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAPAATwZAAAABIACvAIAAAABCQAAAAK AABjAAvwJAAAAH8ABAEEAYcAAQAAAH8BAAABAL8BEQARAP8BCAAJAD8CAQABAAAAEPAIAAAAsAHQ AhAOIAoPABHwEAAAAAAAwwsIAAAAAgAAAAUA3QUPAATwFgEAABIACvAIAAAABSQAAAAKAACDAAvw MAAAAH8AAQAFAIAAGC7dBYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAI AAAAsAqwATAP0BQPABHwEAAAAAAAwwsIAAAAAwAAAAYC3QUPAA3wngAAAAAAnw8EAAAAAgAAAAAA qA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJk IGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIA DQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8M4AAAASAArwCAAAAAYkAAAACgAAkwAL 8DYAAAB/AAEABQCAALDgjgWHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA AAgAABDwCAAAAF8VAABQB38WDwAR8BAAAAAAAMMLCAAAAAQAAAAJAt0FDwAN8FAAAAAAAJ8PBAAA AAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+g8EAAAAAAAAAAAA qg8KAAAAAgAAAAEAAAAAAA8ABPDQAAAAEgAK8AgAAAAHJAAAAAoAAJMAC/A2AAAAfwABAAUAgABo 544FhwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABfFY8J 3xB/Fg8AEfAQAAAAAADDCwgAAAAFAAAACALdBQ8ADfBSAAAAAACfDwQAAAAEAAAAAACgDwIAAAAq AAAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA2A8EAAAAAAAAAAAAqg8KAAAAAgAAAAEA AAAAAA8ABPBIAAAAEgAK8AgAAAABJAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHevWgAlAGO n4sAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMz mQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAA AAAA6y4IAAAA3nnEAQCzKf8PAO4DJAIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAAAAAHAAww DwAMBJQBAAAPAALwjAEAACAACPAIAAAAAwAAAAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMA C/AeAAAAfwAAAAQAgAAw6kcFvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAABgA7AB0BTQCA8AEfAQ AAAAAADDCwgAAAAAAAAADwBHBQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMI AAAgAgAAUwAL8B4AAAB/AAAABACAAPzyRwW/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAANALMAPw EgAPDwAR8BAAAAAAAMMLCAAAAAEAAAAQAEcFDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIA CvAIAAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgT OAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAANp5xAFQ yCkNDwDuAyQCAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAMMA8ADASUAQAADwAC8IwB AAAwAAjwCAAAAAMAAAADDAAADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAAAwAAAUAAAAPAATwcgAAABIACvAIAAAAAgwAACACAABTAAvwHgAAAH8AAAAEAIAA sLySBb8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAA AA0AkgUPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADDAAAIAIAAFMAC/AeAAAA fwAAAAQAgAD8tpIFvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQAAAAAADD CwgAAAABAAAADgCSBQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEMAAAADAAA gwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQ APAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAADaecQBALuzZw8A7gMkAgAAAgDv AxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcADDAPAAwElAEAAA8AAvCMAQAAQAAI8AgAAAADAAAA AxAAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAQAAAF AAAADwAE8HIAAAASAArwCAAAAAIQAAAgAgAAUwAL8B4AAAB/AAAABACAABSy/gW/AQAAAQD/AQAA AQABAwIEAAAAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAANAP4FDwAN8AwAAAAA AJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxAAACACAABTAAvwHgAAAH8AAAAEAIAA5Lf+Bb8B AAABAP8BAAABAAEDAwQAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAA4A/gUP AA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABEAAAAAwAAIMAC/AwAAAAgQEAAAAI gwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAA AICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAA UABUADEAMAAAAIsTEAAAAAAA6y4IAAAA23nEAYDXld0PAO4DmgYAAAIA7wMYAAAAAQAAAA0OAAAA AAAAAAAAgAAAAAAHAAwwDwAMBAoGAAAPAALwAgYAAFAACPAIAAAABQAAAAUUAAAPAAPwcgUAAA8A BPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAFAAABQAAAA8ABPACAwAAEgAK 8AgAAAACFAAAAAoAAJMAC/A2AAAAfwAAAAQAgACA5NoAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAwA/AAQBRBEA8ADfCcAgAAAACfDwQAAAAEAAAAAACo D+gBAABTOiAyMjAgYWx1bW5pLmFsbWFtYXRlci5lZHUgRVNNVFAgc2VydmVyIHJlYWR5IA1DOiBF SExPIGV4YW1wbGUuY29tIA1TOiAyNTAtYWx1bW5pLmFsbWFtYXRlci5lZHUgDVM6IDI1MC1EU04g DVM6IDI1MC1BVVRIIA1TOiAyNTAtU1VCTUlUVEVSIA1TOiAyNTAgU0laRSANQzogTUFJTCBGUk9N OjxhbGljZUBleGFtcGxlLmNvbT4gU1VCTUlUVEVSPWFsaWNlQGV4YW1wbGUuY29tIA1TOiAyNTAg PGFsaWNlQGV4YW1wbGUuY29tPiBzZW5kZXIgb2sgDUM6IFJDUFQgVE86PGJvYkBhbHVtbmkuYWxt YW1hdGVyLmVkdT4gDVM6IDI1MCA8Ym9iQGFsdW1uaS5hbG1hbWF0ZXIuZWR1PiByZWNpcGllbnQg b2sgDUM6IERBVEEgDVM6IDM1NCBva2F5LCBzZW5kIG1lc3NhZ2UgDUM6IEZyb206IGFsaWNlQGV4 YW1wbGUuY29tDUM6IChtZXNzYWdlIGJvZHkgZ29lcyBoZXJlKSANQzogLiANUzogMjUwIG1lc3Nh Z2UgYWNjZXB0ZWQgDUM6IFFVSVQgDVM6IDIyMSBnb29kYnllIAAAqg+YAAAABwAAAAAAAAAUAAAA AQAAAAMAHQAAAAAAAAALAAAAAQAAAAMAZQAAAAAAAAARAAAAAQAAAAMADAAAAAAAAAARAAAAAQAA AAMACgAAAAAAAAARAAAAAQAAAAMAGQAAAAAAAAAYAAAAAQAAAAMACwAAAAAAAAAYAAAAAQAAAAMA PQAAAAAAAAARAAAAAQAAAAMAVgAAAAAAAAAPAATweAAAABIACvAIAAAAAxQAACACAABjAAvwJAAA AH8AAAAEAIAAdOzaAL8BAAABAP8BAAABAAEDAgQAAIgDAAAAAAAAEPAIAAAArQAgAWAVfQMPABHw EAAAAAAAwwsIAAAAAAAAAA0A2gAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPDRAAAA4gMK8AgAAAAE FAAAAAoAALMAC/BCAAAAgACccP4FvwAAAAIARwED5///SAFQeAAAgQEEAAAIgwEAAAAIvwEQABAA wAEBAAAI/wEIAAgAAQICAAAIfwMAAAwAAAAQ8AgAAACABDAJwBIwBg8ADfBfAAAAAACfDwQAAAAE AAAAAACoDy8AAABTVUJNSVRURVIgZXh0ZW5zaW9uIGFkdmVydGlzZWQgaW4gRUhMTyByZXNwb25z ZQAAoQ8UAAAAMAAAAAAAAAgAAAEAMAAAAAAAAAAPAATw1wAAAOIDCvAIAAAABRQAAAAKAADTAAvw TgAAAAQAAAC0AIAAfNT+BYkAAgAAAL8AAAACAEcB1GQAAEgBY30AAIEBBAAACIMBAAAACL8BEAAQ AMABAQAACP8BCAAIAAECAgAACH8DAAAMAAAAEPAIAAAAwAnQDpAVAAwPAA3wWQAAAAAAnw8EAAAA BAAAAAAAqA8pAAAAU1VCTUlUVEVSIHBhcmFtZXRlciBhZGRlZCB0byBNQUlMIGNvbW1hbmQAAKEP FAAAACoAAAAAAAAIAAABACoAAAAAAAAADwAE8EgAAAASAArwCAAAAAEUAAAADAAAgwAL8DAAAACB AQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAvAAXwIAAAAAAA F/AIAAAAAQAAAAQUAAAAABfwCAAAAAIAAAAFFAAAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+Dj ADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsT EAAAAAAA6y4IAAAAWUjEAdBIU1QPAO4D2AcAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAH AAwwDwAMBEgHAAAPAALwQAcAAGAACPAIAAAABgAAAAYYAAAPAAPwoAYAAA8ABPAoAAAAAQAJ8BAA AAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAGAAABQAAAA8ABPB4AAAAEgAK8AgAAAACGAAAIAIA AGMAC/AkAAAAfwAAAAQAgAB86v4FvwEAAAEA/wEAAAEAAQMCBAAAiAMAAAAAAAAQ8AgAAACtACAB YBWgAg8AEfAQAAAAAADDCwgAAAAAAAAADQD+BQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8FwDAAAS AArwCAAAAAMYAAAACgAAkwAL8DYAAAB/AAAABACAAORNkgW/AAIAAgCBAQQAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAHUCkABgFeAQDwAN8PYCAAAAAJ8PBAAAAAQAAAAA AKgPOAIAAFM6IDIyMCBleGFtcGxlLmNvbSBFU01UUCBzZXJ2ZXIgcmVhZHkgDUM6IEVITE8gbGlz dGV4YW1wbGUuY29tDVM6IDI1MC1leGFtcGxlLmNvbSAgICANUzogMjUwLVNVQk1JVFRFUiANUzog MjUwIFNJWkUgDUM6IE1BSUwgRlJPTTo8b3duZXItbGlzdDFAbGlzdGV4YW1wbGUuY29tPiAgICAg IA0gICAgIFNVQk1JVFRFUj1vd25lci1saXN0MUBsaXN0ZXhhbXBsZS5jb20gIA1TOiAyNTAgPG93 bmVyLWxpc3QxQGxpc3RleGFtcGxlLmNvbT4gc2VuZGVyIG9rIA1DOiBSQ1BUIFRPOjxhbGljZUBl eGFtcGxlLmNvbT4gDVM6IDI1MCA8YWxpY2VAZXhhbXBsZS5jb20+IHJlY2lwaWVudCBvayANQzog REFUQSANUzogMzU0IG9rYXksIHNlbmQgbWVzc2FnZSANQzogUmVjZWl2ZWQgQnk6IC4uLiANQzog RnJvbTogYm9iQHdvb2Rncm92ZS5jb20NQzogU2VuZGVyOiBvd25lci1saXN0MUBsaXN0ZXhhbXBs ZS5jb20NQzogVG86IGxpc3QxQGxpc3RleGFtcGxlLmNvbQ1DOiAobWVzc2FnZSBib2R5IGdvZXMg aGVyZSkgDUM6IC4gDVM6IDI1MCBtZXNzYWdlIGFjY2VwdGVkIA1DOiBRVUlUIA1TOiAyMjEgZ29v ZGJ5ZSAAAKoPcgAAAAcAAAAAAAAACwAAAAEAAAADAB0AAAAAAAAADwAAAAEAAAADAD8AAAAAAAAA IQAAAAAAAABxAAAAAAAAABEAAAABAAAAAwALAAAAAAAAABEAAAABAAAAAwBSAAAAAAAAABEAAAAB AAAAAwCaAAAAAAAAAA8A8g8YAAAAAADzDxAAAAAAAAAAAAAAAAAAAAAInw0wAADfDwgAAAB9AAAA ngAAAA8ABPDRAAAA4gMK8AgAAAAEGAAAAAoAALMAC/BCAAAAgAB80/4FvwAAAAIARwHhyv//SAGi MAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIfwMAAAwAAAAQ8AgAAADwAzAM kBWgBQ8ADfBfAAAAAACfDwQAAAAEAAAAAACoDy8AAABTVUJNSVRURVIgZXh0ZW5zaW9uIGFkdmVy dGlzZWQgaW4gRUhMTyByZXNwb25zZQAAoQ8UAAAAMAAAAAAAAAgAAAEAMAAAAAAAAAAPAATw1wAA AOIDCvAIAAAABRgAAAAKAADTAAvwTgAAAAQAAAC0AIAAMEr+BYkAAgAAAL8AAAACAEcBNG4AAEgB Mk0AAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACH8DAAAMAAAAEPAIAAAAwAbQ DpAVAAkPAA3wWQAAAAAAnw8EAAAABAAAAAAAqA8pAAAAU1VCTUlUVEVSIHBhcmFtZXRlciBhZGRl ZCB0byBNQUlMIGNvbW1hbmQAAKEPFAAAACoAAAAAAAAIAAABACoAAAAAAAAADwAE8MwAAADiAwrw CAAAAAYYAAAACgAA0wAL8E4AAAAEAAAAtACAACDL/gWJAAIAAAC/AAAAAgBHAWWDAABIAd0mAACB AQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAh/AwAADAAAABDwCAAAAHAL0A6QFSAN DwAN8E4AAAAAAJ8PBAAAAAQAAAAAAKgPHgAAAFNlbmRlciBoZWFkZXIgYWRkZWQgdG8gbWVzc2Fn ZQAAoQ8UAAAAHwAAAAAAAAgAAAEAHwAAAAAAAAAPAATwSAAAABIACvAIAAAAARgAAAAMAACDAAvw MAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABAD8ABfAw AAAAAAAX8AgAAAABAAAABBgAAAAAF/AIAAAAAgAAAAUYAAAAABfwCAAAAAMAAAAGGAAAEADwByAA AAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAA AF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAXUjEARBY71oPAO4DywcAAAIA7wMYAAAA AQAAAA0OAAAAAAAAAAAAgAAAAAAHAAwwDwAMBDsHAAAPAALwMwcAAHAACPAIAAAABgAAAAYcAAAP AAPwkwYAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAHAAABQAAAA8A BPB4AAAAEgAK8AgAAAACHAAAIAIAAGMAC/AkAAAAfwAAAAQAgABsCNoAvwEAAAEA/wEAAAEAAQMC BAAAiAMAAAAAAAAQ8AgAAADAACABYBXjAg8AEfAQAAAAAADDCwgAAAAAAAAADQDaAA8ADfAMAAAA AACeDwQAAAAAAAAADwAE8NEAAADiAwrwCAAAAAMcAAAACgAAswAL8EIAAACAADw62gC/AAAAAgBH AdDM//9IAaZyAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAh/AwAADAAAABDw CAAAAPADMAyQFaAFDwAN8F8AAAAAAJ8PBAAAAAQAAAAAAKgPLwAAAFNVQk1JVFRFUiBleHRlbnNp b24gYWR2ZXJ0aXNlZCBpbiBFSExPIHJlc3BvbnNlAAChDxQAAAAwAAAAAAAACAAAAQAwAAAAAAAA AA8ABPDXAAAA4gMK8AgAAAAEHAAAAAoAANMAC/BOAAAABAAAALQAgACQRNoAiQACAAAAvwAAAAIA RwHTYAAASAFdGgAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIfwMAAAwAAAAQ 8AgAAADABtAOkBUACQ8ADfBZAAAAAACfDwQAAAAEAAAAAACoDykAAABTVUJNSVRURVIgcGFyYW1l dGVyIGFkZGVkIHRvIE1BSUwgY29tbWFuZAAAoQ8UAAAAKgAAAAAAAAgAAAEAKgAAAAAAAAAPAATw zAAAAOIDCvAIAAAABRwAAAAKAADTAAvwTgAAAAQAAAC0AIAADE7aAIkAAgAAAL8AAAACAEcB9m0A AEgB3SYAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACH8DAAAMAAAAEPAIAAAA cAvQDpAVIA0PAA3wTgAAAAAAnw8EAAAABAAAAAAAqA8eAAAAU2VuZGVyIGhlYWRlciBhZGRlZCB0 byBtZXNzYWdlAAChDxQAAAAfAAAAAAAACAAAAQAfAAAAAAAAAA8ABPBPAwAAEgAK8AgAAAAGHAAA AAoAAJMAC/A2AAAAfwAAAAQAgAAQWNoAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEA AAgAAQICAAAIAAAQ8AgAAAB1ApAAYBXgEA8ADfDpAgAAAACfDwQAAAAEAAAAAACoDzUCAABTOiAy MjAgYWx1bW5pLmFsbWFtYXRlci5lZHUgRVNNVFAgc2VydmVyIHJlYWR5IA1DOiBFSExPIGNvbnNv bGlkYXRlZG1lc3Nlbmdlci5uZXQgIA1TOiAyNTAtYWx1bW5pLmFsbWFtYXRlci5lZHUgIA1TOiAy NTAtRFNOIA1TOiAyNTAtQVVUSCANUzogMjUwLVNVQk1JVFRFUiANUzogMjUwIFNJWkUgDUM6IE1B SUwgRlJPTTo8YWxpY2VAZXhhbXBsZS5jb20+ICANICAgICBTVUJNSVRURVI9YWxpY2VAY29uc29s aWRhdGVkbWVzc2VuZ2VyLm5ldCAgDVM6IDI1MCA8YWxpY2VAZXhhbXBsZS5jb20+IHNlbmRlciBv ayANQzogUkNQVCBUTzo8Ym9iQGFsdW1uaS5hbG1hbWF0ZXIuZWR1PiANUzogMjUwIDxib2JAYWx1 bW5pLmFsbWFtYXRlci5lZHU+IHJlY2lwaWVudCBvayANQzogREFUQSANUzogMzU0IG9rYXksIHNl bmQgbWVzc2FnZSANQzogU2VuZGVyOiBhbGljZUBjb25zb2xpZGF0ZWRtZXNzZW5nZXIubmV0ICAN QzogUmVjZWl2ZWQgQnk6IC4uLiANQzogKG1lc3NhZ2UgYm9keSBnb2VzIGhlcmUpIA1DOiAuIA1T OiAyNTAgbWVzc2FnZSBhY2NlcHRlZCANQzogUVVJVCANUzogMjIxIGdvb2RieWUgAACqD5gAAAAH AAAAAAAAABQAAAABAAAAAwAdAAAAAAAAABkAAAABAAAAAwBnAAAAAAAAABEAAAABAAAAAwATAAAA AAAAAB8AAAABAAAAAwALAAAAAAAAABEAAAABAAAAAwAZAAAAAAAAABgAAAABAAAAAwALAAAAAAAA ABgAAAABAAAAAwA/AAAAAAAAAB8AAAABAAAAAwBtAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABHAAA AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMB AAEAPwAF8DAAAAAAABfwCAAAAAEAAAADHAAAAAAX8AgAAAACAAAABBwAAAAAF/AIAAAAAwAAAAUc AAAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAA AAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAABZSMQB0EhTVA8A7gMkAgAA AgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcADDAPAAwElAEAAA8AAvCMAQAAgAAI8AgAAAAD AAAAAyAAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAg AAAFAAAADwAE8HIAAAASAArwCAAAAAIgAAAgAgAAUwAL8B4AAAB/AAAABACAAPzO2gC/AQAAAQD/ AQAAAQABAwIEAAAAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAANANoADwAN8AwA AAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAyAAACACAABTAAvwHgAAAH8AAAAEAIAAlLDa AL8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAA4A 2gAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABIAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAA3XnEAQCd47YAAHIXLAAAAAEAoAAAAAAAcw4AACEe AABNIAAAeSIAAKUkAABHKwAAJzMAAPo6AAAfGAAAAAD1DxwAAAAGAQAAmRUAAwAAAAAmPQAAAQAA AAoAAAABAMUxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y +U9oEKuRCAArJ7PZMAAAAPAGAAALAAAAAQAAAGAAAAACAAAAaAAAAAQAAAC4AAAACAAAANAAAAAJ AAAA6AAAABIAAAD0AAAACgAAABgBAAAMAAAAJAEAAA0AAAAwAQAADwAAADwBAAARAAAARAEAAAIA AADkBAAAHgAAAEgAAABSZXNwb25zaWJsZSBTdWJtaXR0ZXIgQW4gU01UUCBTZXJ2aWNlIEV4dGVu c2lvbiAgSUVURiA2MCBTYW4gRGllZ28sIENBAAAeAAAAEAAAAEhhcnJ5IFMuIEthdHoAAAAeAAAA EAAAAEhhcnJ5IFMuIEthdHoAAAAeAAAABAAAADUAAAAeAAAAHAAAAE1pY3Jvc29mdCBPZmZpY2Ug UG93ZXJQb2ludABAAAAAIEKZqAYAAABAAAAAAD9039x5xAFAAAAAwAcPiON5xAEDAAAA8wEAAEcA AACkBQAA/////wMAAAAIAIkQZwwAAAEACQAAA8kCAAAFAC0AAAAAAAQAAAADAQgABQAAAAsCAAAA AAUAAAAMAnkAoQADAAAAHgAHAAAA/AIAAP///wAAAAQAAAAtAQAACAAAAPoCBQAAAAAA////AAQA AAAtAQEADgAAACQDBQD///////94AKAAeACgAP///////wgAAAD6AgAAAAAAAAAAAAAEAAAALQEC AAQAAAAtAQAABAAAACcB//8cAAAA+wL3/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAInAAAAMgoi ACMAFQAAAFJlc3BvbnNpYmxlIFN1Ym1pdHRlcgAHAAUABQAFAAUABAAFAAIABQACAAQAAwAGAAUA BQAIAAEAAwACAAUAAwAEAAAALgEAABwAAAD7AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQAAAAAA AAAAAAAYAAAAAQAAAFA8FQDkBAAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avv/AAAAAAAAkAEAAAAA AEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAAC AQEABQAAAAkCAAAAAi0AAAAyCikALwAZAAAAQW4gU01UUCBTZXJ2aWNlIEV4dGVuc2lvbgADAAMA AgADAAQABAADAAIAAwADAAIAAwABAAMAAwABAAMAAwABAAMAAwADAAEAAwADAAQAAAAuAQAABAAA AC0BBAAEAAAA8AEDABwAAAD7Avv/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhIAAAAyCjYARwAH AAAASUVURiA2MDQBAAMABAADAAEAAwADAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avv/ AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAE AAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhsAAAAyCjwAPwANAAAAU2FuIERpZWdvLCBDQXADAAMA AwABAAQAAQADAAMAAwACAAEABAADAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avv/AAAA AAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAA LgEYAAQAAAACAQEABQAAAAkCAAAAAhYAAAAyCloAQgAKAAAASGFycnkgS2F0egQAAwACAAIAAwAB AAMAAwABAAMABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC+/8AAAAAAACQAQAAAAAAQAAA QXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAF AAAACQIAAAACHgAAADIKYQA9AA8AAABNaWNyb3NvZnQgQ29ycC4ABAABAAMAAgADAAMAAwABAAEA AQAEAAMAAgADAAEABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC+/8AAAAAAACQAQAAAAAA QAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIB AQAFAAAACQIAAAACEwAAADIKaABEAAgAAAA4LzQvMjAwNAMAAQADAAEAAwADAAMAAwAEAAAALgEA AAQAAAAtAQQABAAAAPABAwADAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgA Kyz5rjAAAAB0AgAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAAC8AAAABgAAAMQAAAAH AAAAzAAAAAgAAADUAAAACQAAANwAAAAKAAAA5AAAABcAAADsAAAACwAAAPQAAAAQAAAA/AAAABMA AAAEAQAAFgAAAAwBAAANAAAAFAEAAAwAAAAUAgAAAgAAAOQEAAAeAAAAEAAAAE9uLXNjcmVlbiBT aG93AAAeAAAADAAAAE1pY3Jvc29mdAAAAAMAAAB+PQAAAwAAAGgAAAADAAAABwAAAAMAAAAAAAAA AwAAAAAAAAADAAAAAAAAAAMAAADmFQsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAe EAAACQAAAAYAAABBcmlhbAAPAAAARGVmYXVsdCBEZXNpZ24ARwAAAFJlc3BvbnNpYmxlIFN1Ym1p dHRlciBBbiBTTVRQIFNlcnZpY2UgRXh0ZW5zaW9uICBJRVRGIDYwIFNhbiBEaWVnbywgQ0EAEwAA AFNlbmRlciBJRCBPdmVydmlldwAKAAAAU1VCTUlUVEVSABkAAABFeGFtcGxlOiBNYWlsIFN1Ym1p c3Npb24AFgAAAEV4YW1wbGU6IE1haWxpbmcgTGlzdAAVAAAARXhhbXBsZTogTW9iaWxlIFVzZXIA FwAAAENoYW5nZXMgaW4gLTAyIFZlcnNpb24ADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAA AAEAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVz AAMAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD2DyUAAAAUAAAAX8CR41o9AAANAPQDAwDaMEhhcnJ5IFMuIEthdHoIAAAASABh AHIAcgB5ACAAUwAuACAASwBhAHQAegAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA DwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAd AAAAHgAAAP7///8gAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAA/v///ygAAAApAAAAKgAAACsA AAAsAAAALQAAAC4AAAD+////MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAAP7////9////OQAA AP7///////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABYABQH//////////wMAAAAQjYFkm0/PEYbqAKoAuSnoAAAAAAAAAAAAAAAAAAAAAAAA AAD+////AAAAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAC8AAAAAEAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh AHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAP//////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAAAQAAAAAAAAUABvAHcAZQByAFAAbwBp AG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAA BAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfj0AAAAAAAAF AEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAA AAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACcAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUB//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAANDIN2V6esQB PQAAAAADAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAvAAAAABAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8AAAAAEAAAAAAAAFAAbwB3AGUAcgBQAG8AaQBu AHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH49AAAAAAAAAQAA AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAA/v///yAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAD+//////////////////////////// //////////////////8wAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA/v////////////////// /z8AAAD9/////v///z4AAAD+/////v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8BAAAA AgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAP7///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////7/AAAF AQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss +a64AgAAdAIAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAAvAAAAAYAAADEAAAABwAA AMwAAAAIAAAA1AAAAAkAAADcAAAACgAAAOQAAAAXAAAA7AAAAAsAAAD0AAAAEAAAAPwAAAATAAAA BAEAABYAAAAMAQAADQAAABQBAAAMAAAAFAIAAAIAAADkBAAAHgAAABAAAABPbi1zY3JlZW4gU2hv dwAAHgAAAAwAAABNaWNyb3NvZnQAAAADAAAAfj0AAAMAAABoAAAAAwAAAAcAAAADAAAAAAAAAAMA AAAAAAAAAwAAAAAAAAADAAAA5hULAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAA AAkAAAAGAAAAQXJpYWwADwAAAERlZmF1bHQgRGVzaWduAEcAAABSZXNwb25zaWJsZSBTdWJtaXR0 ZXIgQW4gU01UUCBTZXJ2aWNlIEV4dGVuc2lvbiAgSUVURiA2MCBTYW4gRGllZ28sIENBABMAAABT ZW5kZXIgSUQgT3ZlcnZpZXcACgAAAFNVQk1JVFRFUgAZAAAARXhhbXBsZTogTWFpbCBTdWJtaXNz aW9uABYAAABFeGFtcGxlOiBNYWlsaW5nIExpc3QAFQAAAEV4YW1wbGU6IE1vYmlsZSBVc2VyABcA AABDaGFuZ2VzIGluIC0wMiBWZXJzaW9uAAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAAB AAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwAD AAAABwAAADQAAAADAAAAAAAAACAAAAABAAAAJAAAAAAAAIAsAAAAAAAAAAIAAACwBAAAEwAAAAkE AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAEQAbwBj AHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAA OAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADs AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_001_01C47A7A.662270BC Content-Type: application/vnd.ms-powerpoint; name="SenderId040804.ppt" Content-Transfer-Encoding: base64 Content-Description: SenderId040804.ppt Content-Disposition: attachment; filename="SenderId040804.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAGgAAAAAAAAAA EAAAHAAAAAEAAAD+////AAAAABsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////GQAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAA/v////7///8WAAAAFwAAABgAAAD+/////v////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAADDYazvtecQB FQAAAMAHAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAAiMAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkBAAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAGQCAAAAAAAADwDo A/YLAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPID FAEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAEEAcgBpAGEAbAAAANyWEwBT vgww3JYTAAAAAAAwANIPdKkTAHSpEwBAISUB/JYTABW+DDD8lhMAAAAAAA8A1QcAAAQAAACkDwgA AACAAEAAAAD//wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAF AP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8SAAAA AAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwTI AAAADwAA8MAAAAAAAAbwaAAAAAQsAAAMAAAAGAAAAAcAAAABAAAABwAAAAIAAAAEAAAAAwAAAAQA AAAAAAAABAAAAAUAAAAEAAAAAAAAAAQAAAAHAAAABAAAAAAAAAAEAAAACQAAAAQAAAAAAAAABAAA AAsAAAAEAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiGQQAAAAC/ARAAEADAAQEAAAjFQQAAAAD/AQgA CAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAA AAAAAAAAgAAAAAAPANAHdwEAAB8AFAQcAAAAAAAVBBQAAACz7J4UAMqaOxlUfzMAypo7AQEAAQ8A +gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEwAAABkAAAATAAAAGQAAAAAAAAAJIdfARSXEwAVvgww AAAAAAAAAACm////Hv3//wEAEwBwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8AEwQ8 AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAQJcTAKFrDDB0qRMAHCElAQAAAAAAAAAAAAAAAAAA AAAAARMAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAABAlxMAoWsMMHSpEwAcISUBAAAA AAAAAAAAAAAAAAAAAAABEwAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwCIEzgAAAAPAIoT MAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAAANBAgAAAAAwAAAAMAAAA8A8A8n CAAAAADzAxQAAAADAAAAAAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA8QAAAAU2VuZGVy IElEIERyYWZ0cxAAnw8EAAAABQAAAAAAqA8sAAAASmltIEx5b24LTWljcm9zb2Z0IENvcnBvcmF0 aW9uCzQgQXVndXN0IDIwMDQAAPMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAA AACoDwgAAABPdmVydmlldxAAnw8EAAAAAQAAAAAAoA8wAQAAVwBoAG8AIABjAGwAYQBpAG0AcwAg AHQAbwAgAGgAYQB2AGUAIABpAG4AdAByAG8AZAB1AGMAZQBkACAAYQAgAG0AZQBzAHMAYQBnAGUA IABpAG4AdABvACAAdABoAGUAIABlAC0AbQBhAGkAbAAgAGUAYwBvAHMAeQBzAHQAZQBtAD8ADQBE AG8AZQBzACAAdABoAGEAdAAgAHAAZQByAHMAbwBuABkgcwAgAGQAbwBtAGEAaQBuACAAYQBjAGMA ZQBwAHQAIAByAGUAcwBwAG8AbgBzAGkAYgBpAGwAaQB0AHkAIABmAG8AcgAgAHQAaABlACAATQBU AEEAIABmAHIAbwBtACAAdwBoAGkAYwBoACAAdABoAGUAIABtAGEAaQBsACAAYwBhAG0AZQA/AAAA 8wMUAAAABQAAAAAAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKAPGAAAAFcAaABvACAAYwBs AGEAaQBtAHMAIAAmIBAAnw8EAAAAAQAAAAAAqA9vAAAARmluZCBtZXNzYWdlIGhlYWRlciwgZmly c3Qgb2Y6DVJlc2VudC1TZW5kZXINUmVzZW50LUZyb20NU2VuZGVyDUZyb20NVGhpcyBpcyBQUkE6 IFB1cnBvcnRlZCBSZXNwb25zaWJsZSBBZGRyZXNzAAChDzYAAAAfAAAAAAAAAAAAJgAAAAEAAAAA ACsAAAAAAAAAAAAfAAAAAAAAACYAAAAAAAAAKwAAAAAAAAAAAPMDFAAAAAYAAAAAAAAAAgAAAAMB AAAAAAAAAACfDwQAAAAAAAAAAACgD0gAAABEAG8AZQBzACAARABvAG0AYQBpAG4AIABBAGMAYwBl AHAAdAAgAFIAZQBzAHAAbwBuAHMAaQBiAGkAbABpAHQAeQAgACYgPwAAAKEPFAAAACUAAAAAAAAA AAAlAAAAAAACACgAEACfDwQAAAABAAAAAACgDxABAABGAHIAbwBtACAAUABSAEEALAAgAGUAeAB0 AHIAYQBjAHQAIABkAG8AbQBhAGkAbgAgAG4AYQBtAGUALgANAEYAaQBuAGQAIAB0AGgAYQB0ACAA ZABvAG0AYQBpAG4AGSBzACAAVABYAFQAIAByAGUAYwBvAHIAZAAgAGkAbgAgAEQATgBTAC4ADQBS AGUAYwBvAHIAZAAgAGQAZQBzAGMAcgBpAGIAZQBzACAAdwBoAGkAYwBoACAATQBUAEEAcwAgAGEA cgBlACAAYQB1AHQAaABvAHIAaQB6AGUAZAAgAHQAbwAgAHMAcABlAGEAawAgAGYAbwByACAAdABo AGUAIABkAG8AbQBhAGkAbgAuAAAAqg8aAAAAXAAAAAAAAAAEAAAAAQAAAAMAKQAAAAAAAAAAAPMD FAAAAAcAAAAAAAAAAgAAAAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDw4AAABDdXJyZW50IERyYWZ0 cxAAnw8EAAAAAQAAAAAAqA/gAAAAZHJhZnQtaWV0Zi1tYXJpZC1jb3JlLTAyDURlc2NyaWJlcyBQ UkEgYWxnb3JpdGhtLCBvdmVydmlldw1kcmFmdC1pZXRmLW1hcmlkLXByb3RvY29sLTAwDURlc2Ny aWJlcyBmb3JtYXQgYW5kIG1lYW5pbmcgb2YgRE5TIHJlY29yZC4NZHJhZnQtaWV0Zi1tYXJpZC1z dWJtaXR0ZXItMDINRGVzY3JpYmVzIG9wdGlvbmFsIFNNVFAgZXh0ZW5zaW9uIGZvciBwZXJmb3Jt YW5jZSBvcHRpbWl6YXRpb24AAKEPdAAAABkAAAAAAAAAAAAiAAAAAQAAAAAAHQAAAAAAAAAAACwA AAABAAAAAAAeAAAAAAAAAAAAPwAAAAEAAAAAABkAAAAAAAAAIgAAAAAAAAAdAAAAAAQAAAAELAAA AAAEAAAABB4AAAAACAAAAAg/AAAAAAwAAAAMAADzAxQAAAAIAAAAAAAAAAIAAAAFAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8YAAAAZHJhZnQtaWV0Zi1tYXJpZC1jb3JlLTAyEACfDwQAAAABAAAAAACo D+4AAABDaGFuZ2VzOg1SZW1vdmFsIG9mIFhNTCByZWNvcmQgZm9ybWF0Lg1SZWNvcmQgZm9ybWF0 IG1vdmVkIHRvIHByb3RvY29sLTAwLg1SZW1vdmFsIG9mIG5vbnN0YW5kYXJkIGhlYWRlcnMgZnJv bSBQUkEgYWxnb3JpdGhtLg1EZWZpbmUgYmVoYXZpb3IgZm9yIG1hbGZvcm1lZCBoZWFkZXJzIGlu IFBSQSBhbGdvcml0aG0uDVNldCBvZiByZXN1bHRzIG5vdyBtYXRjaGVzIFNQRi4NTWlub3IgZWRp dG9yaWFsIGNoYW5nZXMuAAChDyYAAAAJAAAAAAAAAAAA5gAAAAEAAAAAAAkAAAAAAAAA5gAAAAAE AAAABAAAqg8aAAAAqwAAAAAAAAAKAAAAAQAAAAAAOgAAAAAAAAAAAOoDAAAAAA8A+AOkCQAAAgDv AxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAADDBgAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMA MzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAAmWYAAGAA8Acg AAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAAAAAAlpaWAAAA AAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPMzAD/UFAA/5kA AGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAAAIAAAAD///8A XB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8AM2bMAACwAABm zP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABgAPAHIAAAAGhr XQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+XAD///8AYFl7 AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQAAIyeoAAAAKMP PgAAAAEA//0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP////// /ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAP8AAGQAFAAAANgAAABAAgAAAAAHAAAA ///vAAAAAAD///////8gAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgAgAUA ABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8AAGQA HgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABA AkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAA AQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAAB AIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAA AgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAAAAAA AAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwE 1gQAAA8AAvDOBAAAEAAI8AgAAAAGAAAABgQAAA8AA/BmBAAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIAAAASAArwCAAAAAIEAAAACgAAkwAL8DYA AAB/AAEABQCAABhHXwGHAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgA ABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAABAF8BDwAN8FQAAAAAAJ8PBAAAAAAA AAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxlAACiDwYAAAAhAAAAAAAA AKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAAAwQAAAAKAACDAAvwMAAAAH8AAQAFAIAA IExfAYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAA8AMgAWAVEw8P ABHwEAAAAAAAwwsIAAAAAQAAAAIAXwEPAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sg dG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0 aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQA AACqDwoAAABTAAAAAQAAAAAADwAE8LYAAAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEABQCA AABTXwGBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF4PIAFgBooQ DwAR8BAAAAAAAMMLCAAAAAIAAAAHAV8BDwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAACh DxQAAAACAAAAAAAAAAAAAgAAAAAAAgAOAAAA+A8EAAAAAAAAAA8ABPC4AAAAEgAK8AgAAAAFBAAA AAoAAIMAC/AwAAAAfwABAAUAgABsS18BgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIAAAQ8AgAAABeD7AH0A6KEA8AEfAQAAAAAADDCwgAAAADAAAACQJfAQ8ADfBAAAAAAACfDwQA AAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAEAAgAAAAAAAgAOAAAA+g8EAAAAAAAA AA8ABPC4AAAAEgAK8AgAAAAGBAAAAAoAAIMAC/AwAAAAfwABAAUAgAAEYV8BgQEEAAAIgwEAAAAI vwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyAQYBWKEA8AEfAQAAAAAADDCwgAAAAE AAAACAJfAQ8ADfBAAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIA AgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAA6nnEAUBcJTcgALoPHAAAAEQAZQBmAGEAdQBsAHQA IABEAGUAcwBpAGcAbgAPAO4DJAIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAAAAAHAAwwDwAM BJQBAAAPAALwjAEAACAACPAIAAAAAwAAAAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/Ae AAAAfwAAAAQAgAA0aV8BvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAAA+BbAB0BTcCA8AEfAQAAAA AADDCwgAAAAAAAAADwBfAQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAg AgAAUwAL8B4AAAB/AAAABACAAKxsXwG/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAJAJYAMgE+AN DwAR8BAAAAAAAMMLCAAAAAEAAAAQAF8BDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAI AAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAA AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAOp5xAHg4iY3 DwDuAyQCAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAMMA8ADASUAQAADwAC8IwBAAAw AAjwCAAAAAMAAAADDAAADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA CvAIAAAAAAwAAAUAAAAPAATwcgAAABIACvAIAAAAAgwAACACAABTAAvwHgAAAH8AAAAEAIAAmI5f Ab8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAAAA0A XwEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADDAAAIAIAAFMAC/AeAAAAfwAA AAQAgAD4a18BvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQAAAAAADDCwgA AAABAAAADgBfAQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEMAAAADAAAgwAL 8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAH IAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAADqecQB4PoDUQ8A7gMkAgAAAgDvAxgA AAABAAAADQ4AAAAAAAAAAACAAAAAAAcADDAPAAwElAEAAA8AAvCMAQAAUAAI8AgAAAADAAAAAxQA AA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAA DwAE8HIAAAASAArwCAAAAAIUAAAgAgAAUwAL8B4AAAB/AAAABACAABxxRAG/AQAAAQD/AQAAAQAB AwIEAAAAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAANAEQBDwAN8AwAAAAAAJ4P BAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxQAACACAABTAAvwHgAAAH8AAAAEAIAAbHVEAb8BAAAB AP8BAAABAAEDAwQAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAA4ARAEPAA3w DAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABFAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICA gAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABU ADEAMAAAAIsTEAAAAAAA6y4IAAAA6nnEARD3GtEPAO4DJAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAA AAAAgAAAAAAHAAwwDwAMBJQBAAAPAALwjAEAAHAACPAIAAAAAwAAAAMcAAAPAAPwJAEAAA8ABPAo AAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAHAAABQAAAA8ABPByAAAAEgAK8AgA AAACHAAAIAIAAFMAC/AeAAAAfwAAAAQAgADYR0QBvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACt ACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQBEAQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIA AAASAArwCAAAAAMcAAAgAgAAUwAL8B4AAAB/AAAABACAABxKRAG/AQAAAQD/AQAAAQABAwMEAAAA ABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAEQBDwAN8AwAAAAAAJ4PBAAAAAEA AAAPAATwSAAAABIACvAIAAAAARwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1o AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kA AJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA AOsuCAAAAOt5xAHgswIgDwDuAyQCAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAMMA8A DASUAQAADwAC8IwBAACQAAjwCAAAAAMAAAADJAAADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAACQAAAUAAAAPAATwcgAAABIACvAIAAAAAiQAACACAABTAAvw HgAAAH8AAAAEAIAAkO9EAb8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAArQAgAWAVfQMPABHwEAAA AAAAwwsIAAAAAAAAAA0ARAEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADJAAA IAIAAFMAC/AeAAAAfwAAAAQAgADg80QBvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADwAyABYBUT Dw8AEfAQAAAAAADDCwgAAAABAAAADgBEAQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArw CAAAAAEkAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgA AAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAADrecQBAKua Ug8A7gMkAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcADDAPAAwElAEAAA8AAvCMAQAA sAAI8AgAAAADAAAAAywAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAAAsAAAFAAAADwAE8HIAAAASAArwCAAAAAIsAAAgAgAAUwAL8B4AAAB/AAAABACAACxf RAG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAAN AEYBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAywAACACAABTAAvwHgAAAH8A AAAEAIAAAFtEAb8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsI AAAAAQAAAA4ARAEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABLAAAAAwAAIMA C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoP EAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAA63nEAbBrCaUAAHIXJAAAAAEAgAAA AAAA/gsAAKoVAADWFwAAAhoAAC4cAABaHgAAhiAAAAAA9Q8cAAAABQEAANkYAAMAAAAAsiIAAAEA AAAIAAAAAQD3dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAG AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAAP7/ //8VAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAD+/////v////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////+/wAABQECAAAAAAAAAAAAAAAAAAAA AAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAC0BAAACwAAAAEAAABgAAAAAgAAAGgAAAAEAAAAhAAA AAgAAACYAAAACQAAAKwAAAASAAAAuAAAAAoAAADcAAAADAAAAOgAAAANAAAA9AAAAA8AAAAAAQAA EQAAAAgBAAACAAAA5AQAAB4AAAAUAAAAU2VuZGVyIElEIERyYWZ0cwAAAAAeAAAADAAAAEppbSBM eW9uAAAAAB4AAAAMAAAASmltIEx5b24AAAAAHgAAAAQAAAAyAAAAHgAAABwAAABNaWNyb3NvZnQg T2ZmaWNlIFBvd2VyUG9pbnQAQAAAAEBfQZsBAAAAQAAAAHBeJKDrecQBQAAAALC9ZTvtecQBAwAA AIsAAABHAAAApAMAAP////8DAAAACACJEGcMAAABAAkAAAPKAQAABQAnAAAAAAAEAAAAAwEIAAUA AAALAgAAAAAFAAAADAJ5AKEAAwAAAB4ABwAAAPwCAAD///8AAAAEAAAALQEAAAgAAAD6AgUAAAAA AP///wAEAAAALQEBAA4AAAAkAwUA////////eACgAHgAoAD///////8IAAAA+gIAAAAAAAAAAAAA BAAAAC0BAgAEAAAALQEAAAQAAAAnAf//HAAAAPsC9v8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAAC HwAAADIKNgAsABAAAABTZW5kZXIgSUQgRHJhZnRzBwAFAAYABQAGAAMAAwADAAcAAwAHAAMABQAD AAMABAAEAAAALgEAABwAAAD7AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQAAAAAAAAAAAAAYAAAA AQAAAACnFwDkBAAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avn/AAAAAAAAkAEAAAAAAEAAAEFyaWFs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAhMAAAAyCksAQgAIAAAASmltIEx5b24EAAIABgACAAQAAwAEAAQABAAAAC4BAAAEAAAALQEE AAQAAADwAQMAHAAAAPsC+f8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACJwAAADIKVAAuABUAAABN aWNyb3NvZnQgQ29ycG9yYXRpb24ABQACAAQAAgAEAAQABAACAAIAAgAFAAQAAgAEAAQAAgAEAAIA AgAEAAQABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC+f8AAAAAAACQAQAAAAAAQAAAQXJp YWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAA CQIAAAACGwAAADIKXAA5AA0AAAA0IEF1Z3VzdCAyMDA0ZgQAAgAFAAQABAAEAAQAAgACAAQABAAE AAQABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAADQCAAAQ AAAAAQAAAIgAAAADAAAAkAAAAA8AAACoAAAABAAAAMgAAAAGAAAA0AAAAAcAAADYAAAACAAAAOAA AAAJAAAA6AAAAAoAAADwAAAAFwAAAPgAAAALAAAAAAEAABAAAAAIAQAAEwAAABABAAAWAAAAGAEA AA0AAAAgAQAADAAAANEBAAACAAAA5AQAAB4AAAAQAAAAT24tc2NyZWVuIFNob3cAAB4AAAAYAAAA TWljcm9zb2Z0IENvcnBvcmF0aW9uAAAAAwAAAAIjAAADAAAAHwAAAAMAAAAGAAAAAwAAAAAAAAAD AAAAAAAAAAMAAAAAAAAAAwAAANgYCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4Q AAAIAAAABgAAAEFyaWFsAA8AAABEZWZhdWx0IERlc2lnbgARAAAAU2VuZGVyIElEIERyYWZ0cwAJ AAAAT3ZlcnZpZXcADQAAAFdobyBjbGFpbXMghQAlAAAARG9lcyBEb21haW4gQWNjZXB0IFJlc3Bv bnNpYmlsaXR5IIU/AA8AAABDdXJyZW50IERyYWZ0cwAZAAAAZHJhZnQtaWV0Zi1tYXJpZC1jb3Jl LTAyAAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAABAAAAHgAAABAAAABEZXNpZ24gVGVt cGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAABgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAPYPIAAAABQAAABfwJHj3iIAAAgA9AMDAADYSmltIEx5b24IAAAA SgBpAG0AIABMAHkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHgAAADgAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQD//////////wEAAAAQjYFk m0/PEYbqAKoAuSnoAAAAAAAAAAAAAAAA4HBhZXp6xAEVAAAAAAgAAAAAAABQAG8AdwBlAHIAUABv AGkAbgB0ACAARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIA AAADAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACIwAAAAAA AAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAoAAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAOQEAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAUAAAArAIAAAAAAAD//////////wMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA/v////////8W AAAAHQAAAP///////////v///xkAAAD9/////v///x4AAAD+//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////wEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAI AAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAD+////FQAAABYA AAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHwAAAP7////+//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////BAACAAIAAgAFAAQAAgAEAAQAAgAEAAIAAgAEAAQA BAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC+f8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAAC GwAAADIKXAA5AA0AAAA0IEF1Z3VzdCAyMDA0ZgQAAgAFAAQABAAEAAQAAgACAAQABAAEAAQABAAA AC4BAAAEAAAALQEEAAQAAADwAQMAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/ AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cI ACss+a54AgAANAIAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAAyAAAAAYAAADQAAAA BwAAANgAAAAIAAAA4AAAAAkAAADoAAAACgAAAPAAAAAXAAAA+AAAAAsAAAAAAQAAEAAAAAgBAAAT AAAAEAEAABYAAAAYAQAADQAAACABAAAMAAAA0QEAAAIAAADkBAAAHgAAABAAAABPbi1zY3JlZW4g U2hvdwAAHgAAABgAAABNaWNyb3NvZnQgQ29ycG9yYXRpb24AAAADAAAAAiMAAAMAAAAfAAAAAwAA AAYAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAA2BgLAAsAAAAAAAAACwAAAAAAAAALAAAA AAAAAAsAAAAAAAAAHhAAAAgAAAAGAAAAQXJpYWwADwAAAERlZmF1bHQgRGVzaWduABEAAABTZW5k ZXIgSUQgRHJhZnRzAAkAAABPdmVydmlldwANAAAAV2hvIGNsYWltcyCFACUAAABEb2VzIERvbWFp biBBY2NlcHQgUmVzcG9uc2liaWxpdHkghT8ADwAAAEN1cnJlbnQgRHJhZnRzABkAAABkcmFmdC1p ZXRmLW1hcmlkLWNvcmUtMDIADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAEAAAAeAAAA EAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVzAAMAAAAGAAAA AAAANAAAAAMAAAAAAPYPIAAAABQAAABfwJHj3iIAAAgA9AMDAADYSmltIEx5b24IAAAASgBpAG0A IABMAHkAbwBuAAAAAAAAAAAAAAAAACAAAAABAAAAJAAAAAAAAIAsAAAAAAAAAAIAAACwBAAAEwAA AAkEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_001_01C47A7A.662270BC-- From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 19:59: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 TAA21700 for ; Wed, 4 Aug 2004 19:59:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74NhGG2030187; Wed, 4 Aug 2004 16: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 i74NhGvB030186; Wed, 4 Aug 2004 16:43:16 -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 i74NhFUg030177 for ; Wed, 4 Aug 2004 16:43:15 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 2744828290 for ; Thu, 5 Aug 2004 01:43:14 +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 05343-02 for ; Thu, 5 Aug 2004 01:43:11 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 6B2A928292; Thu, 5 Aug 2004 01:43:11 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Slide decks from MARID meetings Date: Thu, 5 Aug 2004 01:43:10 +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: <200408050143.10924@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 jeudi 5 Août 2004 01:25, Harry Katz a écrit : > > Here are the slides that I presented this morning and that Jim is > presenting as I hit send. I am sorry, I cannot open documents which are provided in a non-standard and non-open format, for I do not have the necessary proprietary tools. Could you be so kind to send them again in an open format suitable for publication ? (Text, RTF, HTML...) so that everybody can have access to them ? -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 20:28: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 UAA23818 for ; Wed, 4 Aug 2004 20:28: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 i750CajR033202; Wed, 4 Aug 2004 17:12:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i750CadV033199; Wed, 4 Aug 2004 17:12:36 -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 i750CXOI033188 for ; Wed, 4 Aug 2004 17:12:36 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i750CasO021732 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 02:12:36 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i750CXAW003820 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 02:12:33 +0200 From: Hadmut Danisch Date: Wed, 4 Aug 2004 17:12:33 -0700 To: ietf-mxcomp@imc.org Subject: Minutes or summary? Message-ID: <20040805001233.GA3803@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, will there be some minutes or a summary of today's sessions and decisions (except for the jabber log)? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 20:52:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25165 for ; Wed, 4 Aug 2004 20:52:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i750fpcA035973; Wed, 4 Aug 2004 17:41:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i750fpw1035972; Wed, 4 Aug 2004 17:41:51 -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 i750foXk035940 for ; Wed, 4 Aug 2004 17:41:50 -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 i750fDCM012772; Wed, 4 Aug 2004 17:41:13 -0700 Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23FC8EBA-E678-11D8-8A0D-000A95CA7FAE@dbc.mtview.ca.us> Content-Transfer-Encoding: 7bit Cc: Andrew Newton From: Marshall Rose Subject: short-term milestones Date: Wed, 4 Aug 2004 17:41:08 -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 and i will be sending out draft minutes, etc., a little later on. however, we would like to draw everyone's attention to the following actions and milestones: 1. the -core document will be split into two documents, one talking about PRA, the other with everything else. 2. revised drafts (-core, -pra, -protocol, -submitter) will be submitted to internet-drafts by friday, august 13th. people having suggestions, nits, new security consideration items, etc., are urged to get them directly to the authors well before then (like between now and this friday). 3. final ipr statements are due monday, august 23rd. 4. working group last call on the revised documents begins monday, august 23rd. the co-chairs will be sending out a separate email on this topic closer to this date. thanks, /mtr From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 20:55:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25271 for ; Wed, 4 Aug 2004 20:55: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 i750jN6N036167; Wed, 4 Aug 2004 17:45:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i750jN3W036166; Wed, 4 Aug 2004 17:45:23 -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 i750jN3P036158 for ; Wed, 4 Aug 2004 17:45:23 -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 i750j8uk013084; Wed, 4 Aug 2004 17:45:24 -0700 In-Reply-To: <20040805001233.GA3803@danisch.de> References: <20040805001233.GA3803@danisch.de> 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@imc.org From: Marshall Rose Subject: Re: Minutes or summary? Date: Wed, 4 Aug 2004 17:45:19 -0700 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 Aug 04, 2004, at 17:12, Hadmut Danisch wrote: > > will there be some minutes or a summary of today's > sessions and decisions (except for the jabber log)? yes, but not for a few days. /mtr From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 20:57: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 UAA25392 for ; Wed, 4 Aug 2004 20:57: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 i750jDUE036144; Wed, 4 Aug 2004 17:45:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i750jDQ4036143; Wed, 4 Aug 2004 17:45: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 i750jDvl036137 for ; Wed, 4 Aug 2004 17:45: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 i750j8uj013084; Wed, 4 Aug 2004 17:45:08 -0700 In-Reply-To: <200408050143.10924@totor.bouissou.net> References: <200408050143.10924@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" From: Marshall Rose Subject: Re: Slide decks from MARID meetings Date: Wed, 4 Aug 2004 17:45:03 -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 On Aug 04, 2004, at 16:43, Michel Bouissou wrote: > I am sorry, I cannot open documents which are provided in a > non-standard and > non-open format, for I do not have the necessary proprietary tools. > > Could you be so kind to send them again in an open format suitable for > publication ? (Text, RTF, HTML...) so that everybody can have access to > them ? michel - the ietf accepts submissions in ppt format for meetings. perhaps someone will be kind enough to translate it into an alternate format for you. /mtr From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 21:00:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25558 for ; Wed, 4 Aug 2004 21:00:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i750oHpp037012; Wed, 4 Aug 2004 17:50:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i750oHFu037011; Wed, 4 Aug 2004 17:50:17 -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 i750oGHu037005 for ; Wed, 4 Aug 2004 17:50:16 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [130.129.129.89] ([::ffff:130.129.129.89]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 04 Aug 2004 20:50:20 -0400 id 00197690.4111844C.00002FD8 In-Reply-To: <0469C730-E596-11D8-A694-000393A56BB6@glyphic.com> References: <0469C730-E596-11D8-A694-000393A56BB6@glyphic.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6CE1954C-E679-11D8-A1FF-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: Discussing CSV Date: Wed, 4 Aug 2004 20:50:19 -0400 To: Mark Lentczner 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 Aug 3, 2004, at 5:42 PM, Mark Lentczner wrote: > Is CSV now open for discussion again? In keeping with our plan and given that we have tentatively agreed on milestones for CSV, the answer is yes. -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 21:03: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 VAA25806 for ; Wed, 4 Aug 2004 21:03: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 i750sxPw037264; Wed, 4 Aug 2004 17:54: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 i750sxuH037263; Wed, 4 Aug 2004 17:54:59 -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 i750swvn037257 for ; Wed, 4 Aug 2004 17:54:59 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Slide decks from MARID meetings MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 4 Aug 2004 19:55:00 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA937@srv1.pan-am.ca> Thread-Topic: Slide decks from MARID meetings Thread-Index: AcR6f5Cg4FmhI5AySs+Q9WpziYaPkwABunNg From: "Gordon Fecyk" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i750sxvn037258 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I am sorry, I cannot open documents which are provided in a > non-standard and > non-open format, for I do not have the necessary proprietary tools. Nice to see that IPR matters were resolved in a calm and collected manner. Do I detect continued hostility over this? -- 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 Aug 4 21:39: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 VAA27505 for ; Wed, 4 Aug 2004 21:39: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 i751SUa3039952; Wed, 4 Aug 2004 18:28:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i751SUZb039951; Wed, 4 Aug 2004 18:28:30 -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 i751STRm039944 for ; Wed, 4 Aug 2004 18:28:29 -0700 (PDT) (envelope-from millenix@zemos.net) Received: from fda.zemos.net (millenix-fda.no-ip.org[68.39.78.137]) by comcast.net (sccrmhc13) with ESMTP id <2004080501282901600e746re>; Thu, 5 Aug 2004 01:28:30 +0000 Received: from localhost (fda [127.0.0.1]) by fda.zemos.net (Postfix) with ESMTP id 9A3A3186C4; Wed, 4 Aug 2004 21:28:28 -0400 (EDT) Received: from fda.zemos.net ([127.0.0.1]) by localhost (fda.zemos.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07596-09; Wed, 4 Aug 2004 21:28:28 -0400 (EDT) Received: from [10.0.0.2] (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id DB807186C3; Wed, 4 Aug 2004 21:28:27 -0400 (EDT) Message-ID: <41118D3B.5040707@zemos.net> Date: Wed, 04 Aug 2004 21:28:27 -0400 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040726 Debian/1.7.1-4 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Michel Bouissou Cc: IETF MARID WG Subject: Re: Slide decks from MARID meetings References: <200408050143.10924@totor.bouissou.net> In-Reply-To: <200408050143.10924@totor.bouissou.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at fda.zemos.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Michel Bouissou wrote: > Le jeudi 5 Août 2004 01:25, Harry Katz a écrit : > >>Here are the slides that I presented this morning and that Jim is >>presenting as I hit send. > > I am sorry, I cannot open documents which are provided in a non-standard and > non-open format, for I do not have the necessary proprietary tools. Proprietary tools are quite unnecessary. Have a look at , specifically this last line: > Of course, you are free to use your old Microsoft PowerPoint > presentations, or save your work in PowerPoint format for sending to people > who are still locked into Microsoft products. Alternatively, use IMPRESS's > built-in ability to create Flash (.swf) versions of your presentations. Just because there is no published standard for the format of such files doesn't mean that there isn't Free Software that can work with it. > Could you be so kind to send them again in an open format suitable for > publication ? (Text, RTF, HTML...) so that everybody can have access to > them ? Alternative formats would certainly be nice. Philip Miller From owner-ietf-mxcomp@mail.imc.org Wed Aug 4 23:11: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 XAA02566 for ; Wed, 4 Aug 2004 23:11: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 i752sNIG047364; Wed, 4 Aug 2004 19:54: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 i752sNKQ047363; Wed, 4 Aug 2004 19:54:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ddg.com (mail.ddg.com [66.93.83.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i752sL7H047356 for ; Wed, 4 Aug 2004 19:54:22 -0700 (PDT) (envelope-from awd@DDG.com) Received: from [130.129.130.52] (account awd HELO [130.129.130.52]) by ddg.com (CommuniGate Pro SMTP 4.2) with ESMTP id 1446911 for ietf-mxcomp@imc.org; Wed, 04 Aug 2004 21:54:18 -0500 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: Content-Type: multipart/mixed; boundary=Apple-Mail-2--449410312 Message-Id: From: "Andrew W. Donoho" Subject: Re: Slide decks from MARID meetings...As PDF Date: Wed, 4 Aug 2004 19:53:42 -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-2--449410312 Content-Type: application/pdf; x-mac-type=50444620; x-unix-mode=0644; x-mac-creator=4341524F; name="IETF60 - Responsible Submitter.pdf" Content-Disposition: inline; filename="IETF60 - Responsible Submitter.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjM2IDAgb2JqPDwvSFs1MTYgMjAzXS9MaW5lYXJpemVkIDEvRSA0NzU3 L0wgMjAwMDYvTiA3L08gMzkvVCAxOTI0ND4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAgICAg IA14cmVmDTM2IDExDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDcxOSAwMDAwMCBuDQowMDAw MDAwNTE2IDAwMDAwIG4NCjAwMDAwMDA3OTkgMDAwMDAgbg0KMDAwMDAwMDkzMCAwMDAwMCBuDQow MDAwMDAxMDQwIDAwMDAwIG4NCjAwMDAwMDE0NTEgMDAwMDAgbg0KMDAwMDAwMTQ4NSAwMDAwMCBu DQowMDAwMDAxNTYxIDAwMDAwIG4NCjAwMDAwMDE5MjQgMDAwMDAgbg0KMDAwMDAwNDU5MiAwMDAw MCBuDQp0cmFpbGVyDTw8L1NpemUgNDcvUHJldiAxOTIzNS9Sb290IDM3IDAgUi9JbmZvIDM1IDAg Ui9JRFs8N2ZiNDZhNzk5ZmY0NmI1YTYxYjFkYjc3ODI3YTZiM2M+PDIwZTQwOTM2ZTY4YTExZDhh MGI4MDAwYTk1NjZhMzUwPl0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAgICAgICAgICAgICAgICAg ICANMzggMCBvYmo8PC9MZW5ndGggMTI0L0ZpbHRlci9GbGF0ZURlY29kZS9MIDEzOS9TIDkyPj5z dHJlYW0NCnjaYmBgYGFgYAphYGZgYO5m4GFAAB6gGAsQcjQwMOzbsI6B8YuGULdswSRPBQYGkzaT aSbLTLaZHDO5xsCBDJFUAs2QZGAwmAikOYCYD2yqEgMPm4CP+AQGpoWeSxY0Syuuk0ycItl4HCwp z8Bg7QakmYDYGiDAAF/UGewNZW5kc3RyZWFtDWVuZG9iag0zNyAwIG9iajw8L1BhZ2VzIDMzIDAg Ui9UeXBlL0NhdGFsb2cvUGFnZUxhYmVscyAzMSAwIFIvTWV0YWRhdGEgMzQgMCBSPj4NZW5kb2Jq DTM5IDAgb2JqPDwvQ29udGVudHMgNDQgMCBSL1R5cGUvUGFnZS9QYXJlbnQgMzMgMCBSL1JvdGF0 ZSAyNzAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNl cyA0MCAwIFI+Pg1lbmRvYmoNNDAgMCBvYmo8PC9Db2xvclNwYWNlPDwvQ3M2IDQyIDAgUj4+L0Zv bnQ8PC9UVDIgNDEgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSA0MyAw IFI+Pj4+DWVuZG9iag00MSAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2Rp bmcvQmFzZUZvbnQvQXJpYWxNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIyL1N1YnR5cGUvVHJ1 ZVR5cGUvRm9udERlc2NyaXB0b3IgNDYgMCBSL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDI3OCAwIDI3OCAyNzggNTU2IDAgNTU2IDAgNTU2IDAgNTU2IDAgNTU2IDAgMCAwIDAgMCAw IDAgMCA2NjcgMCA3MjIgNzIyIDY2NyA2MTEgMCA3MjIgMjc4IDAgNjY3IDAgODMzIDAgMCA2Njcg MCA3MjIgNjY3IDYxMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCAwIDU1NiAy NzggNTU2IDAgMjIyIDAgMCAyMjIgODMzIDU1NiA1NTYgNTU2IDAgMzMzIDUwMCAyNzggNTU2IDUw MCAwIDUwMCA1MDAgNTAwXT4+DWVuZG9iag00MiAwIG9ialsvSUNDQmFzZWQgNDUgMCBSXQ1lbmRv YmoNNDMgMCBvYmo8PC9UeXBlL0V4dEdTdGF0ZS9TQSBmYWxzZS9PUCBmYWxzZS9TTSAwLjAyL29w IGZhbHNlL09QTSAxPj4NZW5kb2JqDTQ0IDAgb2JqPDwvTGVuZ3RoIDI5NS9GaWx0ZXIvRmxhdGVE ZWNvZGU+PnN0cmVhbQ0KSIl0kNtqwzAQRL9A/zCPLdSybraTxzRJL5RAWwv6nBgluDR2KrnXr+9K CSmklF2E0M6cWfTKJFowXYK6MAKVEvCOPaFj+TSUaAJkqtDQy3UtsQl/5Wv2cBxeWpZbq8hi10wg M4KLEfangFGak3VccSLY7TFEpIohGSkFmRsWL8LAfrCzRxd2fRfa1YtD/bbatsPg/Ll9jgHKgFpA jyVXtFXJKxXR4shQiTHpUC/sPWrn39vGYf45OEL2XeQYXhCJ6zHsbG/6XUEm++3cXqEUUZxJXmhk MY7U2YlcJ3m97DBr3aa/wHSSNuUVsoKbfcLJbjdL779wtxy+D3yR+Fr+H7BoG9+Hfj1g2vsdjz7J jUk2dcgg2Sg3uaJvjPO5ZT8CDABcnXSSDQ1lbmRzdHJlYW0NZW5kb2JqDTQ1IDAgb2JqPDwvTGVu Z3RoIDI1NzUvRmlsdGVyL0ZsYXRlRGVjb2RlL04gMy9BbHRlcm5hdGUvRGV2aWNlUkdCPj5zdHJl YW0NCkiJnJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkIARJCSNgFQUQFFEVEhKqVMtZt dEZPRZ0urmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v3d+9953zAKAnpaq11TAL AI3WoM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4HkGm9IkzKwDDw/4kt1+kN AEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jnaxAqNVoGzKWedQqMw8Wmc V9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6PidLgvMCAMh01Ttc+g4b lA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5NpGwGYv/OcOKbaYniRg0Wh wcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0AjK8EwPLmW5vL+wAw8b4d vvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/JgccoymbHKgJnqJq+uqjbqsVqd TK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/UxN/ZdhPND/XuLhjrwGv2Aew LvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NWrZqLk2TlYHKjvm5+z/RZAgKg AibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAddIEesB5sAsNgOxgDu8F+cBCM g4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflDYigSiodSoSyoACqBVJAWMkIt 0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vBvrAYjoFT4Bx4CayCa+AmuBNe Bw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV6UYGkVFkP3IMOYtcQSaRR8gL lIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBFCCNICYsIKkI9oYswSNhJ+Ihw hnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF8iJFkNJJMpKB1EXaQtpH+ox0 mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVBaaT0UcYoxygXKdOUV1Q2VUCN oOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gcuiddQi+iG+nr6B/Sj9O/oj9h MBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElhujJjmEuZTcxB5iHmReYjFoXl xpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifnA84pzl0uwnXmSrhy7gruGPcM d5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g/zr/pYWdRYyF0mKNxX6L yxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+xfmTDswm3kdt02xy0uWkL 23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEOaocBh88c/oqZYzFYFTaE ncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5tLjsdbnpSnEVu5a7bnY9 6/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+9IQ9gzzLPUc8L3rBXsFe aq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB71ve1X5Bfld+Y3y0RR5Qs 6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauCTgb9IzgkWB+8P/hBiEtISch7 ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0CwQLlgbMHdCKcIWcSOiMlILLIk 8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBImWSY5HofEJcZ1x03Ec+Jz44fj v05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06hp2SnDKd8k+qZqk89lganJadt TLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc7OLsPdlPc2Jz+nJu5brnGnNP 5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdvWjxdFFTUVXR9iWBJw5JzS62X Vi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUDigfKCGW/8l5ZRFl/2X1VhGqj 6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxtpfZ0tX11Q/UlnZeuSzdZE1az qWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqGC42ejWsa7zUlNP2mGW2WN59s cWxpb5laFrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/In/FsU67zuWdd1cmrtzbZdal 77qxKnzV9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW/riubN1EX3DftvXE9dr11zdE bdjVz+5v6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCkAVv+mLiZJJmQmfyaaJrVm0Kb r5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfg qFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1 E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48Jf wtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQ utE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p 36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7iju tO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L /tz/bf//AgwA94Tz+w0NZW5kc3RyZWFtDWVuZG9iag00NiAwIG9iajw8L1R5cGUvRm9udERlc2Ny aXB0b3IvRm9udEJCb3hbLTIgLTIxMCA5NzkgNzI5XS9Gb250TmFtZS9BcmlhbE1UL0ZsYWdzIDMy L1N0ZW1WIDg4L0NhcEhlaWdodCA3MTQvWEhlaWdodCA1MTkvQXNjZW50IDkwNS9EZXNjZW50IC0y MTEvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0xIDAgb2JqPDwvQ29udGVudHMgMyAwIFIvVHlwZS9Q YWdlL1BhcmVudCAzMyAwIFIvUm90YXRlIDI3MC9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQ3JvcEJv eFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzIDIgMCBSPj4NZW5kb2JqDTIgMCBvYmo8PC9Db2xvclNw YWNlPDwvQ3M2IDQyIDAgUj4+L0ZvbnQ8PC9UVDQgMjUgMCBSPj4vUHJvY1NldFsvUERGL1RleHRd L0V4dEdTdGF0ZTw8L0dTMSA0MyAwIFI+Pj4+DWVuZG9iag0zIDAgb2JqPDwvTGVuZ3RoIDYxMy9G aWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImck8tu2zAQRb9A/zBLaiGGpF7kss2jSIGgKSyg i6QLRaIdtnq4FG23H9J+b4eU7RhJAwSFBEKWxTMz917+iDgYiNIC8M4zBqVgYHX0BYbo7HwqoJmA h2tq8M2HBYfV9PLzZfT5+Of7Kjqrqgy3VMuIQcJTqgTMK4OipAJkSbmAqj+WYOHyJRhUjV92ERFx 9c0DsrA12wMyJajC4iqlLPMMRhljym9LwmMZNi/00GoL1xfwaavt1ujdniYkZRLmFWlceUzJBZUe FhA8DU14WOFhd+R3nBS8JDcxp5xou0LyuATd6V4PbvLP+3q3Y2eaX/HX6iPuV0UucX7KVYGci4hc 2brXu9F+h3uyuL26j6EeWjivu25udTlauEz62nS+2eSJkKW58oTQU3bSU0EVSWNGMwLXg9N20A4u bL1009wDzpsB3gxSpqjMUP9invRJ6DvyJ05SmVJJWkQJ4vcnRrsltmJNmzSj1QkTByJK5g1Vsx9C Mi9lkbE91wt4Yoc8dpvnnBbkXYzvJelWozXusQ8ztxpb781ghhW4Rw3rjV2P1ukWszWtx2EyD52G um3x53QQl2EEURrBMnmQhsvnMfD6+gp6W3eb2vkCyNh0s2nIxtXpyR3CsRdLCEERexRrRvKXkqkg GX8h2dqObmzGLmHs37JxjHEp3i5b5WXLCYqDwcEZ0JMwWV+7ECI/BByqPvee54qiWv/j/bR56I1D e14NABeKFm8fZDH7f1Pd4pnBg9lo0D+dRo/HIVhlhtY0s1U+CycJeMV5cuzRe1oPoMMRgh7DUq+0 t/ayiv4KMAAV/UcwDQ1lbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmo8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnRCQm94Wy0yIC0yMTAgOTc5IDcyOV0vRm9udE5hbWUvQXJpYWxNVC9GbGFncyAzMi9T dGVtViA4OC9DYXBIZWlnaHQgNzE0L1hIZWlnaHQgNTE5L0FzY2VudCA5MDUvRGVzY2VudCAtMjEx L0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNNSAwIG9iajw8L0NvbnRlbnRzIDcgMCBSL1R5cGUvUGFn ZS9QYXJlbnQgMzMgMCBSL1JvdGF0ZSAyNzAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BCb3hb MCAwIDYxMiA3OTJdL1Jlc291cmNlcyA2IDAgUj4+DWVuZG9iag02IDAgb2JqPDwvQ29sb3JTcGFj ZTw8L0NzNiA0MiAwIFI+Pi9Gb250PDwvVFQ2IDI2IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9F eHRHU3RhdGU8PC9HUzEgNDMgMCBSPj4+Pg1lbmRvYmoNNyAwIG9iajw8L0xlbmd0aCA0MzkvRmls dGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJhJLdjtMwEIWfwO8wlylSvY6TJunl7lJQ0VZaWiMu WC5SZ9IGGrvY3gUehPdlnP4JQYUcWfLP+ebMcb6xFDpgWQH0TXIBpRTgkH0Ew27ufQHaQzoMr2nn 7SqFjf/7esvenw/vFLtRqiCJapmAcZrxqYTDLKAouYSq5KkE1Z9LiGHEEgKUjtN3lmQj9SUC8kGa HwH5VPIpFZcZHxCCCxFhmiWrD3eLuVKz5VGYpVFymEmYVjyTUKaSV1E4jkpRxFKfkl+jcT6tuExm I9rPkx8Bje+sgWBhtVCPsLidP4C2fV+bZvRZvRs641k6IdbrI2vyBytLHjD4g1rvOjQBGtS72iHs n93euoBHEq9y6ohwopJlxCUO/d6SgfUOoW4aWnp4Sh6Xt08j6AzUZsDGNtWrQwLFJbeTSzodX9gn q5e8/mfao3tBB3t0rXU9kCPbgt6i/tqZzTXna6TLCD05rjcIa9v8hM4Ti9qvtbPUSNjiyfngd24C OoPhiuF/v9MivlOVPPsAfR30NlKBAoLaU8yue8EGWmf7Kz6HFPLhr1m+uZeVlGfLW6wJ4KObmWK/ BRgAKmHObQ0NZW5kc3RyZWFtDWVuZG9iag04IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9G b250QkJveFstMiAtMjEwIDk3OSA3MjldL0ZvbnROYW1lL0FyaWFsTVQvRmxhZ3MgMzIvU3RlbVYg ODgvQ2FwSGVpZ2h0IDcxNC9YSGVpZ2h0IDUxOS9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMS9JdGFs aWNBbmdsZSAwPj4NZW5kb2JqDTkgMCBvYmo8PC9Db250ZW50cyAxMSAwIFIvVHlwZS9QYWdlL1Bh cmVudCAzMyAwIFIvUm90YXRlIDI3MC9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQ3JvcEJveFswIDAg NjEyIDc5Ml0vUmVzb3VyY2VzIDEwIDAgUj4+DWVuZG9iag0xMCAwIG9iajw8L0NvbG9yU3BhY2U8 PC9DczYgNDIgMCBSPj4vRm9udDw8L1RUOCAyNyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0 R1N0YXRlPDwvR1MxIDQzIDAgUj4+Pj4NZW5kb2JqDTExIDAgb2JqPDwvTGVuZ3RoIDkzNC9GaWx0 ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImMVdly00oQ/QL9Qz9KFB5mk0ZyBYrgmEsoTCBWiiqW B1kagriSZSznkvz97RmNLC9JoLxIrZk+fXrRmV8egxI8EQF+Q0lBcQpr7X2Cpfds0kaQt8Dsp83x yT9zBtft8fbv3sft4qvUe5amMbqk3z0KIyZIwqH7pxApwiFWhHFI620Iaj8mBIU0N3+/PV8G6U8L gFgxLsuQkzgGxWISG+cRJZRSZh3wjgnj9cWfj4EjqywYJX51Uy9LklV1VmcbvSa6uAlGIQl9CEaK JP50Pks/QKvX/+k15pEVd8G39K0NijTTM0fHxFEd+mQM0zfvLkAHI8YJ828D6mf1qtIkb2rrnD45 ZEYtM0sspKPsPlKYKfoN0fiux9n8vdvQPzm9St/01SGcCWG49ovzq1ez8zSdXg47dpZhfv556uDu 5WlznJ2ev4PXlxez8UlWlbl+qW+HLLF0yn9hLtyHbbTnxxtdOQ6isKFPSOckiIj0sVsRVvMQAYMw ZqK0ellgi5p/9zD5dlgs6cvJhxTSi/HJIhjFfrN4eV+pXzzapD1a3F8YWuIhKDNK3BSCUR+nJy9X pV5uDkkeJG6Inp2mp4+1wJAQoUSk7O6pzR1q3bbZtb5/UGz2r9dNPYZAdbUMj2r5+HAiwFffBYFF U9zBdaNb+KHX+mtwNGoPJUb2R+6x96DPCLI816uNLvrUHoD+eHWe/qlmnKMCNU2xuNOOiLSyI534 yISTJIIIS4v6YX0TgzIa3nB/2lUMX4GsrGB+s6jLti2bpQGcpuikVCQVUJJQhlh4ZUKJTh6Nmk3m Ts3mk/corm9RB3/iLsXhN8Qwgy/fKBSd6krBjKBJxqDeGiIhFC9cocjJqHvGRX+beyJWvVGhwUxC zhZK7UD0FqKjVyhJLCFECY2MX7cmhCRSDjbHGmwNpmIS4Z4uBAtD64HR3W3uGV7OqLyOsTNdMg7C WQY930268hZPzHGxq/E0NqWS1B4Pw7HwQMt77QF9u9HLvk04fng8bXUvK1DdN2WrCyiXnXqvdbtq lq3+i6aypEuF2kvd264qCZ5kZqC6/IS5RK46PGSDWaGJteh3RmLAcIYLgH7OTlyPeRKb6RVcmkOz 6te57IGdbaChi8LjruAdA2chckfQ2ZXn2DvbBexwekO6ZPoq9KSOGsclJfhj+A5GZvr2urfTvP2+ uW7J+A+SscrWWa1RdiErCuzjprHvN4mjSA2NtocWKl2dLQvX2f8FGABL2xODDQ1lbmRzdHJlYW0N ZW5kb2JqDTEyIDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFstMiAtMjEwIDk3 OSA3MjldL0ZvbnROYW1lL0FyaWFsTVQvRmxhZ3MgMzIvU3RlbVYgODgvQ2FwSGVpZ2h0IDcxNC9Y SGVpZ2h0IDUxOS9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMS9JdGFsaWNBbmdsZSAwPj4NZW5kb2Jq DTEzIDAgb2JqPDwvQ29udGVudHMgMTUgMCBSL1R5cGUvUGFnZS9QYXJlbnQgMzMgMCBSL1JvdGF0 ZSAyNzAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNl cyAxNCAwIFI+Pg1lbmRvYmoNMTQgMCBvYmo8PC9Db2xvclNwYWNlPDwvQ3M2IDQyIDAgUj4+L0Zv bnQ8PC9UVDEwIDI4IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzEgNDMg MCBSPj4+Pg1lbmRvYmoNMTUgMCBvYmo8PC9MZW5ndGggMTA3Mi9GaWx0ZXIvRmxhdGVEZWNvZGU+ PnN0cmVhbQ0KSImUVtty2zYQ/QL+wz5SmQrBjSCoSTO2FaVxxqoTi5nO1MkDRSIOU0l0RY0vf98F CEK041sljcRDYnfP7lks9G/EoIZIKMBPIimknMLWRH/BJno9bRWULTD3bku888eCwUX76/Lv0efw 8CiPXuc5o2iTf48ojJkgGYfum4JKCQedEsYhX4cY1L1tDAp5ab+uozgZ5T+tA+lMpXeQUEW0BkUF 0dL6oIRSmlmzsbtMnfHsplhfrswE5kW9qjcXcFK3O++QacAPBZkqwhSkghIdPDFHAK8Ys47O48UE OKZpRmNNdHwzooTFzjcpmzWMxinenS3m+SdozfbKbLEgRXU7+pZ/dLEw3fydTyvQO4+nE5h9ODmF 1WjMOHqs0S+P2525Cb6di/yVTyvwosIlaGkldDxcj9nh8n0oPly4+HI0P87z2Zlf5u/D4vjvWW9p s9aB3/zw+ATej8YZUfGZo3c6n7xprjdmO15hNdmB/R4SwFok8due94AD2Fdg8PtTPjoqT+UMT3F4 iypsKlSh+WeQlaXh28qldjb9lEN+OnlTWFVZvKpLczD0MpCPCeEUvEto0ByW0UgRGaMz9aCzMWNE xNgYZX1Zm83OkrvbH5bUu8P88Ln0RSLRuLj9zaUJa9O2xYV5RHmbqClNfWUqOLqdACHEr3RFeL9t 1hMYpfHS8k7iZnlw3TTVxba5ekH/oYOFq/QEnpfzAWZ5M4H/3wFo+DX2WcOyqW7hojEt/DBb83U0 FPyeUtaQ9Ns/aPpkl/VRirI0lztT7a0fawcb5POX4/zZHuY4KbHSy1un3CzH52mqZAqUZJRlyv4y kYpu6toZOV34GbmY/okz+yNO15+4KuVwDRrmcP6NQtUNcykzOyAFSwh6WgeMAzRRIGWCw06oxN6T kvWXZSSZJlL2eOWw0pAkkqTKYprsH4oss949FlkyCNGjjkAZecyYjbzqodZYSO/Gs8EAgQwyC0Qc 5Z5xFoz9dee3vJf3Klq+smfRcNxzZQsmqLbr7LwPp04cZhOYm53ZtHWzsdKg2njShU1aVDjfd3WL +6nedPN7a9rLZtO+REiOx57lS5n9WfdYM8uXZ8KeRV2WPHOp9MUQMt1DLCAq0q8USbb34YEPgHYd 5jIYdli5FnBeuGadci6CR9ZSEIW9ILU9qNGSZ4Pnq8gTHGDH3mOfWBenB9In01ch86a/yCSEIlzi JlGE3pNpsKG6vTQ801AlqYNWD2++y2JbrM0Oj4eiqlDFXeN2NdFKpXuZ3cGHk2hdbKoX6MqS5I6u HneasGTQ4UztO5zTfYdzuu9wTgeKehAU9Tgo2uOu0rSrd6cBug9ystRt7SAX09T+eZKU2/ZGjLz2 DzvGHvtkugg96LXsM39US6aV86XcPrq35bpz+gf+W+r1sMXmhN8RY9cMTzmU4j8BBgBrK4HlDQ1l bmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFst MiAtMjEwIDk3OSA3MjldL0ZvbnROYW1lL0FyaWFsTVQvRmxhZ3MgMzIvU3RlbVYgODgvQ2FwSGVp Z2h0IDcxNC9YSGVpZ2h0IDUxOS9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMS9JdGFsaWNBbmdsZSAw Pj4NZW5kb2JqDTE3IDAgb2JqPDwvQ29udGVudHMgMTkgMCBSL1R5cGUvUGFnZS9QYXJlbnQgMzMg MCBSL1JvdGF0ZSAyNzAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYxMiA3OTJd L1Jlc291cmNlcyAxOCAwIFI+Pg1lbmRvYmoNMTggMCBvYmo8PC9Db2xvclNwYWNlPDwvQ3M2IDQy IDAgUj4+L0ZvbnQ8PC9UVDEyIDI5IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8 PC9HUzEgNDMgMCBSPj4+Pg1lbmRvYmoNMTkgMCBvYmo8PC9MZW5ndGggMTA4Mi9GaWx0ZXIvRmxh dGVEZWNvZGU+PnN0cmVhbQ0KSImMVtty2zYQ/QL+wz6SmQoBQPCmcTOxZbVxJooTi57O1MkDRSIu U5F0ReWiv+/iRkqK7MTyUDwgdvfsnl1Q/3kMavDCGPA/EhQSTmEjvb+g9Z7P+hjKHpj+9CWu/Llk cN//uP2T9354eJF7z/OccbTJP3kUJiwkGSJ9pRAnhEOaENyQN0MMqj8qBoW8VJdvnh8H+WflQGhT YR1ElJEYYsYIT5ULSiilmbKa6NtE286/F83DWk5h0a3qtYTbXm6Uu3mOBkkSiwQoySjLYvXNwiQ0 GSo+s6Xls5y9xfq8xkw+466EwzdIYQF3HylUpnBCZCRNIWQRQU/NgJFsFIMQEUEQR2pNCOZuS0+w lAjh8NoLk1jhSCREQUGjvWdZppxbHGbRXgSHTPzSs5ixiBhTDdMUa27dWDIYYOCCxFwsw9gRzgZj e2/8lkdpr73VMyW70hr3pFg5wWNVr5Cmap9SaRDYqMS0zOou1Hotby8WV3k+vwH5fSvbvu5aJdeE Eew0vGK3XHp+UX2Vm23dywrqFuav3lxj9/UPXdvLXxCXY9upJLCB8KtxOGUqCZ6FhLny8Ezn5yoU imSEWNVIELczjLLRhwU2ANoZzMVgaHCs20J74SkzcuoIFqEl28doyajuF5wiBS2/4bElb7HNy4Rx QNhcXBEya/qDdGEYEy6Ao4L0SLo95Q5Fs1KJdJDqtMoPxaZo5FZuoKgqFHHb6REnaRwno8qL86s3 UHZNU7TVL8jKouhAVouNJCza63oWj13P6dj1nI5dz+meoBYMglo8COqwqTQ19TYaoPtBTZboaR/k YimmLLToQkGkNT4zhC22uZgADjgpXeKPSsnSWPuK9RQdSOkvZVuhDv/IonJyqFpzwg+02HbQyL4v 7vWATXhKQoHPsT31Ptyi5GVa3jt/OcW+oVAEk8xfB5Qw/0vT1qRYN0VToOxEVl+CSUQiH4JJQjJ/ vlzk7wDPZpxrHOWi2gUf89c6B0NAN09qvM+mZuTLYMKQp49j363rCh1XiqNs7zFCK7faRf7s4HhB YhGdFOsTfDAvtXloVb5vcbl8aze4lfPb/NXR0sEcjOuwvPp7bpdOzoNOSXf7HzfXi+lZsa5L+VKa VxfBCVBFSvwXQ0KHHO98UH9D9N+DiIS+cVI+WRxTXxaGQ4lHZmyUElM4C/DF5KOgMYp5TO8FCoGt 5aOAupm6f0+px4cDQ+d7M3uXQ349PVsFkxSddquXp2QZkn6kcnv8uL9S/MLHXKmO474iS31ssrJ+ qGW7dWxdoxxVQFG9PM/Pn9JPkcBjHD0Vu990EfaHxVlx586M3BR+ptDphlSlk6Wsv+K5ebGbAiHk SW64/4Nv6cCqq3Zw38keB34jPwQuxiOJE/vLa2ySR/NXIrgoRVnKh605SI6a4ESQ97dX+c+qyzn+ puy6arVzL/j/BRgA5zl/5Q0NZW5kc3RyZWFtDWVuZG9iag0yMCAwIG9iajw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udEJCb3hbLTIgLTIxMCA5NzkgNzI5XS9Gb250TmFtZS9BcmlhbE1UL0ZsYWdz IDMyL1N0ZW1WIDg4L0NhcEhlaWdodCA3MTQvWEhlaWdodCA1MTkvQXNjZW50IDkwNS9EZXNjZW50 IC0yMTEvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0yMSAwIG9iajw8L0NvbnRlbnRzIDIzIDAgUi9U eXBlL1BhZ2UvUGFyZW50IDMzIDAgUi9Sb3RhdGUgMjcwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9D cm9wQm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXMgMjIgMCBSPj4NZW5kb2JqDTIyIDAgb2JqPDwv Q29sb3JTcGFjZTw8L0NzNiA0MiAwIFI+Pi9Gb250PDwvVFQxNCAzMCAwIFI+Pi9Qcm9jU2V0Wy9Q REYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDQzIDAgUj4+Pj4NZW5kb2JqDTIzIDAgb2JqPDwvTGVu Z3RoIDkwMy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImkVdFu2zYU/QL9w32UB5gVJZqy sKc2S4cOC9Y5avdQ9EGRKIebRbqkFDcfsn3v7qVtJVbcFGhgQ5At8txzzzlX/BJx0BBlEvC7EAnk aQJORX+BiV5deAm1Bx4+vsZ/fr3msPZPl7fRn+PDN2X0qiy5wD1lGyUw5xkrUthfE5A5S2GZM55C 2Y01kvChGgmUNV12UZzPyr8JQISt4gAgipQVEmS6oN+IkbAkSQraNg+3edh8cVuZtfKgDcyTFD4q 57U1B0S+BPwiVpYysYScp2xJUHsAHijQXUZQn+J/Z3POF5Ll8fUMl/BY1T2CgWB89rn8LSBKliBo uCJuAJS5fASb5kdY1CbA/jebL0XBFoiaMBn3Tpl1f6uMaqC2prWuq0ytUN8vg3aqU6b3P8P1hzdX 78rycgXG7gBXNFVv3T3scGMgw5lA3liyWCxQn18O1SVVj69ev/sd3q7+uIJGty1qAq2zHbxfvQZE wlK17bBQgxQIEB7Wa5SyQQq6rjakYvnT47bi3hIIoyfzAwPOUrLlhMDYtIhXM9Sxs3dUyrpGmzVU N3bosad/6MfgFdj2Ub/qa68Mmfio66p/rudsNLIImfC2U9AO/eAU9LpTE7q8ELQ3WHTiEI+vZpwV cSCLDsHW2Vo1g6s20ChfO72lPKCY1mHgdK/xQae8r9YK/HDTaR94I+3n6IqgJK736DhKPUI41bvK +CMMak0kjDVzQyHp9Z2Cy69Vt91g4P0+nGwS9bTgTL4g6en5pKc5pzGcRF2MUT8VMiXX8Xrwnbo4 9f4oLPaBXd4oSkGDLsPUuu/mfTJt8SFOVPJcpG4o+Vh1jNbZaOyh09NYHbtDyXBhrNdGtzgl6J9T x+6wGa/RH93eh0GrN5Wje6Jzp1zYEIQOAngfFinnrJv0mJNnRyLFw7vyEBX/xPYEXy3iBb5n533n yyS8hU99HwduOj8XKE0Wh6b1xHiURpt6MzQKqs0G6sqjDejUMfzT6Fch+M9ZX4wsFkGbB7+rXYX5 8cqh5lOluBAvOQsW39ApFU9PAjkSzE50EqRTHA4udH8/0FA1DY6DHycCc4o5onjtdH8Lq7cXkMpE juWP7SQZk0vk/6MNyfMNLTOWS0T5lvOnM4Fwq2D9OAkU7NbWA3ps6F01ON3f03nn8Xhx1f496req ppnYv+rw6MGx2FqPJw9xuiyj/wUYAGHCV4YNDWVuZHN0cmVhbQ1lbmRvYmoNMjQgMCBvYmo8PC9U eXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRCQm94Wy0yIC0yMTAgOTc5IDcyOV0vRm9udE5hbWUvQXJp YWxNVC9GbGFncyAzMi9TdGVtViA4OC9DYXBIZWlnaHQgNzE0L1hIZWlnaHQgNTE5L0FzY2VudCA5 MDUvRGVzY2VudCAtMjExL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMjUgMCBvYmo8PC9UeXBlL0Zv bnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L0FyaWFsTVQvRmlyc3RDaGFyIDMy L0xhc3RDaGFyIDE1MC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDQgMCBSL1dpZHRo c1syNzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAwIDMzMyAwIDAgNTU2IDAgNTU2IDU1NiAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDY2NyAwIDcyMiA3MjIgNjY3IDYxMSAwIDAgMjc4IDAg MCAwIDgzMyAwIDc3OCA2NjcgMCAwIDY2NyA2MTEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2 IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMCA1MDAgMjIyIDgzMyA1NTYgNTU2IDU1 NiAwIDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzUwIDU1Nl0+Pg1lbmRvYmoNMjYgMCBv Ymo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L0FyaWFsTVQv Rmlyc3RDaGFyIDMyL0xhc3RDaGFyIDE0OS9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9y IDggMCBSL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAwIDAgMCAwIDAgMCA1 NTYgNTU2IDAgMCAwIDAgNTU2IDAgMCAwIDAgMCAwIDAgMCA2NjcgNjY3IDcyMiAwIDY2NyA2MTEg MCAwIDI3OCAwIDAgNTU2IDgzMyAwIDAgNjY3IDAgNzIyIDY2NyA2MTEgNzIyIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIyMiAwIDUwMCAyMjIg ODMzIDU1NiA1NTYgNTU2IDAgMzMzIDUwMCAyNzggNTU2IDUwMCAwIDUwMCA1MDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzUwXT4+DWVuZG9i ag0yNyAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQv QXJpYWxNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERl c2NyaXB0b3IgMTIgMCBSL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAyNzgg MzMzIDI3OCAwIDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDAgMCAwIDAgMjc4IDAgNTg0IDU4NCA1 ODQgMCAxMDE1IDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDAgNzIyIDI3OCAwIDAgNTU2IDgzMyA3 MjIgNzc4IDY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDAgMCAwIDAgNjExIDAgMCAwIDAgMCAwIDU1 NiA1NTYgNTAwIDU1NiA1NTYgMCA1NTYgNTU2IDIyMiAwIDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2 IDAgMzMzIDUwMCAyNzggNTU2IDUwMCAwIDUwMCA1MDBdPj4NZW5kb2JqDTI4IDAgb2JqPDwvVHlw ZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNlRm9udC9BcmlhbE1UL0ZpcnN0Q2hh ciAzMi9MYXN0Q2hhciAxMjEvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAxNiAwIFIv V2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI3OCAzMzMgMjc4IDAgNTU2IDU1 NiA1NTYgNTU2IDU1NiA1NTYgMCAwIDAgMCAyNzggMCA1ODQgNTg0IDU4NCAwIDEwMTUgNjY3IDY2 NyA3MjIgNzIyIDY2NyA2MTEgMCA3MjIgMjc4IDAgMCA1NTYgODMzIDAgNzc4IDY2NyA3NzggNzIy IDY2NyA2MTEgNzIyIDAgMCAwIDAgNjExIDAgMCAwIDAgMCAwIDU1NiA1NTYgNTAwIDU1NiA1NTYg MCA1NTYgNTU2IDIyMiAwIDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDAgMzMzIDUwMCAyNzggMCA1 MDAgNzIyIDUwMCA1MDBdPj4NZW5kb2JqDTI5IDAgb2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL1dp bkFuc2lFbmNvZGluZy9CYXNlRm9udC9BcmlhbE1UL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjEv U3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAyMCAwIFIvV2lkdGhzWzI3OCAwIDAgMCAw IDAgMCAwIDMzMyAzMzMgMCAwIDI3OCAzMzMgMjc4IDAgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYg NTU2IDAgMCAwIDI3OCAwIDU4NCA1ODQgNTg0IDAgMTAxNSA2NjcgNjY3IDcyMiA3MjIgNjY3IDYx MSAwIDcyMiAyNzggMCAwIDU1NiA4MzMgNzIyIDc3OCA2NjcgNzc4IDcyMiA2NjcgNjExIDcyMiAw IDAgMCAwIDYxMSAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2IDAgNTU2IDU1NiAyMjIg MCA1MDAgMjIyIDgzMyA1NTYgNTU2IDU1NiAwIDMzMyA1MDAgMjc4IDU1NiA1MDAgMCA1MDAgNTAw XT4+DWVuZG9iag0zMCAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2Rpbmcv QmFzZUZvbnQvQXJpYWxNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTUwL1N1YnR5cGUvVHJ1ZVR5 cGUvRm9udERlc2NyaXB0b3IgMjQgMCBSL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMzMzIDI3OCAwIDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMCAwIDAgMjc4IDAg MCAwIDAgMCA2NjcgNjY3IDcyMiAwIDY2NyA2MTEgMCAwIDI3OCAwIDAgNTU2IDgzMyAwIDc3OCA2 NjcgMCA3MjIgNjY3IDYxMSA3MjIgNjY3IDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDU1NiA1MDAg NTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMCA1MDAgMjIyIDgzMyA1NTYgNTU2IDU1NiA1NTYgMzMz IDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzNTAgNTU2XT4+DWVuZG9iag0zMSAwIG9iajw8L051 bXNbMCAzMiAwIFJdPj4NZW5kb2JqDTMyIDAgb2JqPDwvUy9EPj4NZW5kb2JqDTMzIDAgb2JqPDwv Q291bnQgNy9LaWRzWzM5IDAgUiAxIDAgUiA1IDAgUiA5IDAgUiAxMyAwIFIgMTcgMCBSIDIxIDAg Ul0vVHlwZS9QYWdlcz4+DWVuZG9iag0zNCAwIG9iajw8L0xlbmd0aCAzMzcxL1R5cGUvTWV0YWRh dGEvU3VidHlwZS9YTUw+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBD ZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4NCjx4 OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIu OS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4NCjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53 My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9i ZS5jb20vaVgvMS4wLyc+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDoyMGU5ZGE0 MC1lNjhhLTExZDgtYTBiOC0wMDBhOTU2NmEzNTAnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2Jl LmNvbS9wZGYvMS4zLycgcGRmOlByb2R1Y2VyPSdBY3JvYmF0IERpc3RpbGxlciA2LjAuMSBmb3Ig TWFjaW50b3NoJz48L3JkZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSd1dWlkOjIwZTlkYTQwLWU2OGEtMTFkOC1hMGI4LTAwMGE5NTY2YTM1MCcgeG1sbnM6eGFwPSdo dHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRvclRvb2w9J1Bvd2VyUG9pbnQ6 IGNncGRmdG9wcyBDVVBTIGZpbHRlcicgeGFwOkNyZWF0ZURhdGU9JzIwMDQtMDgtMDRUMTk6NDk6 NTAtMDc6MDAnIHhhcDpNb2RpZnlEYXRlPScyMDA0LTA4LTA0VDE5OjQ5OjUwLTA3OjAwJz48L3Jk ZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjIwZTlkYTQw LWU2OGEtMTFkOC1hMGI4LTAwMGE5NTY2YTM1MCcgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6MjBlOWI5NWUtZTY4YS0x MWQ4LWEwYjgtMDAwYTk1NjZhMzUwJy8+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVp ZDoyMGU5ZGE0MC1lNjhhLTExZDgtYTBiOC0wMDBhOTU2NmEzNTAnIHhtbG5zOmRjPSdodHRwOi8v cHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Zm9ybWF0PSdhcHBsaWNhdGlvbi9wZGYnPjxk Yzp0aXRsZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPklFVEY2MCAtIFJl c3BvbnNpYmxlIFN1Ym1pdHRlci5wcHQgW1JlYWQtT25seV08L3JkZjpsaT48L3JkZjpBbHQ+PC9k Yzp0aXRsZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48cmRmOmxpPkFuZHJldyBXLiBEb25vaG88L3Jk ZjpsaT48L3JkZjpTZXE+PC9kYzpjcmVhdG9yPjwvcmRmOkRlc2NyaXB0aW9uPg0KPC9yZGY6UkRG Pg0KPC94OnhtcG1ldGE+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9J3cnPz4NZW5kc3RyZWFtDWVuZG9iag0zNSAwIG9i ajw8L01vZERhdGUoRDoyMDA0MDgwNDE5NDk1MC0wNycwMCcpL0NyZWF0aW9uRGF0ZShEOjIwMDQw ODA0MTk0OTUwLTA3JzAwJykvVGl0bGUoSUVURjYwIC0gUmVzcG9uc2libGUgU3VibWl0dGVyLnBw dCBbUmVhZC1Pbmx5XSkvQ3JlYXRvcihQb3dlclBvaW50OiBjZ3BkZnRvcHMgQ1VQUyBmaWx0ZXIp L1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDYuMC4xIGZvciBNYWNpbnRvc2gpL0F1dGhvcihB bmRyZXcgVy4gRG9ub2hvKT4+DWVuZG9iag14cmVmDTAgMzYNMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDA0NzU3IDAwMDAwIG4NCjAwMDAwMDQ4ODUgMDAwMDAgbg0KMDAwMDAwNDk5NCAwMDAwMCBu DQowMDAwMDA1Njc0IDAwMDAwIG4NCjAwMDAwMDU4MzggMDAwMDAgbg0KMDAwMDAwNTk2NiAwMDAw MCBuDQowMDAwMDA2MDc1IDAwMDAwIG4NCjAwMDAwMDY1ODEgMDAwMDAgbg0KMDAwMDAwNjc0NSAw MDAwMCBuDQowMDAwMDA2ODc1IDAwMDAwIG4NCjAwMDAwMDY5ODUgMDAwMDAgbg0KMDAwMDAwNzk4 NyAwMDAwMCBuDQowMDAwMDA4MTUyIDAwMDAwIG4NCjAwMDAwMDgyODMgMDAwMDAgbg0KMDAwMDAw ODM5NCAwMDAwMCBuDQowMDAwMDA5NTM1IDAwMDAwIG4NCjAwMDAwMDk3MDAgMDAwMDAgbg0KMDAw MDAwOTgzMSAwMDAwMCBuDQowMDAwMDA5OTQyIDAwMDAwIG4NCjAwMDAwMTEwOTMgMDAwMDAgbg0K MDAwMDAxMTI1OCAwMDAwMCBuDQowMDAwMDExMzg5IDAwMDAwIG4NCjAwMDAwMTE1MDAgMDAwMDAg bg0KMDAwMDAxMjQ3MSAwMDAwMCBuDQowMDAwMDEyNjM2IDAwMDAwIG4NCjAwMDAwMTMxMDQgMDAw MDAgbg0KMDAwMDAxMzU2OCAwMDAwMCBuDQowMDAwMDE0MDA4IDAwMDAwIG4NCjAwMDAwMTQ0NDYg MDAwMDAgbg0KMDAwMDAxNDg4OCAwMDAwMCBuDQowMDAwMDE1Mzc3IDAwMDAwIG4NCjAwMDAwMTU0 MTIgMDAwMDAgbg0KMDAwMDAxNTQzNiAwMDAwMCBuDQowMDAwMDE1NTI3IDAwMDAwIG4NCjAwMDAw MTg5NzQgMDAwMDAgbg0KdHJhaWxlcg08PC9TaXplIDM2Pj4Nc3RhcnR4cmVmDTExNg0lJUVPRg0= --Apple-Mail-2--449410312 Content-Type: application/pdf; x-mac-type=50444620; x-unix-mode=0644; x-mac-creator=4341524F; name="SenderId040804.pdf" Content-Disposition: inline; filename=SenderId040804.pdf Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjMxIDAgb2JqPDwvSFs1MTYgMTk2XS9MaW5lYXJpemVkIDEvRSA0NjQ1 L0wgMTU2NTYvTiA2L08gMzQvVCAxNDk5ND4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAgICAg IA14cmVmDTMxIDExDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDcxMiAwMDAwMCBuDQowMDAw MDAwNTE2IDAwMDAwIG4NCjAwMDAwMDA3OTIgMDAwMDAgbg0KMDAwMDAwMDkyMyAwMDAwMCBuDQow MDAwMDAxMDMzIDAwMDAwIG4NCjAwMDAwMDE0MTQgMDAwMDAgbg0KMDAwMDAwMTQ0OCAwMDAwMCBu DQowMDAwMDAxNTI0IDAwMDAwIG4NCjAwMDAwMDE4MjYgMDAwMDAgbg0KMDAwMDAwNDQ5NCAwMDAw MCBuDQp0cmFpbGVyDTw8L1NpemUgNDIvUHJldiAxNDk4NS9Sb290IDMyIDAgUi9JbmZvIDMwIDAg Ui9JRFs8MGJlZmQzMGZkMGQ5MTZiOTU2MjQ2OTMxMWZiNTE3ZTA+PDJhN2IwM2U0ZTY4YTExZDg5 MDkzMDAwYTk1NjZhMzUwPl0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAgICAgICAgICAgICAgICAg ICANMzMgMCBvYmo8PC9MZW5ndGggMTE3L0ZpbHRlci9GbGF0ZURlY29kZS9MIDEzMC9TIDg0Pj5z dHJlYW0NCnjaYmBgYGFgYAphYGZgYBZi4GFAAB6gGAsQcjQwMOzfwMB0wILNoWKSJ1DGpM1kmsky k20mxxg4EBCuBqhClIFB8TeQ5gBiXrBpSgw8bAI+okA1C3mWLCiVXDhXauFqqQlgOSkGBq1bQJoJ iK0BAgwAj9sWfg1lbmRzdHJlYW0NZW5kb2JqDTMyIDAgb2JqPDwvUGFnZXMgMjggMCBSL1R5cGUv Q2F0YWxvZy9QYWdlTGFiZWxzIDI2IDAgUi9NZXRhZGF0YSAyOSAwIFI+Pg1lbmRvYmoNMzQgMCBv Ymo8PC9Db250ZW50cyAzOSAwIFIvVHlwZS9QYWdlL1BhcmVudCAyOCAwIFIvUm90YXRlIDI3MC9N ZWRpYUJveFswIDAgNjEyIDc5Ml0vQ3JvcEJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzIDM1IDAg Uj4+DWVuZG9iag0zNSAwIG9iajw8L0NvbG9yU3BhY2U8PC9DczYgMzcgMCBSPj4vRm9udDw8L1RU MiAzNiAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDM4IDAgUj4+Pj4N ZW5kb2JqDTM2IDAgb2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNl Rm9udC9BcmlhbE1UL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjEvU3VidHlwZS9UcnVlVHlwZS9G b250RGVzY3JpcHRvciA0MSAwIFIvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCA1NTYgMCA1NTYgMCA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY3IDAgNzIyIDcy MiAwIDAgMCAwIDI3OCA1MDAgMCA1NTYgODMzIDAgMCAwIDAgMCA2NjcgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCA1NTYgMCA1MDAgNTU2IDU1NiAyNzggNTU2IDAgMjIyIDAgMCAwIDgzMyA1NTYg NTU2IDU1NiAwIDMzMyA1MDAgMjc4IDU1NiAwIDAgMCA1MDBdPj4NZW5kb2JqDTM3IDAgb2JqWy9J Q0NCYXNlZCA0MCAwIFJdDWVuZG9iag0zOCAwIG9iajw8L1R5cGUvRXh0R1N0YXRlL1NBIGZhbHNl L09QIGZhbHNlL1NNIDAuMDIvb3AgZmFsc2UvT1BNIDE+Pg1lbmRvYmoNMzkgMCBvYmo8PC9MZW5n dGggMjM0L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiWSOy07DMBBFv2D+4S7LIu742WYJ DUIgWKBaYl2FpApSY7BTIf4eO5GKVDTWyI+55/iLJAaQdsjLGsZGMWJHbxhpvUsObYKcK7X55mEv cUz/x3t6vTzeeVp7r3LE98SojBa1wtIZWhvBW1hbl7M/XSw8V7GwYM4jvqVq3jr4b1rtu/G9i3hs 0MRDP6Ub/1HoWhbO0hlKW5Fdjosjw0temoJaPQ0nPP+EseQqJTbb2qKSQrGGb5ZB+ec0s/NlaGNI oZ+wC/EzxMM0LAAprNP1dV5f/9ng9nw8pwkqE0vu3tOvAAMAZoZVzw0NZW5kc3RyZWFtDWVuZG9i ag00MCAwIG9iajw8L0xlbmd0aCAyNTc1L0ZpbHRlci9GbGF0ZURlY29kZS9OIDMvQWx0ZXJuYXRl L0RldmljZVJHQj4+c3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJCAES QkjYBUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem0+8f7/c593fv 793fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJAAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8i55e B5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY5 2sQKjVaBsylnnUKjMPFpnFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9n uj4nS4LzAgDIdNU7XPoOG5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOT aRsBmL/znDim2mJ4kYNFocHBQn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttIt AIyvBMDy5luby/sAMPG+Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHK MpmxyoCZ6iavrqo26rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MT f2XYTzQ/17i4Y68Br9gHsC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2a i5Nk5WByo75ufs/0WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSB HrAebALDYDsYA7vBfnAQjIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2Io EoqHUqEsqAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7wb6w GI6BU+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelG BpFRZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbgRQgj SAmLCCpCPaGLMEjYSfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolkRfIi RZDSSTKSgdRF2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAorpQwSjpFQWmk 9FHGKMcoFynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh2u9on9OmaC/oHLon XUIvohvp6+gf0o/Tv6I/YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJYboy Y5hLmU3MQeYh5kXmIxaF5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPO Kc5dLsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwqfh// IP86/6WFnUWMhdJijcV+i8sWzyxtLKMtlZbdlgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreutt1mf sX5kw7MJt5HbdNsctLlpC9t62mbZNtt+YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6R DmqHAYfPHP6KmWMxWBU2hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLik ubS47HW56UpxFbuWu252Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9 vvSEPYM8yz1HPC96wV7BXmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3g e9b3tV+QX5XfmN8tEUeULOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G /SM4JFgfvD/4QYhLSEnIeyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5 YGzB3QinCFnEjojJSCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkm OR6HxCXGdcdNxHPic+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9Ooadk pwynfJPqmapPPZYGpyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi 7D3ZT3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MXb1o8 XRRU1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIVA4oH yghlv/JeWURZf9l9VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0R7UcbaX2 dLV9dUP1JZ2Xrks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V59Yca2A3ahguN no1rGu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2yvY/dfh19Hd8vyJ/ xbFOu87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2rHndrej+osevZ7Dnh1557xdrRWuH1v64 rmzdRF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvODQYObt9M3WzcPDmU+k8ApAFb /pi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRW pMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqx YLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6E vv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXM tc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr7 24DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDq W+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH +lf65/t3/Af8mP0p/br+S/7c/23//wIMAPeE8/sNDWVuZHN0cmVhbQ1lbmRvYmoNNDEgMCBvYmo8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRCQm94Wy0yIC0yMTAgOTMzIDcyOV0vRm9udE5hbWUv QXJpYWxNVC9GbGFncyAzMi9TdGVtViA5NC9DYXBIZWlnaHQgMC9Bc2NlbnQgOTA1L0Rlc2NlbnQg LTIxMS9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTEgMCBvYmo8PC9Db250ZW50cyAzIDAgUi9UeXBl L1BhZ2UvUGFyZW50IDI4IDAgUi9Sb3RhdGUgMjcwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9Dcm9w Qm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXMgMiAwIFI+Pg1lbmRvYmoNMiAwIG9iajw8L0NvbG9y U3BhY2U8PC9DczYgMzcgMCBSPj4vRm9udDw8L1RUNCAyMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dF0vRXh0R1N0YXRlPDwvR1MxIDM4IDAgUj4+Pj4NZW5kb2JqDTMgMCBvYmo8PC9MZW5ndGggMzMw L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiXSQ0UrDMBSGnyDv8F+2QrOk7br2StSJIIiI gV2IFzHL1sjazKZu7DUE39ckkymInHAuzjn/9//kjXAYkKKCf9OSYZYzDJos0JPJlaugHHgsp/zk 5pFj7f6er8jDaXkpyESI0kvEijBkZUGbHMfOUDY5bSqU9YxWNUR3cmGxggujjLEGQnm12JPkfqeH ndH7VLwGXsED6dg9j09pjhnPaaQFLc+DNouYaSA8JZ9pVjY1LZJFmnGaJ62F2kjTOYwWrdxpmH4c 7PJd6SVk+ixuPakufdBwzgqIOUk67Zxcx1OLsdXQWSfNBlpZd3Cj7s5DwuxHWBYVD8pf/vPU76vE au/cyhFbPTjbfzgsrWf1kErp7fhPgEG7re2deTEbMx6wskOMcScusBpsh31rVBtGIYc4+/6CKn5i TKpkp2PIa0G+BBgAajyEJg0NZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqPDwvVHlwZS9Gb250RGVz Y3JpcHRvci9Gb250QkJveFstMiAtMjEwIDkzMyA3MjldL0ZvbnROYW1lL0FyaWFsTVQvRmxhZ3Mg MzIvU3RlbVYgODgvQ2FwSGVpZ2h0IDcxNC9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMS9JdGFsaWNB bmdsZSAwPj4NZW5kb2JqDTUgMCBvYmo8PC9Db250ZW50cyA3IDAgUi9UeXBlL1BhZ2UvUGFyZW50 IDI4IDAgUi9Sb3RhdGUgMjcwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9Dcm9wQm94WzAgMCA2MTIg NzkyXS9SZXNvdXJjZXMgNiAwIFI+Pg1lbmRvYmoNNiAwIG9iajw8L0NvbG9yU3BhY2U8PC9DczYg MzcgMCBSPj4vRm9udDw8L1RUNiAyMiAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRl PDwvR1MxIDM4IDAgUj4+Pj4NZW5kb2JqDTcgMCBvYmo8PC9MZW5ndGggMzc0L0ZpbHRlci9GbGF0 ZURlY29kZT4+c3RyZWFtDQpIiYxRSU7DMBQ9ge/wlzYirmM7U3dlKBIraC11gViUxGmDmqTYRZyA I8B5seO0qGKD/PVl2W/4wxuKoQEkUnCRSAYZZ2A0WkGHJtc2hdJCPBxbupe7ZQwb+xdeo8fT55VC E6VSR1E1YhBJQQsOITOQBaeF44qM5hJUe3Jhw/EujDLGclAlivw15qA+EF5teyh366a18EnUq1cW sdcM2SnHCeWQxZzmXvdIHVVY4lWe8BeJZJFTgefEvQvcdBW02tr1RsNWryttLqFujD1AX0/Js7r3 RjynrqCQGYhs6CXN0uAUqky8FQsm3yTiMqc5XhBGU6yt7g7RUndO/SgZUymSAtTNSJeefmJmAzMb mXPTtwNPXYzo9Axd4CXxvfwaOCCjXGZixM0JlwU2xKM57klgtcdizgfJ2bCbf09ShUluGwsuHhaz KTy8m31vDrqChbb7vrPNy04HNyft9u/650z49oeR4VlVGbcFv9hbhX4EGABh4p2tDQ1lbmRzdHJl YW0NZW5kb2JqDTggMCBvYmo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRCQm94Wy0yIC0yMTAg OTMzIDcyOV0vRm9udE5hbWUvQXJpYWxNVC9GbGFncyAzMi9TdGVtViA4OC9DYXBIZWlnaHQgNzE0 L0FzY2VudCA5MDUvRGVzY2VudCAtMjExL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNOSAwIG9iajw8 L0NvbnRlbnRzIDExIDAgUi9UeXBlL1BhZ2UvUGFyZW50IDI4IDAgUi9Sb3RhdGUgMjcwL01lZGlh Qm94WzAgMCA2MTIgNzkyXS9Dcm9wQm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXMgMTAgMCBSPj4N ZW5kb2JqDTEwIDAgb2JqPDwvQ29sb3JTcGFjZTw8L0NzNiAzNyAwIFI+Pi9Gb250PDwvVFQ4IDIz IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzEgMzggMCBSPj4+Pg1lbmRv YmoNMTEgMCBvYmo8PC9MZW5ndGggMzY5L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiWSQ 30rDMBTGnyDvcC5bsFnSpm16JdOqICi6BRTEiy7NbNS2s6n4594XEHxfk7ZuwkgI4eR83/nle0EU NKAoAbtjRiANCXQK3UCDZscmAWmADstIWzlbUngw++1rdL19PBJoJgS3ErFGBAJGMOEwngRiyjGD mEc4C0HU2yFkWG5IYDsJtWqJ3I0kIN6Ql7fKQN7WhW5gLqXa9L54tA1JxhIIKKZZahvzUW0nTepo EC+U2bSN0Sv9rPsP+DoctBBE1FGMJwFGYxxCSkPMHdmAETmjYMdx5/34Acs4Dr1T39ZDr2truFrM D0C9910heyhHyKaoFfbvxbkbRDGLEur49g10U0JfFX/Cb+MHMeYeiFtho5VtV4K1yy+X/92snXMb GBPHOPmmOPMWo+8oLZWRnV7Z8N4qLSu4EHMDRadGL8xZNsQXuqQmv3D353iIr3jtq7bTn8qCtmA2 qniCddtZajVBYxfoiUC/AgwANHKVJg0NZW5kc3RyZWFtDWVuZG9iag0xMiAwIG9iajw8L1R5cGUv Rm9udERlc2NyaXB0b3IvRm9udEJCb3hbLTIgLTIxMCA5MzMgNzI5XS9Gb250TmFtZS9BcmlhbE1U L0ZsYWdzIDMyL1N0ZW1WIDg4L0NhcEhlaWdodCA3MTQvWEhlaWdodCA1MTkvQXNjZW50IDkwNS9E ZXNjZW50IC0yMTEvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0xMyAwIG9iajw8L0NvbnRlbnRzIDE1 IDAgUi9UeXBlL1BhZ2UvUGFyZW50IDI4IDAgUi9Sb3RhdGUgMjcwL01lZGlhQm94WzAgMCA2MTIg NzkyXS9Dcm9wQm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXMgMTQgMCBSPj4NZW5kb2JqDTE0IDAg b2JqPDwvQ29sb3JTcGFjZTw8L0NzNiAzNyAwIFI+Pi9Gb250PDwvVFQxMCAyNCAwIFI+Pi9Qcm9j U2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDM4IDAgUj4+Pj4NZW5kb2JqDTE1IDAgb2Jq PDwvTGVuZ3RoIDQxMS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImcksFu1DAQQL/A/zDH RKrdseMk3iN0KyQkUGEtcah6SLPOYrSJF8dtEf8B34vtwLaFclk5GllO5s08Z74SDhZI1UB8aonQ CgRvyCeYyPnF3EA/A89r7uPJmw2H3fzv5wP5cHz5WpNzrTnGHD0QBCorthKwRAS5EmwVkyvJhAQ9 HstgXqkMMkRsQfeE5m0N+oEUF3femynA2ndDmEv9JbErnqhLjGxeMwEtF0wlckrmCYMJcF38KKlc KVYX2zKCZZFA1Jow0LHzdkt75w1FUd7ot4ktFEMFS0So2izQtM0Cz61xmfG/+001fpZUSMXaYl1i jGbuvb01M1x9fAXdfue8DZ/HM3D3xt9b8/Cn1nOPKhZVp3scvAuud3uK+LKLUC2rT3cZnB+7AN20 hdF0k5124AZYv9/EUYh3uGUvWwkpmDzdar67HW0Ixv/3FwnkLM7lX1rVUUs+02qylnrUcodg3dTt YfNOX4H5Fsw0x4Oku9RjCisJlDOBdex8/eSyioPx+Vqm3mTQaL93CZfm9FKTXwIMAHSi2zsNDWVu ZHN0cmVhbQ1lbmRvYmoNMTYgMCBvYmo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRCQm94Wy0y IC0yMTAgOTMzIDcyOV0vRm9udE5hbWUvQXJpYWxNVC9GbGFncyAzMi9TdGVtViA4OC9DYXBIZWln aHQgNzE0L1hIZWlnaHQgNTE5L0FzY2VudCA5MDUvRGVzY2VudCAtMjExL0l0YWxpY0FuZ2xlIDA+ Pg1lbmRvYmoNMTcgMCBvYmo8PC9Db250ZW50cyAxOSAwIFIvVHlwZS9QYWdlL1BhcmVudCAyOCAw IFIvUm90YXRlIDI3MC9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQ3JvcEJveFswIDAgNjEyIDc5Ml0v UmVzb3VyY2VzIDE4IDAgUj4+DWVuZG9iag0xOCAwIG9iajw8L0NvbG9yU3BhY2U8PC9DczYgMzcg MCBSPj4vRm9udDw8L1RUMTIgMjUgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8 L0dTMSAzOCAwIFI+Pj4+DWVuZG9iag0xOSAwIG9iajw8L0xlbmd0aCA0NDUvRmlsdGVyL0ZsYXRl RGVjb2RlPj5zdHJlYW0NCkiJjJLRjpUwEIafgHeYSzBpty1QwDvdVRPjJuueJppsvKhQDpgD1bbu Pok+r1OaPUePyWYD6QXMfPPNDz8yDjNkpQS864pBIxg4k32CNbu49BJ6D3y7fI9P3u047P3/5WP2 8fjytcoulOICe9SYMSBVSTsB6WRQdYJ2EqTgFGvUchzDtiuOYZQx1oLqsVs9ZPng9BjIbMJIFu3m gfTWGcJEob5FfskjOZ3I5zUV0HBB20iPLF5F1l3+qyBV11KeXxaE0Sqf9Lo3/mXxRb2PHNFSnJpO BmWzCctGJhA5kTa/Oqrd5b8LIqqWNvltwfA0i73XB7AjfL7+gMmg6QCjdYsO9HEOp1VZd6CuTu1y a2/zv+sBUWaAYOG7s8H29kAYSxD14qnJq1190OugETUZPRjnYXR2gZvbV8mBtqysogjvpIwiKWd9 2Fs3h2mhMVlyKnv03RaX/ywu86tkPs6rga9m0vezdXEFWPQhbmJOFvN6Nl+wmkdwCrfbLNASnmfS nH2CHZrUuQkxBGf8z0PwGMYDioR+Mh52N2+P+W2A8myV6wIjyecV5c0wB1TARPv0m6TONyr7I8AA Jw/TZQ0NZW5kc3RyZWFtDWVuZG9iag0yMCAwIG9iajw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9u dEJCb3hbLTIgLTIxMCA5MzMgNzI5XS9Gb250TmFtZS9BcmlhbE1UL0ZsYWdzIDMyL1N0ZW1WIDg4 L0NhcEhlaWdodCAwL0FzY2VudCA5MDUvRGVzY2VudCAtMjExL0l0YWxpY0FuZ2xlIDA+Pg1lbmRv YmoNMjEgMCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250 L0FyaWFsTVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDE0OS9TdWJ0eXBlL1RydWVUeXBlL0ZvbnRE ZXNjcmlwdG9yIDQgMCBSL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgMCA2NjcgMCAwIDcyMiAwIDAgMCAw IDAgMCAwIDAgODMzIDAgNzc4IDAgMCAwIDAgNjExIDAgMCA5NDQgMCAwIDAgMCAwIDAgMCAwIDAg NTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMCAwIDIyMiA4MzMgNTU2IDU1NiA1 NTYgMCAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyMjIgMCAwIDM1MF0+Pg1lbmRvYmoNMjIgMCBvYmo8 PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L0FyaWFsTVQvRmly c3RDaGFyIDMyL0xhc3RDaGFyIDE1MC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDgg MCBSL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI3OCAzMzMgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMjc4IDAgMCAwIDAgMCAwIDY2NyAwIDAgMCAwIDYxMSAwIDAgMCAwIDAgMCAw IDAgMCA2NjcgMCA3MjIgNjY3IDYxMSAwIDAgOTQ0IDAgMCAwIDAgMCAwIDAgMCAwIDU1NiA1NTYg NTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDAgMCAyMjIgODMzIDU1NiA1NTYgNTU2IDAgMzMz IDUwMCAyNzggNTU2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDEwMDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMzUwIDU1Nl0+Pg1lbmRvYmoNMjMgMCBvYmo8PC9UeXBlL0Zv bnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L0FyaWFsTVQvRmlyc3RDaGFyIDMy L0xhc3RDaGFyIDE0OS9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDEyIDAgUi9XaWR0 aHNbMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNzggMCAyNzggMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCA1NTYgMCA2NjcgMCAwIDcyMiAwIDYxMSAwIDAgMCAwIDAgMCA4MzMgNzIy IDAgNjY3IDAgNzIyIDY2NyA2MTEgMCAwIDAgNjY3IDAgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDUw MCA1NTYgNTU2IDI3OCAwIDU1NiAyMjIgMCA1MDAgMjIyIDgzMyA1NTYgNTU2IDU1NiAwIDMzMyA1 MDAgMjc4IDU1NiAwIDcyMiA1MDAgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDEwMDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMjIyIDAgMCAzNTBdPj4NZW5kb2JqDTI0IDAgb2JqPDwvVHlw ZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNlRm9udC9BcmlhbE1UL0ZpcnN0Q2hh ciAzMi9MYXN0Q2hhciAxNTAvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAxNiAwIFIv V2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4IDMzMyAyNzggMCA1NTYgMCA1NTYg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDY2NyAwIDcyMiA3MjIgMCAwIDAgMCAwIDAgMCAw IDgzMyA3MjIgMCA2NjcgMCA3MjIgNjY3IDYxMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYg NTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIyMiAwIDAgMjIyIDgzMyA1NTYgNTU2IDU1NiAw IDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzUwIDU1Nl0+Pg1lbmRvYmoNMjUgMCBvYmo8 PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L0FyaWFsTVQvRmly c3RDaGFyIDMyL0xhc3RDaGFyIDE1MC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDIw IDAgUi9XaWR0aHNbMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDMzMyAyNzggMCA1NTYgMCA1 NTYgMCAwIDAgMCAwIDAgMCAyNzggMCAwIDAgMCAwIDAgNjY3IDAgNzIyIDcyMiAwIDYxMSAwIDAg MCAwIDAgNTU2IDgzMyAwIDAgNjY3IDAgNzIyIDY2NyAwIDAgMCAwIDY2NyAwIDAgMCAwIDAgMCAw IDAgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMCAwIDIyMiA4MzMgNTU2IDU1 NiA1NTYgMCAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzUwIDU1Nl0+Pg1lbmRvYmoNMjYgMCBv Ymo8PC9OdW1zWzAgMjcgMCBSXT4+DWVuZG9iag0yNyAwIG9iajw8L1MvRD4+DWVuZG9iag0yOCAw IG9iajw8L0NvdW50IDYvS2lkc1szNCAwIFIgMSAwIFIgNSAwIFIgOSAwIFIgMTMgMCBSIDE3IDAg Ul0vVHlwZS9QYWdlcz4+DWVuZG9iag0yOSAwIG9iajw8L0xlbmd0aCAzMzU1L1R5cGUvTWV0YWRh dGEvU3VidHlwZS9YTUw+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBD ZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4NCjx4 OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIu OS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4NCjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53 My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9i ZS5jb20vaVgvMS4wLyc+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDoyYTgwMDVh Yy1lNjhhLTExZDgtOTA5My0wMDBhOTU2NmEzNTAnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2Jl LmNvbS9wZGYvMS4zLycgcGRmOlByb2R1Y2VyPSdBY3JvYmF0IERpc3RpbGxlciA2LjAuMSBmb3Ig TWFjaW50b3NoJz48L3JkZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSd1dWlkOjJhODAwNWFjLWU2OGEtMTFkOC05MDkzLTAwMGE5NTY2YTM1MCcgeG1sbnM6eGFwPSdo dHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRvclRvb2w9J1Bvd2VyUG9pbnQ6 IGNncGRmdG9wcyBDVVBTIGZpbHRlcicgeGFwOkNyZWF0ZURhdGU9JzIwMDQtMDgtMDRUMTk6NTA6 MDYtMDc6MDAnIHhhcDpNb2RpZnlEYXRlPScyMDA0LTA4LTA0VDE5OjUwOjA2LTA3OjAwJz48L3Jk ZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjJhODAwNWFj LWU2OGEtMTFkOC05MDkzLTAwMGE5NTY2YTM1MCcgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6MmE3ZmUzNGEtZTY4YS0x MWQ4LTkwOTMtMDAwYTk1NjZhMzUwJy8+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVp ZDoyYTgwMDVhYy1lNjhhLTExZDgtOTA5My0wMDBhOTU2NmEzNTAnIHhtbG5zOmRjPSdodHRwOi8v cHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Zm9ybWF0PSdhcHBsaWNhdGlvbi9wZGYnPjxk Yzp0aXRsZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPlNlbmRlcklkMDQw ODA0LnBwdCBbUmVhZC1Pbmx5XTwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpjcmVh dG9yPjxyZGY6U2VxPjxyZGY6bGk+QW5kcmV3IFcuIERvbm9obzwvcmRmOmxpPjwvcmRmOlNlcT48 L2RjOmNyZWF0b3I+PC9yZGY6RGVzY3JpcHRpb24+DQo8L3JkZjpSREY+DQo8L3g6eG1wbWV0YT4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94 cGFja2V0IGVuZD0ndyc/Pg1lbmRzdHJlYW0NZW5kb2JqDTMwIDAgb2JqPDwvTW9kRGF0ZShEOjIw MDQwODA0MTk1MDA2LTA3JzAwJykvQ3JlYXRpb25EYXRlKEQ6MjAwNDA4MDQxOTUwMDYtMDcnMDAn KS9UaXRsZShTZW5kZXJJZDA0MDgwNC5wcHQgW1JlYWQtT25seV0pL0NyZWF0b3IoUG93ZXJQb2lu dDogY2dwZGZ0b3BzIENVUFMgZmlsdGVyKS9Qcm9kdWNlcihBY3JvYmF0IERpc3RpbGxlciA2LjAu MSBmb3IgTWFjaW50b3NoKS9BdXRob3IoQW5kcmV3IFcuIERvbm9obyk+Pg1lbmRvYmoNeHJlZg0w IDMxDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwNDY0NSAwMDAwMCBuDQowMDAwMDA0NzczIDAw MDAwIG4NCjAwMDAwMDQ4ODIgMDAwMDAgbg0KMDAwMDAwNTI3OSAwMDAwMCBuDQowMDAwMDA1NDMx IDAwMDAwIG4NCjAwMDAwMDU1NTkgMDAwMDAgbg0KMDAwMDAwNTY2OCAwMDAwMCBuDQowMDAwMDA2 MTA5IDAwMDAwIG4NCjAwMDAwMDYyNjEgMDAwMDAgbg0KMDAwMDAwNjM5MSAwMDAwMCBuDQowMDAw MDA2NTAxIDAwMDAwIG4NCjAwMDAwMDY5MzggMDAwMDAgbg0KMDAwMDAwNzEwMyAwMDAwMCBuDQow MDAwMDA3MjM0IDAwMDAwIG4NCjAwMDAwMDczNDUgMDAwMDAgbg0KMDAwMDAwNzgyNCAwMDAwMCBu DQowMDAwMDA3OTg5IDAwMDAwIG4NCjAwMDAwMDgxMjAgMDAwMDAgbg0KMDAwMDAwODIzMSAwMDAw MCBuDQowMDAwMDA4NzQ0IDAwMDAwIG4NCjAwMDAwMDg4OTUgMDAwMDAgbg0KMDAwMDAwOTMzOSAw MDAwMCBuDQowMDAwMDA5Nzg2IDAwMDAwIG4NCjAwMDAwMTAyNDYgMDAwMDAgbg0KMDAwMDAxMDcw NyAwMDAwMCBuDQowMDAwMDExMTY2IDAwMDAwIG4NCjAwMDAwMTEyMDEgMDAwMDAgbg0KMDAwMDAx MTIyNSAwMDAwMCBuDQowMDAwMDExMzA5IDAwMDAwIG4NCjAwMDAwMTQ3NDAgMDAwMDAgbg0KdHJh aWxlcg08PC9TaXplIDMxPj4Nc3RhcnR4cmVmDTExNg0lJUVPRg0= --Apple-Mail-2--449410312 Content-Type: multipart/alternative; boundary=Apple-Mail-3--449410311 --Apple-Mail-3--449410311 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit PDF may not be open enough but you should be able to see them anyway. Andrew ____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-3--449410311 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit PDF may not be open enough but you should be able to see them anyway. Andrew Helvetica____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-3--449410311-- --Apple-Mail-2--449410312-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 00:15: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 AAA05858 for ; Thu, 5 Aug 2004 00:15: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 i7543tSE052601; Wed, 4 Aug 2004 21: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 i7543tNs052600; Wed, 4 Aug 2004 21:03:55 -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 i7543r1B052594 for ; Wed, 4 Aug 2004 21:03:54 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040805040358.EULN6357.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 5 Aug 2004 00:03:58 -0400 From: "John Glube" To: "'IETF MARID WG'" Cc: Subject: So ... did Dewey beat Truman? Date: Thu, 5 Aug 2004 00:05:52 -0400 Message-ID: <001301c47aa1$80113070$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20040804152733.DF6F966A@dumbo.pobox.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7543s1B052595 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Oh yes, the famous headline of the Chicago Tribune when Dewey was supposed to have beaten President Truman in the 1948 Presidential election. Why that subject line? Because of this article: IETF Prepares to Forward Sender-ID http://www.internetnews.com/xSP/article.php/3390221 The implication from the article, as a result of the author interviewing Andy Newton, one of the co-chairs of this WG was that Sender-ID had won and CSV had lost. The only thing holding things up? According to the article, a fight going on within MS whether to insist on a license for Sender-ID or not. However it seems based on quick notes released by the WG chairs, the issue remains open. Why do I say this? * The core draft protocol (aka Sender-ID) will now be divided into two documents, core and PRA. * In the meantime, MS has been given until August 23 (the same date when last call starts) to file any IPR claims. * The group can start discussing CSV. And what about CSV? It might be helpful if Andy could clarify whether the interview in the noted article is accurate, or did the reporter mangle his remarks and draw the wrong conclusions. Why? Because the article leaves the impression the issue has already been decided. Instead, with the split of Marid core into two documents, core and PRA, the community could enjoy the benefit of doing: * PRA checks meaning both SENDER FROM and FROM checks as per PRA. * SENDER FROM, MAIL FROM or EHELO checks all as per core. (I appreciate some may balk at this, but bear with me.) With the Marid protocol (SPF) being the design used for senders to publish DNS records, this allows people to build a receiving authentication model around any one of these four options depending on their needs, without prejudicing senders. The benefits: * It leaves MS free to claim a defensive patent on PRA and require a license should it so decide. If MS decides to proceed in this direction, those developers who are happy to sign a license can do so. Those receivers who want to do full blown PRA checks can do so. * It allows the open source community free to develop and implement an authentication model around SENDER FROM, MAIL FROM and/or EHELO FROM. Those receivers who would prefer to focus on the transportation stage for authentication can do so. * This approach does not prejudice senders since the record published using Marid protocol (SPF) can be used to support any authentication chosen by the receiver. * It allows the market to decide which approach to use based on performance. * It allows testing to proceed. * It does not prevent ISPs and business networks from saying in essence, don't want your mail to be automatically rejected, then by such and such a date you must have published an SPF record or else we will automatically reject. As to whether it is delivered or not, depends on our policies. * For marketing purposes call the whole thing Sender-ID to expedite implementation (presuming this name is available and not encumbered). One thing. I am not trying to rehash old ground, or usurp what was discussed and agreed upon at the WG meeting. If the approach suggested is foreclosed by what was discussed and agreed upon, so be it. 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.729 / Virus Database: 484 - Release Date: 27/07/2004 From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 02:51: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 CAA28301 for ; Thu, 5 Aug 2004 02:51: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 i756ae3i098533; Wed, 4 Aug 2004 23: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 i756aeEr098530; Wed, 4 Aug 2004 23:36:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i756aaC1098474 for ; Wed, 4 Aug 2004 23:36:37 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bsbrb-0004cd-00 for ; Thu, 05 Aug 2004 08:36:31 +0200 Received: from 212.82.251.170 ([212.82.251.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 08:36:31 +0200 Received: from nobody by 212.82.251.170 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 08:36:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Slide decks from MARID meetings...As PDF Date: Thu, 05 Aug 2004 08:35:53 +0200 Organization: Lines: 14 Message-ID: <4111D549.67CC@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.170 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 Andrew W. Donoho wrote: > PDF may not be open enough but you should be able to see them > anyway. Unfortunately that's not the case on my system (the AcroReader is only version 3 => no colour support => a black rectangle on a white background... ;-) and there's no better version. But thanks for trying, maybe Google grabs your links here and converts it to some kind of plain text. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 03:23: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 DAA00032 for ; Thu, 5 Aug 2004 03:23: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 i757EJFk011175; Thu, 5 Aug 2004 00:14: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 i757EJZD011174; Thu, 5 Aug 2004 00:14:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i757EJjK011165 for ; Thu, 5 Aug 2004 00:14:19 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id ED79994042; Thu, 5 Aug 2004 09:14:18 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id CA48B9403C; Thu, 5 Aug 2004 09:14:17 +0200 (CEST) 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 i757EHjI1213482; Thu, 5 Aug 2004 09:14:17 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id A74C3102C1; Thu, 5 Aug 2004 09:14:17 +0200 (CEST) Date: Thu, 5 Aug 2004 09:14:17 +0200 From: Stephane Bortzmeyer To: Marshall Rose Cc: IETF MARID WG , Andrew Newton Subject: Re: short-term milestones Message-ID: <20040805071417.GB24130@nic.fr> References: <23FC8EBA-E678-11D8-8A0D-000A95CA7FAE@dbc.mtview.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23FC8EBA-E678-11D8-8A0D-000A95CA7FAE@dbc.mtview.ca.us> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 04, 2004 at 05:41:08PM -0700, Marshall Rose wrote a message of 25 lines which said: > 3. final ipr statements are due monday, august 23rd. There already was a deadline on August 2nd. It was not respected. Why this one would be better? From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 03:26: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 DAA00146 for ; Thu, 5 Aug 2004 03:26: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 i757F196011380; Thu, 5 Aug 2004 00:15:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i757F1e1011379; Thu, 5 Aug 2004 00:15:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i757ExRT011328 for ; Thu, 5 Aug 2004 00:15:00 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i757EpaJ026341 for ; Thu, 5 Aug 2004 08:14:51 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i757Ep8W026340; Thu, 5 Aug 2004 08:14:51 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Interaction with anti-spam systems References: <20040804185931.60B3617109@mail.nitros9.org> From: Graham Murray Date: Thu, 05 Aug 2004 08:14:51 +0100 In-Reply-To: <20040804185931.60B3617109@mail.nitros9.org> (Alan DeKok's message of "Wed, 04 Aug 2004 14:59:31 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Alan DeKok" writes: > e.g. I've talked to people who say that 90% of the SPF records they > see are from spammers. That is certainly not what I am seeing here. Granted it is only a small sample (as I do not keep spam for long) and as I use SPF on the MTA I do not see SPF Fail (as they are refused). In my spam folder at the moment, I have SPF Pass 0 SPF None 203 SPF Neutral 5 SPF Soft-Fail 6 SPF Unknown 4 From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 03:26: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 DAA00166 for ; Thu, 5 Aug 2004 03:26: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 i757BpRn010339; Thu, 5 Aug 2004 00:11: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 i757BpGL010338; Thu, 5 Aug 2004 00:11:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i757Boq5010328 for ; Thu, 5 Aug 2004 00:11:51 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 9A87F9404B; Thu, 5 Aug 2004 09:11:50 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id AC92A94048; Thu, 5 Aug 2004 09:11:43 +0200 (CEST) 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 i757BhjI1209700; Thu, 5 Aug 2004 09:11:43 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 5D68C102C1; Thu, 5 Aug 2004 09:11:43 +0200 (CEST) Date: Thu, 5 Aug 2004 09:11:43 +0200 From: Stephane Bortzmeyer To: Marshall Rose Cc: Michel Bouissou , IETF MARID WG Subject: Re: Slide decks from MARID meetings Message-ID: <20040805071143.GA24130@nic.fr> References: <200408050143.10924@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.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 04, 2004 at 05:45:03PM -0700, Marshall Rose wrote a message of 18 lines which said: > michel - the ietf accepts submissions in ppt format for meetings. What other formats are accepted? Can I use DVI? From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 04:29: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 EAA03469 for ; Thu, 5 Aug 2004 04:29: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 i758Gg2R032069; Thu, 5 Aug 2004 01:16: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 i758GgVZ032068; Thu, 5 Aug 2004 01:16:42 -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 i758GfLi032056 for ; Thu, 5 Aug 2004 01:16:42 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id E0D3E28290 for ; Thu, 5 Aug 2004 10:16:41 +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 29997-03 for ; Thu, 5 Aug 2004 10:16:27 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 7182128292; Thu, 5 Aug 2004 10:16:27 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Slide decks from MARID meetings...As PDF Date: Thu, 5 Aug 2004 10:16:27 +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: <200408051016.27074@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 jeudi 5 Août 2004 04:53, Andrew W. Donoho a écrit : > PDF may not be open enough but you should be able to see them anyway. Thank you very much. It will be allright. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 04:53:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04792 for ; Thu, 5 Aug 2004 04:53:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i758fqwr041008; Thu, 5 Aug 2004 01:41: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 i758fqjX041006; Thu, 5 Aug 2004 01:41:52 -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 i758foWw040989 for ; Thu, 5 Aug 2004 01:41:51 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bsdos-0006ws-00 for ; Thu, 05 Aug 2004 10:41:50 +0200 Received: from 212.82.251.170 ([212.82.251.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 10:41:50 +0200 Received: from nobody by 212.82.251.170 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 10:41:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF/FROM-HDR Date: Thu, 05 Aug 2004 10:31:59 +0200 Organization: Lines: 131 Message-ID: <4111F07F.5049@xyzzy.claranet.de> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us> <3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> <4110E7CC.5796@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.170 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > This I-D is part of the "Unified-SPF" group of I-Ds that > Meng et al talked about publishing several weeks back. For some obscure reasons I always thought that "unified SPF" is the same as "MARID SPF" (protocol-00 and core-02). I don't count "submitter" because anything allowing bounces to a third party is IMHO a perversion of classic SPF resp. RMX. > I didn't hear about the decision to delay until after I had > already submitted the Unified-SPF/From: draft. No problem with that as long as I'm not supposed to grep the I-D list to find new SPF / MARID drafts. > in fact, work has already progressed on the idea of checking > only the From: header and whitelisting exceptions. 2822 From: headers are not necessarily related to the original RMX / SPF problem, i.e. useless bounces caused by billions of forged MAIL FROM addresses. Classic SPF will solve my problem, and I'm very reluctant to consider "better" solutions breaking legacy software. > I think that Meng, Mark and I are all of the opinion that > existing SPF records can be used with the various Unified-SPF > checks. From my POV that's not the case, one of my mail providers has not implemented the "MSA MAY" RfC 2476 8.1. Sender-Id changes this implicitly to a SHOULD or even a MUST. But maybe I can convince you that the recipient could simply pretend that this not yet existing MUST has been done ("default Sender:"), it's less trouble than different spf1 vs. marid1 sender policies. > what Mark meant by it is that it doesn't change things like > RFC2822 or RFC2821. Okay, but for Sender-id there's a problem with RfC 2476 8.1 > the Unified-SPF/From: I-D requires you to whitelist mailing > lists that you have subscribed to. Then it's probably a solution only relevant for MUAs, the MX of a big ISP can't whitelist mailing lists for all users. (?) >> IP not okay for xyzzy: SPF classic SPF/FROM-HDR >> MAIL FROM: UNKNOWN (UNKNOWN in step 3) >> 2822 From: don't care FAIL (step 5) [...] > I'm not sure what exactly the problem with this is. That's the RfC 2476 8.1 "MAY", or rather its "maybe not". My MUA prepares all outbound messages with From: nobody@xyzzy Later I send it with via one of two smart hosts, that's either MAIL FROM: or MAIL FROM:. There is no matching Sender:, and it's "maybe not" inserted. If you ask why I use msa.test: Sometimes (depending on costs and the time of the day, or if the primary MSA is blocked by a recipient) I cannot use "my" primary MSA, and then I use the secondary MSA (msa.test). And the secondary MSA isn't interested in Sender-Id / RfC 2476 8.1, it "only" insists on a correct MAIL FROM: > If I understand things correctly, someone used MSA.test to > submit a message claiming to be from valid@xyzzy, but xyzzy > doesn't say that MSA.test is an ok source for such email. That's it. xyzzy is only a vanity host with a wildcard sender policy, and my primary ISP has no reason to change this, after all I can use its MSA as long as I'm online with this ISP. If I use another dialin ISP then that's my problem. OTOH the 2nd MSA also has no compelling reason to implement RfC 2476 8.1: I could add a matching Sender: manually (for Sender-Id). But for SPF/FROM-HDR even a manually added Sender: won't work. Okay, I could still modify From: into ReplyTo:, and then add a new matching From: manually, but that's a very clumsy solution. > you would need to do both Unified-SPF/MAILFROM and either > Unified-SPF/PRA or Unified-SPF/From:. This _and_ is very important. Maybe we should mention it in SPF/PRA resp. SPF/FROM, these tests make no sense without a prior SPF/MAILFROM test. The important thing is SPF/MAILFROM, and at the moment we have no draft for SPF/MAILFROM (= the old draft-mengwong-spf-01.txt minus all stuff now covered by MARID protocol-00.txt). >> What's the purpose of step 2 spf_test(To:,IP) ? > Whitelisting the To: address is something that SpamAssassin > does. It allows many emails sent through mail forwarders to > be whitelisted. So far that's clear. > If I send email to , and it gets passed > onto address associated with forwarder.tld. That's also clear. > Since user@isp.tld has been involved with the creation and > running of this forwarding relationship, they can easily > whitelist it. ACK, now I got it, To: user@forwarder.tld and the forwarding IP should be matched by the sender policy of forwarder.tld, and that's something the MUA of user@isp.tld knows. But again a case which won't work at the MX of isp.tld for big ISPs. > people really want to also protect the From: header. More than 1000 useless bounces to "my" catch-all vanity domain per day are a much more pressing problem for me. > I strongly suspect that Unified-SPF/From: can be made to > have a much lower error rate than PRA if there is a good > interface to the whitelisting in the MUA. Maybe. But things are really confusing if the recipient either tests this or tests that, and I as sender don't know how my sender policy is interpreted today. I'd prefer a KISS solution where sender policies only for SPF/MAILFROM are possible. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 05:26: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 FAA06573 for ; Thu, 5 Aug 2004 05:26: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 i7595gxF049106; Thu, 5 Aug 2004 02:05: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 i7595g45049105; Thu, 5 Aug 2004 02:05:42 -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 i7595fvB049092 for ; Thu, 5 Aug 2004 02:05:41 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BseBx-0007Ri-00 for ; Thu, 05 Aug 2004 11:05:41 +0200 Received: from 212.82.251.170 ([212.82.251.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 11:05:41 +0200 Received: from nobody by 212.82.251.170 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Aug 2004 11:05:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF/FROM-HDR Date: Thu, 05 Aug 2004 11:04:18 +0200 Organization: Lines: 26 Message-ID: <4111F812.2B05@xyzzy.claranet.de> References: <000001c47a44$c77a1c90$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.170 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 John Glube wrote: > With the realization we continued to have an IPR and > licensing issue with the existing Sender-ID draft, Wayne > suggested a substitution. Yes, that point was clear. But as I said on the SPF list some days ago, IANAL and more interested in technical details. All drafts based on SPF protocol-00 test "something" against a IP and a sender policy in a certain more or less obvious order. I don't see how anybody could patent the order of these tests. The semantics of Sender; / From: / Return-Path: is "prior art", and even the people who invented the internet can't claim that this is new. > Last night I raised the Unified theory as a work around to > many of these problems. Okay. Then we'd still need a separate SPF/MAILFROM text for the classic SPF test, and some technical corrections in SPF protocol-00 (ABNF-issues, typos, RfC 3849 for IPv6 examples). Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 06:59: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 GAA10318 for ; Thu, 5 Aug 2004 06:59: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 i75AUBMW079786; Thu, 5 Aug 2004 03:30: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 i75AUBH1079785; Thu, 5 Aug 2004 03:30:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75AU9R5079768 for ; Thu, 5 Aug 2004 03:30:10 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id D3B9828290; Thu, 5 Aug 2004 12:30: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 29191-02; Thu, 5 Aug 2004 12:29:57 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 31F8028292; Thu, 5 Aug 2004 12:29:57 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Interaction with anti-spam systems Date: Thu, 5 Aug 2004 12:29:56 +0200 User-Agent: KMail/1.6.1 References: <20040804185931.60B3617109@mail.nitros9.org> In-Reply-To: Cc: spf-discuss@v2.listbox.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200408051229.56710@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 jeudi 5 Août 2004 09:14, Graham Murray a écrit : > "Alan DeKok" writes: > >   e.g. I've talked to people who say that 90% of the SPF records they > > see are from spammers. > > That is certainly not what I am seeing here. To advance the discussion with some real-life example, you will find below the list of domains for which my (relatively low-traffic) personal server has received a "MAIL FROM:" in the last days (for any kind of messages, either legitimate or spam or forged), and that DO have an SPF record. Some of these domains are known spamming domains. Others obviously look like spammer throwaway domains. But many are also perfectly legitimate domains. The funny thing is that I've seen many "obvious spams from spamming domains" being rejected with an SPF FAIL. Which means that spammers have set-up SPF records that do not correspond to the machines from which they send or forward. Thus they are shooting themselves in the foot ;-) I've noticed that *many* times, I saw rejections of "SPF failing spam-domains" come by batches of 3 or 4, in the same minute or so. In such cases, most of these actually show the same SPF record. The SPF record thay usually shows for these is: yesanother.com text "v=spf1 ip4:216.65.64.1/24 ip4:216.65.3.1/24 a:send1.surgeweb.com mx -all" An example of such a "batch of 3 or 4" is: Aug 4 19:41:44 reject: RCPT from unknown[80.253.1.54]: 550 : Sender address rejected: Violation SPF: [...] from= helo= Aug 4 19:41:58 reject: RCPT from intelsat.ru[80.253.1.52]: 550 : Sender address rejected: Violation SPF: [...] from= helo= Aug 4 19:42:43 reject: RCPT from atlas.aquitaine.iufm.fr[195.220.161.3]: 550 : Sender address rejected: Violation SPF: [...] from= helo= Aug 4 19:44:33 reject: RCPT from mail.probit.wroc.pl[81.219.229.100]: 550 : Sender address rejected: Violation SPF: [...] from= helo= Now for the list of SPF-enabled domains MAIL FROM: that my personal server has seen in the last days. Make your own mind about which of these are legitimate, and which are spammers' ;-) 121mailoffers.com 121mailoffers.net 126.com 12.com 12inch.com 163.com 1cooloffers.com 573dls.com abso-bloody-lutely.com abv.bg access-one.com ac-montpellier.fr acsinc.net adelphia.net adlikon.ch alsation.com altn.com another.com antihunt.com aol.com arboi.fr.eu.org arsenal-fanatic.com arvelh.com asiacontent.com aspware.net bellatlantic.net bellsouth.net bigbgns.com bloody-minded.com bluebell.saar.de blueyonder.co.uk bol.com.br bugzilla.spamassassin.org carteblache.com c.dk charente.de club-internet.fr comedycottage.com csoft.bg dailydiscounts121.com dartmail.net dbc.mtview.ca.us did-the-earth-move.com dieboerse.de dlznstlz.com DNSreport.com duo.quattro.co.za e123discounts.com earthlink.net edailydiscounts.com edt02.net email.ro erldls.com eskimo.com faberoonie.com flashmail.com froffers.com garlic.com gc.net getgrtdeals.com getronics.com gmail.com gmx.at gmx.net google.com gorillanation.studiostore.com grtdeals.com handinhand.co.uk hushmail.com idcj.com iet.hist.no ilikeaeroplanejelly.com i-love-ayr.com iloveswindon.com inbox.ru incredimail.com interia.pl irislink.com ism.com.br iwantanother.com kendra.com kolumbus.fi leaveitwithme.com listbox.com list.ru lists.sourceforge.net mail.com mail.ru mediascape.de mycooloffers.com narod.ru nass.com.au nastypieceofwork.com nessus.org nls.net nordnet.fr nytimes.com ourcooloffers.com paregos.se petersen.mail.dk playingcupid.com pobox.com pop.com.br puk.ac.za real.com regularflow.com reply.mb00.net rldls.com rog.de sergeant.org seznam.cz skymail.fr snark.thyrsus.com snogtastic.com soter.com.br speed.net symantec.com testmail.com theonering.net trans-it.de tv2lorry.dk unicode.org uol.com.br uptodata.com usbank-email.com v2.listbox.com verizon.net vip.163.com weezing-fan.com wonderware.com world-foundation.org xmailserver.com xyzdeals.com yandex.ru yeah.net yesanother.com zipmail.com.br zzapp.org -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 12:15:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27199 for ; Thu, 5 Aug 2004 12:15: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 i75Fo7JK009865; Thu, 5 Aug 2004 08:50:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75Fo7m9009864; Thu, 5 Aug 2004 08:50: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 i75Fo71O009856 for ; Thu, 5 Aug 2004 08:50:07 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 7CAE717109 for ; Thu, 5 Aug 2004 11:58:10 -0400 (EDT) From: "Alan DeKok" To: "IETF MARID WG" Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) In-Reply-To: Your message of "Wed, 04 Aug 2004 14:44:26 CDT." Date: Thu, 05 Aug 2004 11:58:10 -0400 Message-Id: <20040805155810.7CAE717109@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > That is *exactly* what Spamassassin does. I have no idea where the > assumption that the Spamassassin folks are clueless came from. My comments were about the people using spamassassin, who can, and do, edit their rule database. I haven't looked at Spamassassin to see how it interacts with SPF, or what recommendations it makes for user-edited rule databases & SPF. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 12:21:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27483 for ; Thu, 5 Aug 2004 12:21:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75FjsdB009580; Thu, 5 Aug 2004 08:45: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 i75Fjsm2009579; Thu, 5 Aug 2004 08:45: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 i75Fjkcb009569 for ; Thu, 5 Aug 2004 08:45:46 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [130.129.131.181] ([::ffff:130.129.131.181]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 05 Aug 2004 11:45:46 -0400 id 0019767F.4112562A.000002DD In-Reply-To: <20040805071417.GB24130@nic.fr> References: <23FC8EBA-E678-11D8-8A0D-000A95CA7FAE@dbc.mtview.ca.us> <20040805071417.GB24130@nic.fr> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <827F9416-E6F6-11D8-A1FF-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Marshall Rose , IETF MARID WG From: Andrew Newton Subject: Re: short-term milestones Date: Thu, 5 Aug 2004 11:45:43 -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 Aug 5, 2004, at 3:14 AM, Stephane Bortzmeyer wrote: > > On Wed, Aug 04, 2004 at 05:41:08PM -0700, > Marshall Rose wrote > a message of 25 lines which said: > >> 3. final ipr statements are due monday, august 23rd. > > There already was a deadline on August 2nd. It was not respected. Why > this one would be better? The intent of the Aug 2 deadline was to give participants time to read any new IPR claims to be discussed in the Aug. 4 meeting, as it was felt new information would be forthcoming. To belay any fears, Aug 23 is a hard and fast deadline. -andy From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 12: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 MAA27608 for ; Thu, 5 Aug 2004 12: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 i75G3XEn010665; Thu, 5 Aug 2004 09:03: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 i75G3XvS010664; Thu, 5 Aug 2004 09:03:33 -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 i75G3Wut010658 for ; Thu, 5 Aug 2004 09:03:32 -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 C46DB17109 for ; Thu, 5 Aug 2004 12:11:37 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) In-Reply-To: Your message of "Wed, 04 Aug 2004 22:48:25 +0200." <20040804204825.GA2551@nic.fr> Date: Thu, 05 Aug 2004 12:11:37 -0400 Message-Id: <20040805161137.C46DB17109@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephane Bortzmeyer wrote: > Wether MARID encourage or discourages it will make no > difference. Scores of the various tests in SpamAssassin are not > determined by an human trying to guess wether "sex" should be more an > indication of spam than "viagra", or less. Scores are determined by > using the actual tests against a corpus of spam and a corpus of > ham. See http://wiki.apache.org/spamassassin/HowScoresAreAssigned. I am saying that we know a-priori, that giving positive marks to messages which pass SPF checks is not a good idea. Your statement also appears to contradict Wayne's assertion about Spamassassin. > Do note that, at the present time, the scores of all SPF-related tests > are very low (probably reflecting the small number of SPF-enabled > domains). See http://spamassassin.apache.org/tests.html and search for > SPF. Which has a "-0.001" for SPF_PASS, or marking the message as somehow "better" for passing SPF. While this score is low enough to not effect much, I think it should be forced to zero, otherwise spammers will *gain* by publishing MARID-style records. If the neural net method is still used, I'll bet that the score for SPF_PASS won't get significantly far from zero, for the reasons I outlined previously. Passing MARID checks is *no* indication of whether or not the message is spam. And if, as we've seen, spammers publish lots of MARID records, then there's a non-zero chance that a neural net may decide there's a correlation between spam & MARID records, which means MARID won't be as useful for everyone else. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 12:22:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27635 for ; Thu, 5 Aug 2004 12:22:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75G33iF010641; Thu, 5 Aug 2004 09:03: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 i75G33m5010640; Thu, 5 Aug 2004 09:03:03 -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 i75G336w010634 for ; Thu, 5 Aug 2004 09:03:03 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [130.129.131.181] ([::ffff:130.129.131.181]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 05 Aug 2004 12:03:05 -0400 id 0019768A.41125A39.00000444 In-Reply-To: <001301c47aa1$80113070$6c62fea9@ibmrkydk2ufvdd> References: <001301c47aa1$80113070$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: spf-discuss@v2.listbox.com, "'IETF MARID WG'" From: Andrew Newton Subject: Re: So ... did Dewey beat Truman? Date: Thu, 5 Aug 2004 12:03:04 -0400 To: "John Glube" 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 Aug 5, 2004, at 12:05 AM, John Glube wrote: > It might be helpful if Andy could clarify whether the > interview in the noted article is accurate, or did the > reporter mangle his remarks and draw the wrong conclusions. It was not accurate and either I miscommunicated with the reporter or he simply got it wrong. I'm sorry if this has caused any headache or heartache. It certainly was not intentional. Talking to reporters is not an aspect of chairship I like, and I have in the past ducked several reporters. However, from experience I have learned there is a higher probably that they will get the story right if I do talk to them, though it is never a guarantee. Again, sorry. -andy From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 12: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 MAA28459 for ; Thu, 5 Aug 2004 12:34: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 i75GGWT9011813; Thu, 5 Aug 2004 09: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 i75GGW1C011812; Thu, 5 Aug 2004 09:16:32 -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 i75GGVZD011805 for ; Thu, 5 Aug 2004 09:16:32 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040805161633.FOAJ26030.tomts20-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 5 Aug 2004 12:16:33 -0400 From: "John Glube" To: "'Carl Hutzler'" , "'IETF-MXCOMP'" Cc: Subject: RE: So ... did Dewey beat Truman? Date: Thu, 5 Aug 2004 12:18:26 -0400 Message-ID: <002201c47b07$d6a0b3a0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i75GGWZD011806 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The marid protocol should be set up so that the sender writes a sender policy record which allows the receiver under marid core to use this record to verify any one or more of the data sets the receiver wants to check. Let me explain. Want to do an SMTP mail from check? Okay. Want to do an EHELO check? Great Want to do an SMTP sender from check? Sure Want to do any combination of SMTP mail from, EHELO and SMTP sender from checks? Fine. Want to do any combination of SMTP mail from, EHELO, SMTP Sender from and PRA checks. Hey, that's fine too. (This is the AOL choice.) PRA is moved to its own spot to give MS the option, feel you need a defensive patent and royalty free license. Hey, go for it. It may be that checking using SPF and Submitter is sufficient. It may be that using CSV suffices. However, we should only say to receivers you must run checks. Which checks you run is up to you. In turn this lets the market decide which checks are optimal and deliver the best results. If a service provider like AOL feels the optimal solution is to check everything, hey ... go for it. As to a public-key cryptography solution relying on DNS, on the sender side, one would need to: * amend the marid protocol to add the requirement to publish a public-key; * amend core to allow receivers to choose to check the public key. I would suggest it is too early to dictate this to senders. Let me repeat so there is no misunderstanding: * The sender under marid protocol publishes a sender policy. To be acceptable, this sender policy must allow the receiver to run any one or more of a series of tests based on SMTP mail from, ehelo, SMTP sender from and PRA. At some point in the future we will add a form of public-key cryptographic test. * The receiver under marid core can elect what 'data sets' she wants to check using the sender policy published for the domain under the marid protocol. From the sender's perspective, he says to the receiver: "Want to check SMTP mail from, ehelo, SMTP sender from, PRA ... go ahead. Its all there and everything is in order." The receiver can say, for example thanks, but I only need to check the ehelo using the CSV protocol. All the rest of these checks are redundant. I am satisfied the data set from ehelo, along with the use of reputation and accreditation services and ultimately a light weight version of public key cryptography will suffice. Marid core should not tell a receiver you must check everything, only that you may check one or more of the following: SMTP mail from The protocol for using SMTP mail from is found in SPF (needs to be updated). SMTP sender from The protocol for using SMTP sender from is found in Submitter? EHELO The protocol for using EHELO is found in CSV. PRA The protocol for using PRA is found in PRA. (At some future point in time, a public key cryptography solution or some other variant which we have yet to think about.) In this way, it allows proponents of particular solutions to provide the receiving market with a choice. This market can then decide which solution it wishes to use based on what best suits the needs of the receiver. Write the rules so you dictate what information senders must provide. Don't write the rules to dictate a solution for receivers. Allow the rules to be flexible to let proponents fashion a solution within the established framework which best suits the needs of the specific receiver or class of receivers. So, if AOL feels, we want to check everything, then it will look for a solution provider which allows it to check everything. At the same time if XYZ says, we don't need all this backup checking and will only check this particular data set using this approach, then presuming there is a solution provider, that's up to XYZ. :-) John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 12: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 MAA29550 for ; Thu, 5 Aug 2004 12:52:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Gbtof014463; Thu, 5 Aug 2004 09:37: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 i75GbtEO014462; Thu, 5 Aug 2004 09:37:55 -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 i75Gbs3w014452 for ; Thu, 5 Aug 2004 09:37:54 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 005C928290 for ; Thu, 5 Aug 2004 18:37:56 +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 07224-05 for ; Thu, 5 Aug 2004 18:37:54 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 501) id 0D65328292; Thu, 5 Aug 2004 18:37:54 +0200 (CEST) From: Michel Bouissou Organization: Me, Myself and I To: "IETF MARID WG" Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) Date: Thu, 5 Aug 2004 18:37:53 +0200 User-Agent: KMail/1.6.1 References: <20040805161137.C46DB17109@mail.nitros9.org> In-Reply-To: <20040805161137.C46DB17109@mail.nitros9.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200408051837.53545@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 jeudi 5 Août 2004 18:11, Alan DeKok a écrit : > > > Do note that, at the present time, the scores of all SPF-related tests > > are very low (probably reflecting the small number of SPF-enabled > > domains). See http://spamassassin.apache.org/tests.html and search for > > SPF. > >   Which has a "-0.001" for SPF_PASS, or marking the message as somehow > "better" for passing SPF. > >   While this score is low enough to not effect much, I think it should > be forced to zero Practically speaking, -0.001 is equivalent to zero. The difference is that if you use zero, the SPF tests may be skipped alltogether (usualy when a test score is zero, SA bypasses performing it), and if it is -0.001 the test will be performed and its result may be reflected into SA added mail headers (depending upon configuration). So -0.001 doesn't change anything for the actual scoring of the message except that it allows having the SPF results added to the message headers. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 12:57: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 MAA29825 for ; Thu, 5 Aug 2004 12:57:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75GgDNm014851; Thu, 5 Aug 2004 09:42:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75GgDNG014850; Thu, 5 Aug 2004 09:42:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75GgCSK014833 for ; Thu, 5 Aug 2004 09:42:12 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i75Gg8qc012935 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 18:42:08 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i75GeSM6002585 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 18:40:28 +0200 From: Hadmut Danisch Date: Thu, 5 Aug 2004 09:40:27 -0700 To: ietf-mxcomp@imc.org Subject: Does marid-submitter-02 really make sense? Message-ID: <20040805164027.GA2443@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, to paraphrase my yesterday's session's question: Does the SUBMITTER parameter really make sense? Case 1: The sender is authorized by some domain to send messages. The message will have to be accepted and therefore to be transmitted. No benefit in checking the parameter before transmission. Could do this also after transmission. Case 2: The sender is not authorized or does not want to reveal her identity (e.g. spammer). Sender would be stupid if she gave a SUBMITTER parameter not covering her IP address. So the sender will certainly do as if she had not yet implemented the SUBMITTER, i.e. omit it. Message will be transmitted as well. So what sense does it make to introduce this new extension? Could have done the same thing better based on header checks after transmission of message. An additional header entry is much easier to implement or configure. The only sense I can see is a smooth transition: E.g. allow both - submitter and header based checks - until Dec-31 2005 and require everyone to support it by then. But if this is desired, then this is a completely wrong way. In such a case the MARID group should not hide the smooth transition in a SMTP extension. Instead it should mark this all as a "temporary ad hoc solution to fight spam and crime now", and reengineer a better solution then. Yesterday's answers to my question didn't convince me. On the contrary. It caused doubts whether this is really a well planned solution or rather a workaround that does not really work around. Wouldn't it be better to allow a new header entry line instead? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 13:03: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 NAA00131 for ; Thu, 5 Aug 2004 13:03: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 i75Gp7MU015512; Thu, 5 Aug 2004 09:51: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 i75Gp72t015511; Thu, 5 Aug 2004 09:51:07 -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 i75Gp6X5015505 for ; Thu, 5 Aug 2004 09:51:06 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i75Gp933013134 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 18:51:09 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i75GoFan002721 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 18:50:15 +0200 From: Hadmut Danisch Date: Thu, 5 Aug 2004 09:50:15 -0700 To: ietf-mxcomp@imc.org Subject: marid-submitter-02: Which SUBMITTER value? Message-ID: <20040805165015.GA2628@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, more questions about the SUBMITTER extension. Where does it come from? How does it find it's way to the recipient? The draft only describes the SMTP protocol details. But how does the sending MTA know what's the value of the parameter, and when to use it? Is it to be given by the injecting MUA? If so, how? Optional parameter to /usr/sbin/sendmail ? My first guess would be this: MTA knows which domains it is authorized to be sender of (either by configuration or querying MARID records for it's own IP addresses). If there is a message to transmit which does not have a sender address the MTA is authorized to use, then some default value (set by configuration) would have to be used. Is that what it is supposed to be? Even if so, the draft lacks a statement and precise description. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 13: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 NAA00487 for ; Thu, 5 Aug 2004 13: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 i75Gox3k015498; Thu, 5 Aug 2004 09:50:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75Gox1T015497; Thu, 5 Aug 2004 09:50:59 -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 i75GowxU015491 for ; Thu, 5 Aug 2004 09:50:58 -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 1BslSC-0007HV-4F for ietf-mxcomp@imc.org; Thu, 05 Aug 2004 11:51:01 -0500 To: "IETF MARID WG" References: <001301c47aa1$80113070$6c62fea9@ibmrkydk2ufvdd> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 05 Aug 2004 11:50:55 -0500 In-Reply-To: (Andrew Newton's message of "Thu, 5 Aug 2004 12:03:04 -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: So ... did Dewey beat Truman? 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 Andrew Newton writes: > On Aug 5, 2004, at 12:05 AM, John Glube wrote: > >> It might be helpful if Andy could clarify whether the >> interview in the noted article is accurate, or did the >> reporter mangle his remarks and draw the wrong conclusions. > > It was not accurate and either I miscommunicated with the reporter or > he simply got it wrong. There is also a third possiblity: An editor chopped things up in order to make things fit. Reporters rarely "have time" to get a story reviewed by their sources, and editors rarely "have time" to get their edits reviewed by the reporter. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 13:16: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 NAA00970 for ; Thu, 5 Aug 2004 13:16: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 i75H0E10016095; Thu, 5 Aug 2004 10:00: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 i75H0Elv016094; Thu, 5 Aug 2004 10:00:14 -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 i75H0D9q016087 for ; Thu, 5 Aug 2004 10:00:14 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i75H0Dew013334 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 19:00:13 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i75GxBHN002823 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 18:59:11 +0200 From: Hadmut Danisch Date: Thu, 5 Aug 2004 09:59:11 -0700 To: ietf-mxcomp@imc.org Subject: marid-submitter-02: What is a SUBMITTER? Message-ID: <20040805165911.GA2726@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, to paraphrase another of my yesterday's questions, where the answer did not make me happy. What is a SUBMITTER? What's its meaning, its semantics? Why do you call it a SUBMITTER? And why do you use a full e-mail address alike identifier if you use the domain part only? What's the left part good for? I'm pretty sure this will cause confusion and misinterpretation. First, it looks like an e-mail address, and there even might be an identical e-mail address, but it _is_ not an e-mail address, because it is never meant to be used as a recipient's e-mail address for any e-mail. What's that left part good for? Why do you use it if it has no meaning (at least none precisely defined in the draft)? Second, it is not a legal statement about beeing the submitter. Imagine the content of the message is offending or violating law (e.g. child porn, terrorists message, etc.) What would someone (e.g. a public attorney) keep from accusing the owner of the given e-mail address? After all, this is the submitter, and isn't that MARID thing a mechanism to verifiy the submitter? Isn't it evidence that the sender agreed to be the submitter of the message? Third: What is it actually? It is nothing more than a pointer to a domain. It helps finding a domain which's MARID record covers the IP address of the sending MTA. That's it. Nothing more than that. Why don't you treat it exactly like that? Why do you give it some meaning it doesn't have or appearance it doesn't meet? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 13:30:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01677 for ; Thu, 5 Aug 2004 13:30: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 i75HF1IT017168; Thu, 5 Aug 2004 10:15:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75HF1Vk017167; Thu, 5 Aug 2004 10:15:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75HF0LV017148 for ; Thu, 5 Aug 2004 10:15:01 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [192.168.0.5] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id 9927946504 for ; Thu, 5 Aug 2004 12:15:01 -0500 (CDT) Message-ID: <41126AF0.2040706@ehsco.com> Date: Thu, 05 Aug 2004 13:14:24 -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: ietf-mxcomp@imc.org Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) References: <20040805161137.C46DB17109@mail.nitros9.org> In-Reply-To: <20040805161137.C46DB17109@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 8/5/2004 12:11 PM, Alan DeKok wrote: > Which has a "-0.001" for SPF_PASS, or marking the message as somehow > "better" for passing SPF. > > While this score is low enough to not effect much, I think it should > be forced to zero I haven't looked at this particular ruleset yet, but a score of zero usually means "don't run the test" But "pass" truly is meaningless, so not bothering with that specific test does make some sense. "fail" is the only hard result that means anything. From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 13:38:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02037 for ; Thu, 5 Aug 2004 13:38:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75H691M016415; Thu, 5 Aug 2004 10:06:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75H69Oj016414; Thu, 5 Aug 2004 10:06:09 -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 i75H68Zj016406 for ; Thu, 5 Aug 2004 10:06:08 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i75H6BUl013483 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 19:06:11 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i75H5txt002927 for ietf-mxcomp@imc.org; Thu, 5 Aug 2004 19:05:55 +0200 From: Hadmut Danisch Date: Thu, 5 Aug 2004 10:05:54 -0700 To: ietf-mxcomp@imc.org Subject: marid-submitter-02: Recipient's point of view Message-ID: <20040805170554.GA2869@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, sorry, to flood you with questions, but another one of my yesterday's questions. It hasn't been answered yesterday. Imagine this: MAIL FROM: SUBMITTER=criminal@superphishing.any Of course, superphishing.any would cover the sending MTA's IP address, so the message would be accepted by the receiving MTA. But how could the human reading the message tell that it came from superphishing.any and not from the bank? Today's MUAs are not ready for this extensions and I do not see how the SUBMITTER value would find it's way to the human reader. So forging and cheating is still possible, isn't it? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 13:43: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 NAA02281 for ; Thu, 5 Aug 2004 13:43: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 i75HSIaj017977; Thu, 5 Aug 2004 10:28: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 i75HSIob017976; Thu, 5 Aug 2004 10:28:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75HSHsk017970 for ; Thu, 5 Aug 2004 10:28:17 -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 3EF1D132CD1; Thu, 5 Aug 2004 13:30:44 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id EA4265F0; Thu, 5 Aug 2004 13:28:18 -0400 (EDT) Date: Thu, 5 Aug 2004 13:28:18 -0400 From: Meng Weng Wong To: Hadmut Danisch Cc: ietf-mxcomp@imc.org Subject: Re: marid-submitter-02: Recipient's point of view Message-ID: <20040805172818.GD28401@dumbo.pobox.com> References: <20040805170554.GA2869@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040805170554.GA2869@danisch.de> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 05, 2004 at 10:05:54AM -0700, Hadmut Danisch wrote: | | MAIL FROM: SUBMITTER=criminal@superphishing.any | | But how could the human reading the message tell that it came from | superphishing.any and not from the bank? Today's MUAs are not ready | for this extensions and I do not see how the SUBMITTER value would | find it's way to the human reader. You are correct that MUAs will need to change. The SUBMITTER draft assumes familiarity with the core/PRA document. Section 7.5 of that document reads: 7.5 MUA Implementers When displaying a received message, an MUA SHOULD display the purported responsible address as defined by this document whenever that address differs from the RFC 2822 From address. This display SHOULD be in addition to the RFC 2822 From address. When a received message contains multiple headers that might be used for the purported responsible address determination, an MUA should consider displaying all of them. That is, if a message contains several Resent-From's, a Sender and a From, an MUA should consider displaying all of them. http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt I think we all agree that the above argument as an antiphishing device is weaker than next-generation cryptographic solutions. The rationale was this: preferring the SUBMITTER value over the MAIL FROM value was seen as making life easier for forwarders. Requiring a PASS on SUBMITTER was seen as making it possible to quickly attach reputation to bad spammers. (In other words, a reputation system would be expected to quickly list superphishing.any. This expectation is justified by the fact that DNSBLs seem to respond quickly, and RHSBLs should be able to respond just as quickly.) The common case is expected for SUBMITTER to not be present in most spam, and so the check would operate against MAIL FROM. This reasoning is justified by: 4.1 Setting the SUBMITTER Parameter Value SMTP clients that support the Responsible Submitter extension MUST 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. This includes messages where the MAIL FROM address is empty or "<>". http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-02.txt I understand that to mean that the sending MTA has reduced MAIL FROM: SUBMITTER= to MAIL FROM: and therefore a SPF check on K before DATA is sufficient. The next sentence in the draft says: SMTP clients SHOULD include the SUBMITTER parameter on messages where the purported responsible address is the same as the MAIL FROM address. I move to rephrase that as: SMTP clients MAY include the SUBMITTER parameter on messages where the purported responsible address is the same as the MAIL FROM address. From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 13:43:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02312 for ; Thu, 5 Aug 2004 13:43:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75HHuJ0017353; Thu, 5 Aug 2004 10:17: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 i75HHuvp017352; Thu, 5 Aug 2004 10:17:56 -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 i75HHtJ9017345 for ; Thu, 5 Aug 2004 10:17:55 -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 2D88F132CFB for ; Thu, 5 Aug 2004 13:20:21 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id C45495F0; Thu, 5 Aug 2004 13:17:55 -0400 (EDT) Date: Thu, 5 Aug 2004 13:17:55 -0400 From: Meng Weng Wong To: IETF MARID WG Subject: Re: So ... did Dewey beat Truman? Message-ID: <20040805171755.GC28401@dumbo.pobox.com> References: <001301c47aa1$80113070$6c62fea9@ibmrkydk2ufvdd> 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, Aug 05, 2004 at 11:50:55AM -0500, wayne wrote: | | There is also a third possiblity: An editor chopped things up in | order to make things fit. Reporters rarely "have time" to get a story | reviewed by their sources, and editors rarely "have time" to get their | edits reviewed by the reporter. | In the same vein, many readers of a certain online community news form rarely "have time" to read the articles before posting their comments. :) From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 13:58: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 NAA02983 for ; Thu, 5 Aug 2004 13:58:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75HgTdA018810; Thu, 5 Aug 2004 10:42:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75HgTnl018809; Thu, 5 Aug 2004 10:42:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75HgSpY018803 for ; Thu, 5 Aug 2004 10:42:28 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LDAOL199E800005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Thu, 05 Aug 2004 10:42:31 -0700 (PDT) Date: Thu, 05 Aug 2004 10:11:33 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Does marid-submitter-02 really make sense? In-reply-to: "Your message dated Thu, 05 Aug 2004 09:40:27 -0700" <20040805164027.GA2443@danisch.de> To: Hadmut Danisch Cc: ietf-mxcomp@imc.org Message-id: <01LDAWC6X2SQ00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040805164027.GA2443@danisch.de> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > Does the SUBMITTER parameter really make sense? > Case 1: The sender is authorized by some domain to > send messages. The message will have to be accepted and therefore > to be transmitted. No benefit in checking the parameter before > transmission. Could do this also after transmission. Maybe, maybe not. Having the information early might in some MTAs allow for throughput optimizations. > Case 2: The sender is not authorized or does not want > to reveal her identity (e.g. spammer). Sender would be stupid > if she gave a SUBMITTER parameter not covering her IP address. > So the sender will certainly do as if she had not yet implemented the > SUBMITTER, i.e. omit it. Message will be transmitted as well. You're missing cases 3 and 4: Case 3: The sender should be authorized by some domain but for whatever reason is not. This extension allows this condition to be detected early and may avoid transfer of a large message. Case 4: The sender should not be authorized and uses SUBMITTER anyway. (Even if you assume spammers never do this directly, which may or may not be true, there are cases where mail is forced through intermediaries that might not be prepared to do a validation check but would be able to add a SUBMITTER field.) This again transfer of the message body to be avoided. This is clearly a corner case, but it needs to be on the list. > So what sense does it make to introduce this new extension? Could have > done the same thing better based on header checks after transmission > of message. An additional header entry is much easier to implement or > configure. There is absolutely no value and considerable harm in using an additional header field. The only advantage SUBMITTER has is temporal in nature - it delivers the information sooner. This is lost with a header that's delivered at the same time as all the others. And in order to be effective the field has to be compared with the value derived from other other header fields, so the same amount of work has to be done in either case. Even worse, when there's a header present containing this information there are bound to be lazy implementations that will not perform the check. This opens a security hole. Of course SUBMITTER has a similar hole, but the liklihood of someone bothering to implement SUBMITTER and not do the header check seems a lot smaller than the liklihood of someone just using a header value without the check. > The only sense I can see is a smooth transition: E.g. allow both - > submitter and header based checks - until Dec-31 2005 and require > everyone to support it by then. But if this is desired, then this is a > completely wrong way. > In such a case the MARID group should not hide the smooth transition > in a SMTP extension. Instead it should mark this all as a "temporary > ad hoc solution to fight spam and crime now", and reengineer a better > solution then. > Yesterday's answers to my question didn't convince me. On the > contrary. It caused doubts whether this is really a well planned > solution or rather a workaround that does not really work around. > Wouldn't it be better to allow a new header entry line instead? Absolutely not. I don't especially care if SUBMITTER happens or not - I can implement it and I can live without it. But I'm strongly opposed to a header equivalent of SUBMITTER. Ned From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 14:10: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 OAA03662 for ; Thu, 5 Aug 2004 14:10: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 i75HnMGV019346; Thu, 5 Aug 2004 10:49: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 i75HnMDR019345; Thu, 5 Aug 2004 10:49:22 -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 i75HnLC1019338 for ; Thu, 5 Aug 2004 10:49:22 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i75HnLPl014600; Thu, 5 Aug 2004 19:49:21 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i75Hn9w5003825; Thu, 5 Aug 2004 19:49:09 +0200 From: Hadmut Danisch Date: Thu, 5 Aug 2004 10:49:09 -0700 To: Meng Weng Wong Cc: ietf-mxcomp@imc.org Subject: Re: marid-submitter-02: Recipient's point of view Message-ID: <20040805174909.GA3352@danisch.de> References: <20040805170554.GA2869@danisch.de> <20040805172818.GD28401@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040805172818.GD28401@dumbo.pobox.com> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 05, 2004 at 01:28:18PM -0400, Meng Weng Wong wrote: > > You are correct that MUAs will need to change. It is far from reality to assume that sufficient many MUAs will change within 1-2 years. > The SUBMITTER draft assumes familiarity with the core/PRA > document. Section 7.5 of that document reads: > > 7.5 MUA Implementers > > When displaying a received message, an MUA SHOULD display the > purported responsible address as defined by this document whenever > that address differs from the RFC 2822 From address. This display > SHOULD be in addition to the RFC 2822 From address. This does not answer the question. How does the information find it's way to the MUA? The SUBMITTER is not an RFC2822 information. Were does it find it's place in a standard Unix mbox file without changing the mbox file format? How does IMAP support this? POP? What about UUCP? How should a MUA be able to display an information as long as there is no defined way how the MTA should pass the information to the MUA? How many protocols, file formats and software do you intend to change? Has anyone ever implemented this? Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 14:17: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 OAA03996 for ; Thu, 5 Aug 2004 14:17: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 i75I6Hl2020497; Thu, 5 Aug 2004 11:06: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 i75I6HIB020496; Thu, 5 Aug 2004 11:06:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from Garovirus.uqss.uquebec.ca (garovirus.uqss.uquebec.ca [192.77.51.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75I6G3W020484 for ; Thu, 5 Aug 2004 11:06:16 -0700 (PDT) (envelope-from gfk@logidac.com) Received: from maestro ([132.214.200.206]) by Garovirus.uqss.uquebec.ca (8.12.10/8.12.8) with SMTP id i75I67u5005090 for ; Thu, 5 Aug 2004 14:06:07 -0400 Message-ID: <015201c47b16$feb41c10$cec8d684@sraq.intra> From: "Guillaume Filion" To: References: <002201c47b07$d6a0b3a0$6c62fea9@ibmrkydk2ufvdd> Subject: Re: So ... did Dewey beat Truman? Date: Thu, 5 Aug 2004 14:06:56 -0400 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.1437 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Garovirus-MailScanner: Found to be clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "John Glube" wrote: > The marid protocol should be set up so that the sender > writes a sender policy record which allows the receiver > under marid core to use this record to verify any one or > more of the data sets the receiver wants to check. It makes a lot of sense to me; and I'm pretty sure that it's what's going to happen whatever the RFC says. It's better to design the protocol with this in mind than complaining later that people are implementing only a part of the RFC. My 2 cents, GFK's -- Guillaume Filion, ing. jr Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 14:20: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 OAA04111 for ; Thu, 5 Aug 2004 14:20: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 i75I29Ch020225; Thu, 5 Aug 2004 11:02: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 i75I29lG020224; Thu, 5 Aug 2004 11:02:09 -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 i75I25FR020216 for ; Thu, 5 Aug 2004 11:02:08 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i75I29md014917; Thu, 5 Aug 2004 20:02:09 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i75I1ulC004010; Thu, 5 Aug 2004 20:01:56 +0200 From: Hadmut Danisch Date: Thu, 5 Aug 2004 11:01:55 -0700 To: ned.freed@mrochek.com Cc: ietf-mxcomp@imc.org Subject: Re: Does marid-submitter-02 really make sense? Message-ID: <20040805180155.GA3883@danisch.de> References: <20040805164027.GA2443@danisch.de> <01LDAWC6X2SQ00005R@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01LDAWC6X2SQ00005R@mauve.mrochek.com> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 05, 2004 at 10:11:33AM -0700, ned.freed@mrochek.com wrote: > > Maybe, maybe not. Having the information early might in some MTAs allow for > throughput optimizations. Really? I don't see significant potential for optimizations. And even if you do need this you can rely on the fact that the message header is transmitted before the message body. If you want to optimize nobody keeps you from evaluating the message header before completion of the message transfer. A header line will be transmitted only very few bytes later than a SMTP extension. So not an argument. > You're missing cases 3 and 4: > > Case 3: The sender should be authorized by some domain but for whatever > reason is not. This extension allows this condition to be detected early > and may avoid transfer of a large message. Not convincing. The main cases will be authorized and unauthorized. I doesn't make sense to extend the SMTP protocol just for the case of misconfiguration. It does not make sense to invent a protocol extensions with major disadvantes just to prevent some bytes of transmission in case of misconfiguration. > Case 4: The sender should not be authorized and uses SUBMITTER anyway. > (Even if you assume spammers never do this directly, which may or may > not be true, there are cases where mail is forced through intermediaries > that might not be prepared to do a validation check but would be able to add a > SUBMITTER field.) This again transfer of the message body to be avoided. > This is clearly a corner case, but it needs to be on the > list. I don't see that there will be a significant number of idiots sending messages while they know that the receiver is MARID aware and will discard the message anyway if they could do better without SUBMITTER. Even a spammer has to pay money and time for transmission. If a spammer sees a MARID aware MTA and knows that the message will be discarded it is logical to go to the next victim instead of wasting time and money. So this is not a relevant case. > The only advantage SUBMITTER has is temporal in nature - it > delivers the information sooner. Not significantly sooner than a header line. Nobody forces you to wait for completion of transmission before to look at the header. If this is the only advantage, then it is not a real advantage at all. Why introduce a protocol extension without a real advantage? Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 14:28: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 OAA04739 for ; Thu, 5 Aug 2004 14:28: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 i75I9mNn020749; Thu, 5 Aug 2004 11:09:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75I9mp7020748; Thu, 5 Aug 2004 11:09:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75I9lGO020741 for ; Thu, 5 Aug 2004 11:09: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 1BsmgS-0008Cl-Pb for ietf-mxcomp@imc.org; Thu, 05 Aug 2004 13:09:51 -0500 To: "IETF MARID WG" References: <20040805161137.C46DB17109@mail.nitros9.org> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 05 Aug 2004 13:09:44 -0500 In-Reply-To: <20040805161137.C46DB17109@mail.nitros9.org> (Alan DeKok's message of "Thu, 05 Aug 2004 12:11:37 -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: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) 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 <20040805161137.C46DB17109@mail.nitros9.org> "Alan DeKok" writes: > Stephane Bortzmeyer wrote: >> Wether MARID encourage or discourages it will make no >> difference. Scores of the various tests in SpamAssassin are not >> determined by an human trying to guess wether "sex" should be more an >> indication of spam than "viagra", or less. Scores are determined by >> using the actual tests against a corpus of spam and a corpus of >> ham. See http://wiki.apache.org/spamassassin/HowScoresAreAssigned. > > I am saying that we know a-priori, that giving positive marks to > messages which pass SPF checks is not a good idea. > > Your statement also appears to contradict Wayne's assertion about > Spamassassin. In Spamassassin, the more postivie the score, the more spammy the message was found. Giving a positive score for a pass from SPF is not a good idea because an SPF pass is neither a sign of spam nor ham. Failing an SPF check is a spam sign according to their genetic alogrithm. Stephane's statements do not controdict mine, other than I didn't correct your confusion over negative vs positive scores. Stephane explained *how* Spamassassin comes up with their numbers, I just mentioned the result. >> Do note that, at the present time, the scores of all SPF-related tests >> are very low (probably reflecting the small number of SPF-enabled >> domains). See http://spamassassin.apache.org/tests.html and search for >> SPF. > > Which has a "-0.001" for SPF_PASS, or marking the message as somehow > "better" for passing SPF. As others have pointed out, this has no real effect, it only means that the results gets put into the headers. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 14:53:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06378 for ; Thu, 5 Aug 2004 14:53: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 i75IXpaj023094; Thu, 5 Aug 2004 11:33: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 i75IXp1v023092; Thu, 5 Aug 2004 11:33:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75IXosY023080 for ; Thu, 5 Aug 2004 11:33:50 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1Bsn3k-0008VM-Nc for ietf-mxcomp@imc.org; Thu, 05 Aug 2004 13:33:53 -0500 To: "IETF MARID WG" References: <001301c47aa1$80113070$6c62fea9@ibmrkydk2ufvdd> <20040805171755.GC28401@dumbo.pobox.com> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 05 Aug 2004 13:33:48 -0500 In-Reply-To: <20040805171755.GC28401@dumbo.pobox.com> (Meng Weng Wong's message of "Thu, 5 Aug 2004 13:17:55 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: So ... did Dewey beat Truman? 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 <20040805171755.GC28401@dumbo.pobox.com> Meng Weng Wong writes: > On Thu, Aug 05, 2004 at 11:50:55AM -0500, wayne wrote: > | > | There is also a third possiblity: An editor chopped things up in > | order to make things fit. Reporters rarely "have time" to get a story > | reviewed by their sources, and editors rarely "have time" to get their > | edits reviewed by the reporter. > > In the same vein, many readers of a certain online community > news form rarely "have time" to read the articles before > posting their comments. :) Yeah, that is much like many IETF meeting attendees rarely "have time" to read the I-Ds. Paul Vixie has a very cool rant on that subject during the DNSOPs yesterday. From what I can tell, the MARID session also suffered from this problem with respect to the "breaking up the marid-core I-D". Yeah, I know, there *are* still a few things other than just the PRA algorithm described in the marid-core I-D, but from the discussions yesterday, it sounded like many people thought that the stuff that moved to marid-protocol was still in marid-core. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 15:02: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 PAA06872 for ; Thu, 5 Aug 2004 15:02:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75IicWD024170; Thu, 5 Aug 2004 11: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 i75IicHS024169; Thu, 5 Aug 2004 11: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.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75IicAQ024161 for ; Thu, 5 Aug 2004 11:44:38 -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 B70CE17109 for ; Thu, 5 Aug 2004 14:52:42 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) In-Reply-To: Your message of "Thu, 05 Aug 2004 18:37:53 +0200." <200408051837.53545@totor.bouissou.net> Date: Thu, 05 Aug 2004 14:52:42 -0400 Message-Id: <20040805185242.B70CE17109@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michel Bouissou wrote: > Practically speaking, -0.001 is equivalent to zero. I had stated as much. > The difference is that if you use zero, the SPF tests may be skipped > alltogether (usualy when a test score is zero, SA bypasses > performing it), Hmm... the scores are overloaded with additional, non-score information. I can see why they did that, but it then requires things like "scores of epsilon", or -0.001, in order to get "zero", without it's other effects. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 15:08: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 PAA07568 for ; Thu, 5 Aug 2004 15:08:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Iu98v024961; Thu, 5 Aug 2004 11:56: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 i75Iu9WO024960; Thu, 5 Aug 2004 11:56:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Iu6W8024940 for ; Thu, 5 Aug 2004 11:56:09 -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 2FB4417109 for ; Thu, 5 Aug 2004 15:04:10 -0400 (EDT) From: "Alan DeKok" To: "IETF MARID WG" Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) In-Reply-To: Your message of "Thu, 05 Aug 2004 13:09:44 CDT." Date: Thu, 05 Aug 2004 15:04:10 -0400 Message-Id: <20040805190410.2FB4417109@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > In Spamassassin, the more postivie the score, the more spammy the > message was found. I understand. My comments were about other anti-spam systems, too. The intention was to describe the "spamminess" of a message, so positive scores are positive indications of spam. I should probably have used the word "benefit" rather than "score", but I can't keep track of which system uses what vocabulary. For implementation reasons, Spamassassin has chosen to invert the "score", so "ham" is given negative scores. It amounts to the same thing, with different vocabulary. > Stephane explained *how* Spamassassin comes up with their numbers, I > just mentioned the result. My point then, as now, is that passing SPF or MARID checks means *nothing* about the "spam" or "ham" nature of a message. Any anti-spam system should give *zero* additional benefit to messages which pass those checks. If those systems choose to implement zero as a small negative number, that's their business. Having spamassassin use a neural net to determine the score for SPF_PASS is wrong. We *know* what the value is, from an analysis of the system. > As others have pointed out, this has no real effect, it only means > that the results gets put into the headers. That's an implementation decision for Spamassassin. My comments about scoring were completely independent of reporting of that score. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 15:11:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07981 for ; Thu, 5 Aug 2004 15:11: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 i75Ir01i024783; Thu, 5 Aug 2004 11:53: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 i75Ir01D024782; Thu, 5 Aug 2004 11:53:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Iqxnb024775 for ; Thu, 5 Aug 2004 11:53:00 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BsnML-0000H6-4L for ietf-mxcomp@imc.org; Thu, 05 Aug 2004 13:53:03 -0500 To: "IETF MARID WG" From: wayne Reply-To: "IETF MARID WG" Date: Thu, 05 Aug 2004 13:53:00 -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: changing the SPF record version number? Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.4 required=4.0 tests=AWL,BAYES_00,DOMAIN_BODY, GREYLIST_ISWHITE autolearn=no version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yesterday in one of the MARID sessions at IETF-60, it was decided that we should change the version number on the SPF records. I didn't raise any objections to this during the meeting because I needed to think about it. Having thought about it over night, I think that *just* changing the version number and abandoning the SPF1 records is a bad idea. First off, I think people are underestimating the number of SPF records that have already been published. Someone with a list of all the .ch domains has started to go through them and see who has published records. They added 20,000 domains to the SPF adoption roll yesterday, and they are only up to 's'. After doing two surveys of 1.3 million email domains in the last 3 months, I have also found that the adoption roll underestimates the number of published SPF records. Instead of just changing the version number of the records and ignoring SPF1 records, I think we should use SPF1 records unless SPF2 records have been published and I think SPF2 should have the scope variable added as per the Unified-SPF I-Ds. Then, if domain owners feel that they need different records when used with the PRA algorithm, they can publish SPF2 records and use the scope variable to make the required distinctions. During the discussions of the Unified-SPF idea (which happened mostly on the SPF lists, not here), there were also some discussions about using a scope= modifier. Personally, I don't think it is as good of a solution, but it is certainly a possibility. For those who are interested in reading the discussions about the scope= modifier instead of just reinventing the wheel, you can view the discussions of the spf-discuss archives from June and July here: http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/index.html http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/index.html Basically search for the posts with the subject that have "unified" in them. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 17: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 RAA18359 for ; Thu, 5 Aug 2004 17: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 i75LgocO037550; Thu, 5 Aug 2004 14: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 i75LgoR7037549; Thu, 5 Aug 2004 14:42:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Lgnil037540 for ; Thu, 5 Aug 2004 14:42:49 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040805214253.XPJS1984.tomts5-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 5 Aug 2004 17:42:53 -0400 From: "John Glube" To: "'Guillaume Filion'" , Subject: RE: So ... did Dewey beat Truman? Date: Thu, 5 Aug 2004 17:44:44 -0400 Message-ID: <003501c47b35$6c27d750$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <015201c47b16$feb41c10$cec8d684@sraq.intra> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i75Lgnil037544 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Guillaume, Here is the problem and its classic. We don't know whether it is possible for people to write a sender policy which will work for everything. Even if it is possible, with all the chances for mistakes in setting it up and as we have never done anything like this on the Internet before on this scale, is it better to go with something simple? And what about less developed countries who are simply struggling to get online. Are we going to simply say tough? So, does this mean we back away from making it a must on the sender side and rather have it as a recommendation? Prudent senders will take the time and effort to properly configure their systems so that recipient's can run any check they want. Or will they? Unless it is mandatory, why do it? On the receiving side, we have protocols which allow for checks based on different aspects of the message header. Which checks will be used will depend on a provider's particular needs. A big ISP like AOL may need to use SPF, Sender-ID, Submitter, CSV and DomainKeys given how everyone uses their system. A small home based web hosting service or ISP may only need to use SPF or CSV. Why do it? Because, it is the most cost efficient way of dealing with the problem of spoofing and phishing, or because a large enough group of service providers say if you want to send email to us, you must? Be a prudent sender. :-) John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 18:23: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 SAA21708 for ; Thu, 5 Aug 2004 18:22: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 i75MAkIO039991; Thu, 5 Aug 2004 15:10:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75MAkPe039990; Thu, 5 Aug 2004 15:10:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75MAjiT039984 for ; Thu, 5 Aug 2004 15:10:45 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1BsqRe-0002Ll-2a for ietf-mxcomp@imc.org; Thu, 05 Aug 2004 17:10:47 -0500 To: ietf-mxcomp@imc.org (ietf mxcomp (e-mail)) References: <557@rama.pamho.net> From: wayne Date: Thu, 05 Aug 2004 17:10:41 -0500 In-Reply-To: <557@rama.pamho.net> (Roger Moser's message of "Thu, 5 Aug 2004 14:06 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Some statistics from the SPF-discuss list 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: fyi; Roger Moser posted the following stats to the SPF-discuss list In <557@rama.pamho.net> "Roger Moser" writes: > In July my mail server received 309,000 spams and viruses. > 525 (0.17%) of them have not been catched by other filters but have been > catched by SPF with a 'fail' result. > 236 (0.08%) had 'softfail' and 836 (0.27%) had 'neutral'. > > My SPF cache contains 4035 SPF records. 3452 (85%) of them have "-all". > > Roger From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 18:38: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 SAA23127 for ; Thu, 5 Aug 2004 18:38: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 i75MMEn2040741; Thu, 5 Aug 2004 15:22:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75MMEuv040740; Thu, 5 Aug 2004 15:22:14 -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 i75MMDhn040733 for ; Thu, 5 Aug 2004 15:22:14 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040805222218.TFFT6357.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 5 Aug 2004 18:22:18 -0400 From: "John Glube" To: "'IETF-MXCOMP'" Cc: Subject: RE: So ... did Dewey beat Truman? Date: Thu, 5 Aug 2004 18:24:09 -0400 Message-ID: <003601c47b3a$edb63f00$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i75MMEhn040735 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I am simply forwarding this on to the lists as it did not seem to get posted. From: Carl Hutzler [mailto:cdhutzler@aol.com] Sent: August 5, 2004 9:50 AM To: ""John" "Glube""; IETF-MXCOMP Cc: spf-discuss@v2.listbox.com Subject: Re: So ... did Dewey beat Truman? I see a lot of CSV or SPF or DomainKeys or SenderID, etc. Why can we not change the "or" into an "and". From AOL's standpoint, I would like to see SPF AND CSV AND DomainKeys AND SenderID. The reason is that CSV, SenderID/SPF, and DomainKeys all provide DIFFERENT information. They do not conflict with eachother. Since they all provide different information, I would like to have access to all of the data streams when an MTA connects to me. This way I can make better decisions. -Carl On 8/5/04 12:05 AM, "John Glube" wrote: > > Oh yes, the famous headline of the Chicago Tribune when > Dewey was supposed to have beaten President Truman in the > 1948 Presidential election. > > Why that subject line? Because of this article: > > IETF Prepares to Forward Sender-ID > http://www.internetnews.com/xSP/article.php/3390221 > > The implication from the article, as a result of the author > interviewing Andy Newton, one of the co-chairs of this WG > was that Sender-ID had won and CSV had lost. > > The only thing holding things up? According to the article, > a fight going on within MS whether to insist on a license > for Sender-ID or not. > > However it seems based on quick notes released by the WG > chairs, the issue remains open. > > Why do I say this? > > * The core draft protocol (aka Sender-ID) will now be > divided into two documents, core and PRA. > > * In the meantime, MS has been given until August 23 (the > same date when last call starts) to file any IPR claims. > > * The group can start discussing CSV. > > And what about CSV? > > It might be helpful if Andy could clarify whether the > interview in the noted article is accurate, or did the > reporter mangle his remarks and draw the wrong conclusions. > > Why? Because the article leaves the impression the issue > has already been decided. > > Instead, with the split of Marid core into two documents, > core and PRA, the community could enjoy the benefit of > doing: > > * PRA checks meaning both SENDER FROM and FROM checks as > per PRA. > > * SENDER FROM, MAIL FROM or EHELO checks all as per core. > > (I appreciate some may balk at this, but bear with me.) > > With the Marid protocol (SPF) being the design used for > senders to publish DNS records, this allows people to build > a receiving authentication model around any one of these > four options depending on their needs, without prejudicing > senders. > > The benefits: > > * It leaves MS free to claim a defensive patent on PRA and > require a license should it so decide. > > If MS decides to proceed in this direction, those > developers who are happy to sign a license can do so. Those > receivers who want to do full blown PRA checks can do so. > > * It allows the open source community free to develop and > implement an authentication model around SENDER FROM, MAIL > FROM and/or EHELO FROM. Those receivers who would prefer to > focus on the transportation stage for authentication can do > so. > > * This approach does not prejudice senders since the record > published using Marid protocol (SPF) can be used to support > any authentication chosen by the receiver. > > * It allows the market to decide which approach to use > based on performance. > > * It allows testing to proceed. > > * It does not prevent ISPs and business networks from > saying in essence, don't want your mail to be automatically > rejected, then by such and such a date you must have > published an SPF record or else we will automatically > reject. As to whether it is delivered or not, depends on > our policies. > > * For marketing purposes call the whole thing Sender-ID to > expedite implementation (presuming this name is available > and not encumbered). > > One thing. I am not trying to rehash old ground, or usurp > what was discussed and agreed upon at the WG meeting. If > the approach suggested is foreclosed by what was discussed > and agreed upon, so be it. > > 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.729 / Virus Database: 484 - Release Date: 27/07/2004 > > > > -- Carl Hutzler Director, AntiSpam Operations America Online Mail Operations cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 18:47: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 SAA23820 for ; Thu, 5 Aug 2004 18:47: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 i75MbD2i041828; Thu, 5 Aug 2004 15:37: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 i75MbD8D041827; Thu, 5 Aug 2004 15:37: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 i75MbCMb041820 for ; Thu, 5 Aug 2004 15:37:12 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [130.129.131.181] ([::ffff:130.129.131.181]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 05 Aug 2004 18:37:15 -0400 id 00197673.4112B69B.00002AB7 In-Reply-To: References: <557@rama.pamho.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-mxcomp@imc.org (ietf mxcomp (e-mail)) From: Andrew Newton Subject: Re: Some statistics from the SPF-discuss list Date: Thu, 5 Aug 2004 18:37:13 -0400 To: wayne 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 Aug 5, 2004, at 6:10 PM, wayne wrote: >> >> My SPF cache contains 4035 SPF records. 3452 (85%) of them have >> "-all". My zone scans show roughly 55% -all, 36% ?all, and 7% ~all. -andy From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 20:07: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 UAA27960 for ; Thu, 5 Aug 2004 20:07: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 i75Nq1er048570; Thu, 5 Aug 2004 16:52: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 i75Nq1Qn048569; Thu, 5 Aug 2004 16:52:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Nq0MC048542 for ; Thu, 5 Aug 2004 16:52:00 -0700 (PDT) (envelope-from millenix@zemos.net) Received: from fda.zemos.net (millenix-fda.no-ip.org[68.39.78.137]) by comcast.net (rwcrmhc13) with ESMTP id <2004080523520101500945jee>; Thu, 5 Aug 2004 23:52:01 +0000 Received: from localhost (fda [127.0.0.1]) by fda.zemos.net (Postfix) with ESMTP id EB525186C4; Thu, 5 Aug 2004 19:51:58 -0400 (EDT) Received: from fda.zemos.net ([127.0.0.1]) by localhost (fda.zemos.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23610-10; Thu, 5 Aug 2004 19:51:58 -0400 (EDT) Received: from [10.0.0.2] (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id 34228186C3; Thu, 5 Aug 2004 19:51:58 -0400 (EDT) Message-ID: <4112C81E.1000903@zemos.net> Date: Thu, 05 Aug 2004 19:51:58 -0400 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040726 Debian/1.7.1-4 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Andrew Newton Cc: "ietf mxcomp (e-mail)" Subject: Re: Some statistics from the SPF-discuss list References: <557@rama.pamho.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at fda.zemos.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > My zone scans show roughly 55% -all, 36% ?all, and 7% ~all. Summing those gives 98%. Does that mean that the remainder publish +all or don't have any _all at all? Philip Miller From owner-ietf-mxcomp@mail.imc.org Thu Aug 5 22:49: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 WAA05994 for ; Thu, 5 Aug 2004 22:49: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 i762WOSm060956; Thu, 5 Aug 2004 19:32: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 i762WO7F060955; Thu, 5 Aug 2004 19:32:24 -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 i762WOKe060949 for ; Thu, 5 Aug 2004 19:32:24 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [130.129.129.58] ([::ffff:130.129.129.58]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 05 Aug 2004 22:32:28 -0400 id 00197673.4112EDBC.00003B56 In-Reply-To: <4112C81E.1000903@zemos.net> References: <557@rama.pamho.net> <4112C81E.1000903@zemos.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 mxcomp (e-mail)" From: Andrew Newton Subject: Re: Some statistics from the SPF-discuss list Date: Thu, 5 Aug 2004 22:32:23 -0400 To: Philip Miller 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 Aug 5, 2004, at 7:51 PM, Philip Miller wrote: > Summing those gives 98%. Does that mean that the remainder publish > +all or don't have any _all at all? +all -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 03:41: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 DAA09530 for ; Fri, 6 Aug 2004 03:41: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 i767LRjO033159; Fri, 6 Aug 2004 00:21:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i767LRgA033158; Fri, 6 Aug 2004 00:21:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i767LQhS033151 for ; Fri, 6 Aug 2004 00:21:26 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LDBODUP30000005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Fri, 06 Aug 2004 00:21:23 -0700 (PDT) Date: Fri, 06 Aug 2004 00:16:00 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Does marid-submitter-02 really make sense? In-reply-to: "Your message dated Thu, 05 Aug 2004 11:01:55 -0700" <20040805180155.GA3883@danisch.de> To: Hadmut Danisch Cc: ned.freed@mrochek.com, ietf-mxcomp@imc.org Message-id: <01LDBOXGHT3I00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040805164027.GA2443@danisch.de> <01LDAWC6X2SQ00005R@mauve.mrochek.com> <20040805180155.GA3883@danisch.de> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > On Thu, Aug 05, 2004 at 10:11:33AM -0700, ned.freed@mrochek.com wrote: > > > > Maybe, maybe not. Having the information early might in some MTAs allow for > > throughput optimizations. > Really? I don't see significant potential for optimizations. I see some potential for optimization. Whether or not it is significant I don't know - that would only emerge with testing, and I haven't implemented this yet, let alone tested it. I note, however, that past experience has been that the potential for optimization with various SMTP extensions has been underestimated fairly consistently. > And even if you do need this you can rely on the fact that the > message header is transmitted before the message body. If you want to > optimize nobody keeps you from evaluating the message header before > completion of the message transfer. Sure, but you can't stop the body from being transmitted in this case. > A header line will be transmitted > only very few bytes later than a SMTP extension. So not an argument. I disagree. > > You're missing cases 3 and 4: > > > > Case 3: The sender should be authorized by some domain but for whatever > > reason is not. This extension allows this condition to be detected early > > and may avoid transfer of a large message. > Not convincing. The main cases will be authorized and unauthorized. > I doesn't make sense to extend the SMTP protocol just for the case of > misconfiguration. It does not make sense to invent a protocol > extensions with major disadvantes just to prevent some bytes of > transmission in case of misconfiguration. I never said it did. > > Case 4: The sender should not be authorized and uses SUBMITTER anyway. > > (Even if you assume spammers never do this directly, which may or may > > not be true, there are cases where mail is forced through intermediaries > > that might not be prepared to do a validation check but would be able to add a > > SUBMITTER field.) This again transfer of the message body to be avoided. > > This is clearly a corner case, but it needs to be on the > > list. > I don't see that there will be a significant number of idiots sending > messages while they know that the receiver is MARID aware and will > discard the message anyway if they could do better without SUBMITTER. > Even a spammer has to pay money and time for transmission. If a > spammer sees a MARID aware MTA and knows that the message will be > discarded it is logical to go to the next victim instead of wasting > time and money. So this is not a relevant case. Which is exactly what I said it was. > > The only advantage SUBMITTER has is temporal in nature - it > > delivers the information sooner. > Not significantly sooner than a header line. Nobody forces you to wait > for completion of transmission before to look at the header. Again, this remains to be seen. > If this is the only advantage, then it is not a real advantage at > all. Why introduce a protocol extension without a real advantage? Again, I am personally ambivalent about SUBMITTER. My purpose in responding to you was to point out that (a) Your case against it really isn't that cut and dried, and (b) I am strongly opposed to the alternative header scheme you proposed. Ned From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 09:24:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25785 for ; Fri, 6 Aug 2004 09:24:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76D3Iq0020509; Fri, 6 Aug 2004 06:03: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 i76D3IS8020508; Fri, 6 Aug 2004 06:03:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76D3IMq020502 for ; Fri, 6 Aug 2004 06:03:18 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 95C4694038; Fri, 6 Aug 2004 15:03:19 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 2330994037; Fri, 6 Aug 2004 15:03:18 +0200 (CEST) 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 i76D3Evm1536290; Fri, 6 Aug 2004 15:03:18 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id B833B102C5; Fri, 6 Aug 2004 15:03:14 +0200 (CEST) Date: Fri, 6 Aug 2004 15:03:14 +0200 From: Stephane Bortzmeyer To: Hadmut Danisch Cc: Meng Weng Wong , ietf-mxcomp@imc.org Subject: Re: marid-submitter-02: Recipient's point of view Message-ID: <20040806130314.GB5761@nic.fr> References: <20040805170554.GA2869@danisch.de> <20040805172818.GD28401@dumbo.pobox.com> <20040805174909.GA3352@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040805174909.GA3352@danisch.de> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 05, 2004 at 10:49:09AM -0700, Hadmut Danisch wrote a message of 35 lines which said: > How does the information find it's way to the MUA? The SUBMITTER is > not an RFC2822 information. Were does it find it's place in a > standard Unix mbox file without changing the mbox file format? They way I understand draft-ietf-marid-submitter-02, it is the opposite. The SMTP client must derive the submitter from the 2822-headers (see 4.2 "Processing the SUBMITTER Parameter" and 4.3). So, there is no need to send SUBMITTER back into 2822-headers (just a check, described in 4.3). > How should a MUA be able to display an information as long as there > is no defined way how the MTA should pass the information to the > MUA? See above. For instance, I quote draft-ietf-marid-submitter-02, 4.3 : This should involve no information loss, since the SUBMITTER parameter is required to contain information derived from the message headers. From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 09:26: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 JAA25859 for ; Fri, 6 Aug 2004 09:26: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 i76Cw6ce020038; Fri, 6 Aug 2004 05:58: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 i76Cw6PY020037; Fri, 6 Aug 2004 05:58:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76CvvMA020024 for ; Fri, 6 Aug 2004 05:58:05 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 119599400B; Fri, 6 Aug 2004 14:57:59 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 9E42494029; Fri, 6 Aug 2004 14:57:57 +0200 (CEST) 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 i76Cvvvm1542063; Fri, 6 Aug 2004 14:57:57 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 24978102C5; Fri, 6 Aug 2004 14:57:57 +0200 (CEST) Date: Fri, 6 Aug 2004 14:57:57 +0200 From: Stephane Bortzmeyer To: Alan DeKok Cc: ietf-mxcomp@imc.org Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) Message-ID: <20040806125757.GA5761@nic.fr> References: <20040804204825.GA2551@nic.fr> <20040805161137.C46DB17109@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040805161137.C46DB17109@mail.nitros9.org> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 05, 2004 at 12:11:37PM -0400, Alan DeKok wrote a message of 36 lines which said: > I am saying that we know a-priori, that giving positive marks to > messages which pass SPF checks is not a good idea. Such analysis are always dangerous ("We all know that spams are in text/html only") and this is exactly why SpamAssassin switched to an automatically-generated list of scores. It leaves less room to personal opinions. > And if, as we've seen, spammers publish lots of MARID records, then > there's a non-zero chance that a neural net may decide there's a > correlation between spam & MARID records, which means MARID won't be > as useful for everyone else. If the neural net decides so, fine with me. It's exactly for a similar reason that SpamAssassin decided that "This mail is not spam" was a good marker for spams... From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 09:46: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 JAA26691 for ; Fri, 6 Aug 2004 09: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 i76DTYDo022559; Fri, 6 Aug 2004 06:29: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 i76DTYGR022557; Fri, 6 Aug 2004 06:29: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 i76DTVgR022545 for ; Fri, 6 Aug 2004 06:29: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 D89BD132CD1; Fri, 6 Aug 2004 09:32:05 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 7D32C633; Fri, 6 Aug 2004 09:29:30 -0400 (EDT) Date: Fri, 6 Aug 2004 09:29:30 -0400 From: Meng Weng Wong To: Stephane Bortzmeyer Cc: ietf-mxcomp@imc.org Subject: SUBMITTER and PRA Message-ID: <20040806132930.GA3243@dumbo.pobox.com> References: <20040805170554.GA2869@danisch.de> <20040805172818.GD28401@dumbo.pobox.com> <20040805174909.GA3352@danisch.de> <20040806130314.GB5761@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040806130314.GB5761@nic.fr> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 06, 2004 at 03:03:14PM +0200, Stephane Bortzmeyer wrote: | On Thu, Aug 05, 2004 at 10:49:09AM -0700, | Hadmut Danisch wrote | a message of 35 lines which said: | | > How does the information find it's way to the MUA? The SUBMITTER is | > not an RFC2822 information. Were does it find it's place in a | > standard Unix mbox file without changing the mbox file format? | | They way I understand draft-ietf-marid-submitter-02, it is the | opposite. The SMTP client must derive the submitter from the | 2822-headers (see 4.2 "Processing the SUBMITTER Parameter" and | 4.3). So, there is no need to send SUBMITTER back into 2822-headers | (just a check, described in 4.3). I want to comment on how the phrasing above frames the relatioship between PRA and SUBMITTER. Alan Kay said: The best way to predict the future is to invent it. In the same way, sometimes the best way to "derive the submitter from the 2822-headers" is to assign it. If you have a given block of headers, you can derive the PRA by examining the headers according to the algorithm described in core (now moving to a separate document). But you can also cheat. You can simply prepend a Resent-Sender or Resent-From header to the existing block. Because you know what you prepended, you can assign that value directly to the PRA variable. That way you don't need to look at the existing block of headers at all. SUBMITTER and PRA are synonyms. In the above paragraph, who is "you"? The current thinking represented by the current drafts says "you" is the SMTP client. Niels Bohr said: The opposite of every great idea is another great idea. Suppose we turn things around and set "you" to be the SMTP server. It is possible to construct an equivalent operation in which the SMTP sender system *does not* prepend a PRA to the headers, but instead only assigns SUBMITTER. In that world, the SMTP *receiver* system is responsible for taking the given SUBMITTER value and prepending it to the headers as a Resent-* field. SMTP receivers already do this --- "MAIL FROM" turns into the Return-Path, so why shouldn't "SUBMITTER" turn into Resent-From? It is not a technical challenge. If the algorithm by which PRA is derived from the headers turns out to be encumbered, the above workaround offers all the functionality of the PRA/SUBMITTER system but without the heartache. It is, as it were, an independent implementation, written without reading the original source code, that offers the same feature set. From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 10:00: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 JAA27338 for ; Fri, 6 Aug 2004 09:59: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 i76DlNuh023811; Fri, 6 Aug 2004 06: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 i76DlNEJ023810; Fri, 6 Aug 2004 06:47:23 -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 i76DlK8s023801 for ; Fri, 6 Aug 2004 06:47:20 -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 76ECC132CD1; Fri, 6 Aug 2004 09:49:57 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 0AFB8633; Fri, 6 Aug 2004 09:47:22 -0400 (EDT) Date: Fri, 6 Aug 2004 09:47:22 -0400 From: Meng Weng Wong To: Frank Ellermann Cc: ietf-mxcomp@imc.org Subject: "unified spf" Message-ID: <20040806134722.GE28401@dumbo.pobox.com> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us> <3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> <4110E7CC.5796@xyzzy.claranet.de> <4111F07F.5049@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4111F07F.5049@xyzzy.claranet.de> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 05, 2004 at 10:31:59AM +0200, Frank Ellermann wrote: | | This _and_ is very important. Maybe we should mention it in | SPF/PRA resp. SPF/FROM, these tests make no sense without a | prior SPF/MAILFROM test. The important thing is SPF/MAILFROM, | and at the moment we have no draft for SPF/MAILFROM (= the old | draft-mengwong-spf-01.txt minus all stuff now covered by MARID | protocol-00.txt). | Actually, we do. There is a set of drafts out there that collectively describe the "unified" model. They have not been published to the list for fear of distraction; given the tight time constraints, it seems prudent to focus on getting Sender ID off the ground before opening the door to more theoretical discussion. But I will mention them for the record, and because there has been some interest in the past in defining the term "Unified SPF". At the WG meeting, some folks suggested we should extract the PRA algorithm from the core document because it has general utility in the 2822 space independent of MARID work. That refactoring represents a step in the direction of the unified drafts. The "unified" document describes the overall structure. The "protocol" document describes the SPF test. "ptr", "helo", "mailfrom", and "pra" describe the semantics of the SPF test in the context of each identity. "best" shows how the four instances interact. The documents at http://spf.pobox.com/unified/id/ are a rough draft. They represent only my take (together with Mark) on another way to present Sender ID. I have no plans to submit them as I-Ds. They have informational value at best. I hope they are a constructive contribution. From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 11:23: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 LAA04335 for ; Fri, 6 Aug 2004 11:23: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 i76F2WDk029836; Fri, 6 Aug 2004 08:02: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 i76F2WxG029835; Fri, 6 Aug 2004 08:02:32 -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 i76F2TKd029823 for ; Fri, 6 Aug 2004 08:02:31 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 5659A16E1F for ; Fri, 6 Aug 2004 11:10:36 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Interaction with anti-spam systems (was Re: A spammer subscribed to this list ? ) In-Reply-To: Your message of "Fri, 06 Aug 2004 14:57:57 +0200." <20040806125757.GA5761@nic.fr> Date: Fri, 06 Aug 2004 11:10:36 -0400 Message-Id: <20040806151036.5659A16E1F@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephane Bortzmeyer wrote: > Such analysis are always dangerous ("We all know that spams are in > text/html only") That's not a good analogy. We *know* SPF_PASS says nothing about whether a message is spam or not. We *know* SPF_FAIl says that the domain publishing SPF has not authorized the message. > > there's a non-zero chance that a neural net may decide there's a > > correlation between spam & MARID records, which means MARID won't be > > as useful for everyone else. > > If the neural net decides so, fine with me. Assigning negative spamassassin scores to SPF_PASS means that spammers can benefit from using SPF. Assigning positive spamassassin scores to SPF_PASS means that non-spam will get punished for using SPF. We want neither to happen, therefore anti-spam systems should assign no benefit, and no penalty, for publishing MARID-style records. If you want to allow neural-net systems to assign scores, then you're OK with either, or both, of the two scenarios from the preceding paragraph. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 11:30: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 LAA04648 for ; Fri, 6 Aug 2004 11:30: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 i76F4vbl030010; Fri, 6 Aug 2004 08:04: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 i76F4vu9030009; Fri, 6 Aug 2004 08:04:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76F4ukv030002 for ; Fri, 6 Aug 2004 08:04:56 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id BC0D694012; Fri, 6 Aug 2004 17:04:58 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 5D0A294004; Fri, 6 Aug 2004 17:04:57 +0200 (CEST) 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 i76F4vvm1050189; Fri, 6 Aug 2004 17:04:57 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 0233B102C5; Fri, 6 Aug 2004 17:04:56 +0200 (CEST) Date: Fri, 6 Aug 2004 17:04:56 +0200 From: Stephane Bortzmeyer To: Meng Weng Wong Cc: Stephane Bortzmeyer , ietf-mxcomp@imc.org Subject: Re: SUBMITTER and PRA Message-ID: <20040806150456.GA16760@nic.fr> References: <20040805170554.GA2869@danisch.de> <20040805172818.GD28401@dumbo.pobox.com> <20040805174909.GA3352@danisch.de> <20040806130314.GB5761@nic.fr> <20040806132930.GA3243@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040806132930.GA3243@dumbo.pobox.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 06, 2004 at 09:29:30AM -0400, Meng Weng Wong wrote a message of 61 lines which said: > In the same way, sometimes the best way to "derive the submitter > from the 2822-headers" is to assign it. Isn't it a violation of the current protocol: 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." ? From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 11:31: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 LAA04734 for ; Fri, 6 Aug 2004 11:31: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 i76FI8qj032199; Fri, 6 Aug 2004 08:18: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 i76FI81k032198; Fri, 6 Aug 2004 08:18:08 -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 i76FI5E5032188 for ; Fri, 6 Aug 2004 08:18:08 -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 3ED1B132CD1; Fri, 6 Aug 2004 11:20:43 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id F198F6A4; Fri, 6 Aug 2004 11:18:06 -0400 (EDT) Date: Fri, 6 Aug 2004 11:18:06 -0400 From: Meng Weng Wong To: Stephane Bortzmeyer Cc: Meng Weng Wong , ietf-mxcomp@imc.org Subject: Re: SUBMITTER and PRA Message-ID: <20040806151806.GC3243@dumbo.pobox.com> References: <20040805170554.GA2869@danisch.de> <20040805172818.GD28401@dumbo.pobox.com> <20040805174909.GA3352@danisch.de> <20040806130314.GB5761@nic.fr> <20040806132930.GA3243@dumbo.pobox.com> <20040806150456.GA16760@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040806150456.GA16760@nic.fr> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 06, 2004 at 05:04:56PM +0200, Stephane Bortzmeyer wrote: | | Isn't it a violation of the current protocol: | If by "violation" you mean "one possible suggested alternative to", then yes. From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 12:23:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07947 for ; Fri, 6 Aug 2004 12:23:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76Fv6dC034456; Fri, 6 Aug 2004 08:57: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 i76Fv6b0034455; Fri, 6 Aug 2004 08:57: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 i76Fv5mJ034447 for ; Fri, 6 Aug 2004 08:57:05 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i76Fv0vl015370 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 6 Aug 2004 11:57:03 -0400 Date: Fri, 6 Aug 2004 11:57:00 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "william(at)elan.net" cc: "Hallam-Baker, Phillip" , IETF MARID WG Subject: RE: How is SPF different from RMX? 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: Yes, William and I frequently disagree. The subsequent history of these disagreements has proven me right and William wrong in nearly every case. Frequently, the commonly held beliefs aren't true. In consequence, I don't uncritically accept that what someone else claims is true. I analyze their claims. And my record on anti-spam claims is pretty good. In fact, on nearly all (maybe all) of the mistakes by Anti-spammers, I correctly analyzed it and found it to be foolhardy when it was __proposed__. Subsequent experiences with those mistakes bore out my analysis: They worked or failed to work more or less as I expected. And this goes all the way back to the diconnection of Sanford Wallace and the collapse of the IEMCC. So, while William tries weakly to launch an ad-hominem attack, the truth is that my credibility is enhanced by having a history of having been proven right with regard to past stupid ideas proposed and executed by anti-spammers. --Dean On Tue, 3 Aug 2004, william(at)elan.net wrote: > > > On Tue, 3 Aug 2004, Dean Anderson wrote: > > > My apologies. Everyting that is obvious to me isn't obvious to everyone. > > I suspect many here who are not subscribed to main and some other ietf > lists can't imagine how much this sentence is applicable in reverse > (replace "is" with "isnt" and other way around) to many of the posts > I've seen from Dean Anderson. > > Sorry for OT and of course "My apologies" > > P.S. For the future lets not use "everything" and "obvious" in statements > or even just in same sentence. There would not be so many discussions > on this list if everything was so obvious :) > > --- > William Leibzon > Elan Networks > william@elan.net > > From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 12:46: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 MAA09243 for ; Fri, 6 Aug 2004 12:46: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 i76GRKlw037182; Fri, 6 Aug 2004 09: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 i76GRK1j037181; Fri, 6 Aug 2004 09:27:20 -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 i76GRBri037170 for ; Fri, 6 Aug 2004 09:27:11 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i76GR7pv009161; Fri, 6 Aug 2004 18:27:07 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i76GPibp002306; Fri, 6 Aug 2004 18:25:44 +0200 From: Hadmut Danisch Date: Fri, 6 Aug 2004 09:25:44 -0700 To: Stephane Bortzmeyer Cc: Meng Weng Wong , ietf-mxcomp@imc.org Subject: Re: marid-submitter-02: Recipient's point of view Message-ID: <20040806162543.GA2154@danisch.de> References: <20040805170554.GA2869@danisch.de> <20040805172818.GD28401@dumbo.pobox.com> <20040805174909.GA3352@danisch.de> <20040806130314.GB5761@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040806130314.GB5761@nic.fr> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 06, 2004 at 03:03:14PM +0200, Stephane Bortzmeyer wrote: > > They way I understand draft-ietf-marid-submitter-02, it is the > opposite. The SMTP client must derive the submitter from the > 2822-headers (see 4.2 "Processing the SUBMITTER Parameter" and > 4.3). So, there is no need to send SUBMITTER back into 2822-headers > (just a check, described in 4.3). > ... > See above. For instance, I quote draft-ietf-marid-submitter-02, 4.3 : > > This should involve no information loss, since the SUBMITTER parameter > is required to contain information derived from the message headers. HELLLOOOO. Wake Up! We are not playing card games here. *** This is about _security_! *** We try to defend against attackers here. Spammers, cheaters, criminals. What makes you think that they will comply to this requirement? Expecting the sender to behave well and to provide redundant information consistently is naive and opening the door to attacks. May I ask who in this working group has experience in designing security protocols? Hadmut From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 12:54: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 MAA09842 for ; Fri, 6 Aug 2004 12:54: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 i76GaTjJ037913; Fri, 6 Aug 2004 09:36: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 i76GaT82037912; Fri, 6 Aug 2004 09:36:29 -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 i76GaSe9037906 for ; Fri, 6 Aug 2004 09:36:28 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [130.129.136.122] ([::ffff:130.129.136.122]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 06 Aug 2004 12:36:29 -0400 id 00197682.4113B38D.000012B3 Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: testing of MARID proposals Date: Fri, 6 Aug 2004 12:36:28 -0400 To: "ietf mxcomp \"(e-mail)" 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 At IETF 60, I was approached by a very large ISP willing to do some testing of the MARID proposals (Sender ID & CSV). They have asked for advice on testing, so I thought I'd ask the experts (you!). Quite simply, they are seeking advice on the variables to measure and guidelines for deployment and evaluation of such tests. Their hope is that they will be able to come back to the MARID working group with a report on what they have found. So, your advice is welcome. But I do ask one favor: please do not formulate any such advice in the form of Sender ID vs CSV. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 13:30: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 NAA12425 for ; Fri, 6 Aug 2004 13:30: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 i76H4ZpZ039678; Fri, 6 Aug 2004 10:04: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 i76H4ZVW039677; Fri, 6 Aug 2004 10:04:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org ([168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76H4Zns039612 for ; Fri, 6 Aug 2004 10:04:35 -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 6BF34414BA; Fri, 6 Aug 2004 10:04:08 -0700 (PDT) Received: from 130.129.130.242 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Fri, 6 Aug 2004 10:04:08 -0700 (PDT) Message-ID: <3058.130.129.130.242.1091811848.squirrel@harry.mail-abuse.org> In-Reply-To: <20040806130314.GB5761@nic.fr> References: <20040805170554.GA2869@danisch.de> <20040805172818.GD28401@dumbo.pobox.com> <20040805174909.GA3352@danisch.de> <20040806130314.GB5761@nic.fr> Date: Fri, 6 Aug 2004 10:04:08 -0700 (PDT) Subject: Re: marid-submitter-02: Recipient's point of view From: "Douglas Otis" To: "Stephane Bortzmeyer" Cc: "Hadmut Danisch" , "Meng Weng Wong" , 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 > > On Thu, Aug 05, 2004 at 10:49:09AM -0700, > Hadmut Danisch wrote > a message of 35 lines which said: > >> How does the information find it's way to the MUA? The SUBMITTER is >> not an RFC2822 information. Were does it find it's place in a >> standard Unix mbox file without changing the mbox file format? > > They way I understand draft-ietf-marid-submitter-02, it is the > opposite. The SMTP client must derive the submitter from the > 2822-headers (see 4.2 "Processing the SUBMITTER Parameter" and > 4.3). So, there is no need to send SUBMITTER back into 2822-headers > (just a check, described in 4.3). Misreading the draft as to the significance of Submitter is a reason for not introducing this field. A Should must be a Must check. The general goal was to protect the RFC 2822 headers. To neglect checking RFC 2822 headers would remove this protection without any record of this lapse. >> How should a MUA be able to display an information as long as there >> is no defined way how the MTA should pass the information to the >> MUA? > > See above. For instance, I quote draft-ietf-marid-submitter-02, 4.3 : > > This should involve no information loss, since the SUBMITTER parameter > is required to contain information derived from the message headers. The claimed optimization depends upon a spammer being behind the curve. The receiving MTA must check both the Submitter and RFC 2822 headers, but Submitter may allow this header check to be skipped. Do not expect Submitter parameters to fail acceptance to any degree, once its use becomes prevalent. Submitter acceptance can be accomplished any number of ways, many without requiring an administrative relationship to various DNS records. I would not expect any optimization likely, but rather an added security flaw is created. There is also the opportunity for differences in the PRA checks between two systems to then force rejection of messages. The errors may provide clues, but could become a mysterious problem, as what is being asserted is not recorded. Going down this path seems to be based upon an assumption spammers will be thwarted by this check. It is more likely this check will benefit spammers and make support more difficult. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 13:46: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 NAA13420 for ; Fri, 6 Aug 2004 13:46: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 i76HTGNm042449; Fri, 6 Aug 2004 10:29: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 i76HTGne042448; Fri, 6 Aug 2004 10:29:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76HTFfv042439 for ; Fri, 6 Aug 2004 10:29:15 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i76HTBXH010644; Fri, 6 Aug 2004 19:29:11 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i76HStWe003164; Fri, 6 Aug 2004 19:28:55 +0200 From: Hadmut Danisch Date: Fri, 6 Aug 2004 10:28:55 -0700 To: Andrew Newton Cc: "ietf mxcomp (e-mail)" Subject: Re: testing of MARID proposals Message-ID: <20040806172855.GA3019@danisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 06, 2004 at 12:36:28PM -0400, Andrew Newton wrote: > > At IETF 60, I was approached by a very large ISP willing to do some > testing of the MARID proposals (Sender ID & CSV). They have asked for > advice on testing, so I thought I'd ask the experts (you!). What kind of ISP? Hoster of large number of domains? Or many users within a single domain? An important test would be the definition of MARID records. Where do these records come from? Give every customer a default record which should work for most of them and allow them to modify? Or let users start from scratch? Is the average user able to understand what's going on? What kind of user interface? How much load does this mean for the hotline people required to help users? How long does the average user need to have a correct record and how many tries? How many 'good' mails are lost until so? How frequently does the average user change the record after he had a working one for the first time? Is the average user able to understand this at least in principle? What impact does it have on mail delivery? Do users prefer to cover their own machines with the record or do they deliver through the ISP's machines? What's the average length of the MARID record? How many replies do not fit into a UDP DNS result? Are MARID records an invitation for attacks? Are machines mentioned in MARID records under higher attack than others? How does the load of the DNS servers increase? Do they need faster processors, more memory, more bandwidth? And again: Fox6 News reported that policy departments are launching special task forces against phishing. It would be good to get into contact with them to find out whether they do know anything about fraudulent attacks what we don't know yet but need to take into consideration. Hadmut From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 14:00:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14303 for ; Fri, 6 Aug 2004 14: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 i76Hitxk044270; Fri, 6 Aug 2004 10:44: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 i76HitGa044269; Fri, 6 Aug 2004 10:44:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76HisBe044262 for ; Fri, 6 Aug 2004 10:44:54 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1Bt8lr-0001Er-8q for ietf-mxcomp@imc.org; Fri, 06 Aug 2004 12:44:57 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Fri, 06 Aug 2004 12:44:47 -0500 In-Reply-To: (Andrew Newton's message of "Fri, 6 Aug 2004 12:36:28 -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: testing of MARID proposals Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.9 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE, NO_EXPERIENCE autolearn=no version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Andrew Newton writes: > At IETF 60, I was approached by a very large ISP willing to do some > testing of the MARID proposals (Sender ID & CSV). Great! > Quite simply, they are seeking advice on the variables to measure and > guidelines for deployment and evaluation of such tests. For Sender ID, the stuff that Mark Lentczner reported was quite useful. Or, at least, I found the detailed reports to be useful. My analysis of the data and why various parts are important can be found at: http://www.imc.org/ietf-mxcomp/mail-archive/msg02776.html Mark wrote a perl script to generate this data, but it makes the assumption that there are no post-edge MTA relays, which is not true for my mail boxes nor for the Spamassassin corpus. I'm fiddling with Mark's script to see if I can get good data from either source. > So, your advice is welcome. But I do ask one favor: please do not > formulate any such advice in the form of Sender ID vs CSV. I suspect that only SPF-classic has enough published domains to do any real testing on. Currently, Sender ID makes the assumption that v=spf1 records are valid to be used for Sender ID checks. While I personally agree that this asumption is almost always true, it was decided at the IETF-60 session that this was not a safe assumption. One useful thing to test for is whether this assumption is really true or not. Personally, I think it would be very useful to also test the SPF-classic results for both the MAIL FROM and the HELO. As far as CSV testing, my understanding is that few domains have published the SRV records needed to test it. I suspect that people more knowledgable about CSV deployment may be needed to develop useful tests. A couple of days ago, I went through my inbox to see how many valid emails I have received that had HELO domains that did not resolve to the IP address of the client MTA. I never finished going through the list or giving a real report, but I thought the following list was interesting none the less. [192.74.137.143] helo=TheWorld.com Maybe if this "Barry Shein" guy had more experience running a public ISP, he wouldn't have his HELO domain wrong. [205.143.207.126] helo=hera.prod.geico.com Yeah, no one would mind losing email from GEICO. [66.35.250.206] helo=sc8-sf-mx2.sourceforge.net These guys have no idea about creating and using software. [128.242.147.150] (helo=nu.jumpserver.net) this is the registrar/DNS hoster that I've used since the mid 90s. [206.222.212.237] helo=midwestcs.com The guy is an idiot. [216.145.52.229] helo=yahoo-inc.com Small, two-bit company with no experience with email and they haven't been around very long anyway. [206.45.235.30] helo=mail.pan-am.ca This guy obviously has no clue about designated sender systems and what needs to be done to make them work reliably. (I thought I had sendmail.com for a sec, but it is just their forward and reverse not matching.) [216.239.56.194] helo=cwar25.prod.google.com Yeah, another two-bit company that has nothing to do with email. [208.198.98.24] helo=CORPMAIL1.roving.com What can I say? Email is not their thing. Mind you, these were emails to my person-to-person inbox, not stuff from mailing lists, so the volume is fairly low and fairly restricted. I think the above list represents about half of the MTAs that used invalid HELO domains. Overall, I found that around 20% of all valid, person-to-person email I received had an invalid HELO domain. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 14:32: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 OAA15969 for ; Fri, 6 Aug 2004 14:32:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76IDQta046299; Fri, 6 Aug 2004 11:13:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i76IDQkf046298; Fri, 6 Aug 2004 11:13:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from 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 i76IDPYs046253 for ; Fri, 6 Aug 2004 11:13:25 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: testing of MARID proposals Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 6 Aug 2004 13:13:26 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA93E@srv1.pan-am.ca> Thread-Topic: testing of MARID proposals Thread-Index: AcR71ty+D1ztaCg/SiSEm+WSgBRwIwACEW1w 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 i76IDPYs046293 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Quite simply, they are seeking advice on the variables to measure and > guidelines for deployment and evaluation of such tests. The big concern brought up to me was that the bandwidth used by these checks could be more than the bandwidth saved by refusing unwanted mail. So I would look for these data: * Total SMTP traffic in bytes, or bytes/second, or bytes/message * Total MARID traffic in bytes, or bytes/second, or bytes/message Some things can't be measured directly, such as the traffic between DNS servers as names get resolved and forwarders do their jobs, but it is possible to measure one's own DNS traffic. If possible, I would try to receive all SMTP traffic anyway, so one could accurately determine any bandwidth saved if a MARID query resulted in a refusal. I've been told a break-even scenario would be acceptable, barely, because of the more visible effect of less mail. But I think our chances of considerable savings (like 20% or more after MARID overhead) are good. If doing checks after the entire message is received, you'll want to measure CPU usage, both analyzing and waiting for disk access, or processing a check. My prior impression was that network speeds were orders of magnitude slower than CPU and disk speeds, so they didn't make a difference. After reading these documents however, I would pay more attention to them. I'm sure we could get a proper feel for that by running MARID on a Pentium 133 running NT 4.0 and the old EMWAC IMS mail server, for instance.[1] [1] Don't laugh. They're already writing MARID plugins at ims-users@rockliffe.com. And I used to host a 2500-user mail server on that kind of machine very comfortably. If you want to impress me, run MARID with low overhead on that kind of machine. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 14:42: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 OAA16470 for ; Fri, 6 Aug 2004 14:42: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 i76IOnX0047648; Fri, 6 Aug 2004 11:24: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 i76IOn3q047647; Fri, 6 Aug 2004 11:24:49 -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 i76IOnjv047640 for ; Fri, 6 Aug 2004 11:24:49 -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 2669E4149B for ; Fri, 6 Aug 2004 11:24:51 -0700 (PDT) Received: from 130.129.130.242 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Fri, 6 Aug 2004 11:24:51 -0700 (PDT) Message-ID: <3099.130.129.130.242.1091816691.squirrel@harry.mail-abuse.org> In-Reply-To: References: Date: Fri, 6 Aug 2004 11:24:51 -0700 (PDT) Subject: Re: testing of MARID proposals From: "Douglas Otis" To: "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 > > In Andrew Newton > writes: > >> At IETF 60, I was approached by a very large ISP willing to do some >> testing of the MARID proposals (Sender ID & CSV). > > Great! > ... > As far as CSV testing, my understanding is that few domains have > published the SRV records needed to test it. I suspect that people > more knowledgable about CSV deployment may be needed to develop useful > tests. > > > > A couple of days ago, I went through my inbox to see how many valid > emails I have received that had HELO domains that did not resolve to > the IP address of the client MTA. I never finished going through the > list or giving a real report, but I thought the following list was > interesting none the less. > > > [192.74.137.143] helo=TheWorld.com > Maybe if this "Barry Shein" guy had more experience running a > public ISP, he wouldn't have his HELO domain wrong. > > [205.143.207.126] helo=hera.prod.geico.com > Yeah, no one would mind losing email from GEICO. > > [66.35.250.206] helo=sc8-sf-mx2.sourceforge.net > These guys have no idea about creating and using software. > > [128.242.147.150] (helo=nu.jumpserver.net) > this is the registrar/DNS hoster that I've used since the mid 90s. > > [206.222.212.237] helo=midwestcs.com > The guy is an idiot. > > [216.145.52.229] helo=yahoo-inc.com > Small, two-bit company with no experience with email and they > haven't been around very long anyway. > > [206.45.235.30] helo=mail.pan-am.ca > This guy obviously has no clue about designated sender systems and > what needs to be done to make them work reliably. > > (I thought I had sendmail.com for a sec, but it is just their forward > and reverse not matching.) > > [216.239.56.194] helo=cwar25.prod.google.com > Yeah, another two-bit company that has nothing to do with email. > > [208.198.98.24] helo=CORPMAIL1.roving.com > What can I say? Email is not their thing. > > > > > Mind you, these were emails to my person-to-person inbox, not stuff > from mailing lists, so the volume is fairly low and fairly restricted. > I think the above list represents about half of the MTAs that used > invalid HELO domains. Overall, I found that around 20% of all > valid, person-to-person email I received had an invalid HELO domain. > It should be expect that those that do publish the CSV-CSA record will ensure the host name of their outbound MTAs are accurately reflected in the EHLO domain reported. Until then, all bets are off. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 15:47: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 PAA21247 for ; Fri, 6 Aug 2004 15:47: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 i76JPLlw053886; Fri, 6 Aug 2004 12:25: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 i76JPLM7053885; Fri, 6 Aug 2004 12:25:21 -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 i76JPIwg053877 for ; Fri, 6 Aug 2004 12:25:20 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Subject: The real reason MARID won't work, RE: testing of MARID proposals Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 6 Aug 2004 14:25:22 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA940@srv1.pan-am.ca> Thread-Topic: testing of MARID proposals Thread-Index: AcR74BYB2cLqhtr5QzSEo3BNQkZxrgABrp7Q From: "Gordon Fecyk" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i76JPKwg053880 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > [206.45.235.30] helo=mail.pan-am.ca > This guy obviously has no clue about designated sender systems and > what needs to be done to make them work reliably. Lovely. So the author of DMP doesn't have a clue about his own system, or about changing his own records when he changes IP addresses. :-) :-) Excuse me while I go laugh at myself. *ahem* Ahh where was I? Oh yes: The real reason MARID won't work is exactly because of this sort of nonsense. Lazy or forgetful admins who don't change their designation records to match any server changes. Oh sure we've all done such goofy things before, like delegating a reverse DNS server by IP address instead of by name and wondering why a website loads so slowly as the web server tries to resolve .3 [1] and such. And this probably would've come to light much sooner had any other people bothered bouncing mail due to an incorrect record. But because so few people bother checking these things and even then don't bother to bounce mail because they think it's unreliable to do so, mistakes like that will go overlooked for years after MARID's official publication as an Internet Standard. And then folks will use even more proprietary stuff like DomainKeys, Skeptic and such. At least those willing to pay the price. And then archaeologists excavating an old burial site will discover draft-ietf-marid-x on a scratched but barely readable CD (provided their DRM-enforced computers will let them read it), along with some other forgotten tomes with long forbidden words such as "Stallman," "Torvalds," and "Tux." Along with an old hard drive crammed with spam. Their discovery will be filed away with the Ark of the Covenant and other such artifacts. Seriously, I can laugh at myself now, but I guess this highlights a need for automated tools to simplify managing this stuff. I'm sure Meng will jump in with: "If you used spf with mx you wouldn't have this problem" any time soon. But then we have the whole excessive DNS traffic problem again. [1] I didn't do that, I swear! I had to LART an upstream ISP who did that to me in 1998. "iStink Internet," as I liked to call them, fortunately died out a year later. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 16:23:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23453 for ; Fri, 6 Aug 2004 16:23: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 i76K6gva057151; Fri, 6 Aug 2004 13:06: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 i76K6gsw057150; Fri, 6 Aug 2004 13:06:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76K68Vw057091 for ; Fri, 6 Aug 2004 13:06:41 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id CD4EF9403A; Fri, 6 Aug 2004 22:06:12 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 6ED7094004; Fri, 6 Aug 2004 22:06:11 +0200 (CEST) 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 i76K6Bvm1093471; Fri, 6 Aug 2004 22:06:11 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 46CF9102C5; Fri, 6 Aug 2004 22:06:11 +0200 (CEST) Date: Fri, 6 Aug 2004 22:06:11 +0200 From: Stephane Bortzmeyer To: Hadmut Danisch Cc: Stephane Bortzmeyer , Meng Weng Wong , ietf-mxcomp@imc.org Subject: Re: marid-submitter-02: Recipient's point of view Message-ID: <20040806200611.GC1882@nic.fr> References: <20040805170554.GA2869@danisch.de> <20040805172818.GD28401@dumbo.pobox.com> <20040805174909.GA3352@danisch.de> <20040806130314.GB5761@nic.fr> <20040806162543.GA2154@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040806162543.GA2154@danisch.de> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 06, 2004 at 09:25:44AM -0700, Hadmut Danisch wrote a message of 30 lines which said: > HELLLOOOO. Wake Up! Not at this time of the day. > May I ask who in this working group has experience in designing > security protocols? Not me. Now, what's the security problem? The draft says that the *client* SMTP must derive SUBMITTER from the 2822 headers and that the *server* SMTP should check that they still match. Besides a lazy server which understands SHOULD as "if you please", can you present a scenario where SUBMITTER fails, because the bad guy forged the 2822 headers (something which is easy to do, we know it, no need to be a security expert)? From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 16:25:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23584 for ; Fri, 6 Aug 2004 16:25:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76KAcw8057367; Fri, 6 Aug 2004 13: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 i76KAcJx057366; Fri, 6 Aug 2004 13:10:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76KAbZD057360 for ; Fri, 6 Aug 2004 13:10:38 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 1A27B94004; Fri, 6 Aug 2004 22:10:42 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id B11BB94012; Fri, 6 Aug 2004 22:10:40 +0200 (CEST) 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 i76KAevm1094560; Fri, 6 Aug 2004 22:10:40 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 962A5102C5; Fri, 6 Aug 2004 22:10:40 +0200 (CEST) Date: Fri, 6 Aug 2004 22:10:40 +0200 From: Stephane Bortzmeyer To: Andrew Newton Cc: "ietf mxcomp (e-mail)" Subject: Re: testing of MARID proposals Message-ID: <20040806201040.GD1882@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 06, 2004 at 12:36:28PM -0400, Andrew Newton wrote a message of 15 lines which said: > At IETF 60, I was approached by a very large ISP willing to do some > testing of the MARID proposals (Sender ID & CSV). They have asked > for advice on testing, so I thought I'd ask the experts (you!). I agree with wayne here. There is not enough Sender-ID or CSV deployment to do a real testing. Your ISP would have to write its own software to test what? Non-existing Sender-ID records... Also, spammers only react when the threat (to them) is sufficient. Spammers/phisers did not start yet to adapat to LMAP protocols because they are not deployed enough. A technical experiment could be interesting but the real experiment will be the social one and it can only be done in real, once MARID is common. > So, your advice is welcome. Install SPF in test mode for several months on a real server and report the results (how many legitimate mails would have been bounced, how many spams got through, increase of the DNS traffic, etc). At least, it would yield interesting results. From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 17:22: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 RAA25970 for ; Fri, 6 Aug 2004 17:22: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 i76L5RYg061808; Fri, 6 Aug 2004 14:05: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 i76L5Rs1061807; Fri, 6 Aug 2004 14:05:27 -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 i76L5QSP061801 for ; Fri, 6 Aug 2004 14:05:26 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040806210517.KCQU28143.tomts25-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 6 Aug 2004 17:05:17 -0400 From: "John Glube" To: "'Andrew Newton'" , "'ietf mxcomp \"\(e-mail\)'" Subject: milestones for CSV Date: Fri, 6 Aug 2004 17:07:05 -0400 Message-ID: <006701c47bf9$540b33f0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i76L5QSP061802 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Andy, The last item on the agenda for the MARID meeting was to formulate milestones for CSV. Were these settled? If so, may we have these milestones sent to the list? Thanks, John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 18:30: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 SAA00487 for ; Fri, 6 Aug 2004 18:30:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76M81DC068039; Fri, 6 Aug 2004 15:08: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 i76M81R2068038; Fri, 6 Aug 2004 15:08:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76M803P068028 for ; Fri, 6 Aug 2004 15:08:00 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: The real reason MARID won't work, RE: testing of MARID proposals Date: Fri, 6 Aug 2004 17:07:58 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02B04097@cliff.bai.org> Thread-Topic: The real reason MARID won't work, RE: testing of MARID proposals Thread-Index: AcR74BYB2cLqhtr5QzSEo3BNQkZxrgABrp7QAAPHZgA= From: "Ryan Malayter" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i76M803P068033 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Gordon Fecyk] >But then we have the whole excessive DNS traffic problem again. I haven't seen anyone present convincing evidence of "excessive DNS traffic" when MX mechanisms are checked. Won't DNS caching will completely eliminate any potential problem? Where, exactly, are you seeing this excessive traffic in your systems? What are the acutal numbers? Is it really a problem in practice, or is it just a theoretical objection? In my (admittedly limited) tests with SPFv1 almost all the MX and host records were already in my DNS cache. Regards, Ryan From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 19:09: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 TAA02446 for ; Fri, 6 Aug 2004 19:09: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 i76Mlxag071176; Fri, 6 Aug 2004 15:47: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 i76MlxJQ071175; Fri, 6 Aug 2004 15:47:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76MlxNv071161 for ; Fri, 6 Aug 2004 15:47:59 -0700 (PDT) (envelope-from msk@sendmail.com) Received: from protagonist.smi.sendmail.com ([10.210.202.26]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i76Mm1wq005828 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 6 Aug 2004 15:48:02 -0700 Received: from protagonist.smi.sendmail.com (localhost [127.0.0.1]) by protagonist.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i76Mm1sP054210 for ; Fri, 6 Aug 2004 15:48:01 -0700 (PDT) (envelope-from msk@sendmail.com) Received: from localhost (msk@localhost) by protagonist.smi.sendmail.com (8.12.9/8.12.9/Submit) with ESMTP id i76Mm08u054207 for ; Fri, 6 Aug 2004 15:48:00 -0700 (PDT) (envelope-from msk@sendmail.com) X-Authentication-Warning: protagonist.smi.sendmail.com: msk owned process doing -bs Date: Fri, 6 Aug 2004 15:47:59 -0700 (PDT) From: "Murray S. Kucherawy" X-X-Sender: msk@protagonist.smi.sendmail.com To: IETF MARID WG Subject: RE: The real reason MARID won't work, RE: testing of MARID proposals In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02B04097@cliff.bai.org> Message-ID: <20040806154615.O53863@protagonist.smi.sendmail.com> References: <792DE28E91F6EA42B4663AE761C41C2A02B04097@cliff.bai.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 Fri, 6 Aug 2004, Ryan Malayter wrote: > [Gordon Fecyk] > >But then we have the whole excessive DNS traffic problem again. > > I haven't seen anyone present convincing evidence of "excessive DNS > traffic" when MX mechanisms are checked. Won't DNS caching will > completely eliminate any potential problem? In fact I have heard (admittedly, not seen) evidence to the contrary, namely that even the large ISPs receive the vast majority of their e-mail from only a few domains. It follows that the DNS impact would quite possibly not be as severe as we all assume. Published empirical evidence would be great and would definitely cut down on the room for rhetoric. From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 20:48: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 UAA07031 for ; Fri, 6 Aug 2004 20:48: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 i770W2H4079906; Fri, 6 Aug 2004 17:32: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 i770W25Z079905; Fri, 6 Aug 2004 17:32:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i770W1Zp079899 for ; Fri, 6 Aug 2004 17:32:01 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 6 Aug 2004 17:31:51 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Aug 2004 17:31:49 -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); Fri, 6 Aug 2004 17:31:50 -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: sender_agents modifier Date: Fri, 6 Aug 2004 17:31:42 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF776D8D@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: sender_agents modifier thread-index: AcR8EOkDAIRFJ7r/RJqE7O11/bAzrQABK8GQ From: "Jim Lyon" To: "Mark Shewmaker" , X-OriginalArrivalTime: 07 Aug 2004 00:31:50.0476 (UTC) FILETIME=[EE24C0C0:01C47C15] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i770W1Zp079900 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The biggest problem with this is that most domains won't have enough information to reasonably set "sender_agents". Clearly, if your domain permits people to send personal e-mail, it can't possibly know. (It doesn't know whether I have a Blackberry or equivalent, for example.) However, I suspect that this inability to set "sender_agents" reasonably won't prevent many domain owners from setting it unreasonably. Therefore, I don't think it's a good idea. -- jimbo From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 21:02: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 VAA07723 for ; Fri, 6 Aug 2004 21:02: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 i76NgJEG075555; Fri, 6 Aug 2004 16:42:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i76NgJgm075554; Fri, 6 Aug 2004 16:42:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76NgIFa075546 for ; Fri, 6 Aug 2004 16:42:18 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i76NgMMt002691 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 6 Aug 2004 19:42:22 -0400 Subject: sender_agents modifier From: Mark Shewmaker To: ietf-mxcomp@imc.org Content-Type: text/plain Message-Id: <1091835903.19686.357.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 06 Aug 2004 19:45:03 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Fri, 06 Aug 2004 19:42:23 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit (I've made suggestions for a modifier of this sort a few times on the spf-discuss list, and even mentioned it during the latest marid talks on #spf, (though not on the jabber channel) but given the timing, I'm told I should suggest it again here for it to have any hope of making it into the final marid specs.) Goal: ----- I want Senders to be able to publish an additional modifier that would allow for the reliable detection of a specific type of forgery that is currently not reliably detectable. Background: ---------- Currently recipients can white-list their known forwarders, in other words they can white-list specific PRAs. White-listing a PRA effectively makes that PRA a trusted agent of the recipient. The recipient would then trust that PRA not to lie to him in the same way he trusts his own MTA not to lie to him. This is all fine and good--by white-listing specific PRAs, the recipient can trust body headers backwards a little bit. But only backwards--there's currently no reliable way to re-examine trust going forwards. But... If a body-header "From:"/PRA-going-forwards address could publish *it's* authorized sending agents (PRAs), you could examine trust going forwards. So then you'd be in a situation where the senders could publish their forward-looking-PRA sending agents, and recipients would know their normal-backward-looking-PRA recipient agents. If those two threads meet in the middle, then you know you can trust the message to be authentic, (in ways you currently can't now.) BUT, if the sender *says* he participates and there's a hole somewhere, then you know the message is a forgery and can reject it. Practical gain: --------------- The current standards don't do anything to prevent someone sending an email with a body From: of "official_person@BigBank.example.com", and a body Sender: of "forgery@thief.example.com". However, if you could look up the spf record of "official_person@BigBank.example.com", and make a query to see if it allows "forger@thief.example.com" to speak on it's behalf, and find out that it doesn't, then you could reject that message at MTA-receipt time. There would then be: o no need to depend on alert recipients to notice oddities in the email headers o no need to depend on educated recipients to understand warnings that updated MUAs might give if they suspect that there's something fishy (heh) going on, and o no need to depend on domain-name-based block lists quickly saying that all mail from "thief.example.com" is unreliable. The actual suggestion: ====================== Preliminary: ------------ For the purpose of this modifier only, imagine that the PRA test algorithm puts "List-ID" in between the body header From and the body header Sender: Were the actual PRA algorithm changed, (which I'm not suggesting), it could be done by moving the "From:" item from number 5 to 6, inserting the following as number 5: 5. Locate all the non-empty List-ID headers in the message. If there are no such headers, continue to step 6. If there are multiple such headers, exit without returning a PRA. If the single non-empty List-ID header is hopelessly malformed (e.g. if it appears to contain multiple mailboxes, or if the single mailbox is hopelessly malformed), exit without returning a PRA. Otherwise, exit returning the mailbox from the List-ID header as the PRA. Suggested new modifier: ----------------------- Imagine a new modifier: sender_agents=mycheck.example.com that recipients could use to see whether a sender authorizes another address as their sending agent by checking: sha1(full_address_of_purported_agent).sender_localpart.mycheck.example.com If the result is an NXDOMAIN, then that sender doesn't list any authorized agent addresses, so no implicit sent-on-behalf-of authorization claims can be validated or invalidated. (Or you could run the test without the sha section and check for NXDOMAIN or not--allowing the sha1() to return NXDOMAIN means one fewer DNS lookups for the case where the sender participates.) If there is a result, then look at the last bit of the resulting address, with "1" meaning the sender authorizes the agent to send on his behalf, or "0" if not. (You'd have to check the unwrapped-SRS address. Also, I'm listing sha1() as a convenience for this description for now. I would ask that if you're responding with alternate encoding suggestions, to make a separate thread on that part of things, since it's mostly uncoupled with the rest of the idea.) (The modifier name should probably be something shorter than "sender_agents".) Details: -------- (Somewhat repetitive--this is taken from my previous spf-discuss message. I'm leaving the repetitive bits in because I'm unsure if I'm explaining things clearly.) A recipient can decide whether or not he trusts the PRA to not be lying about the previous resending hop's claims by looking at his personal PRA whitelist. But without the sender_agents modifier, he can't explicitly backtrack the same trust tests any further. For instance, if I write a message on behalf of my friend using "From: myfriend@example.com" and "Sender: me@example.com" in the body headers, then if the recipient hasn't white-listed me, there's no way for him to know if myfriend@example.com is okay with my making these claims. The most the recipient can tell is that it was really me, "me@example.com" who most recently sent him this message. That's useful to know, but we can do better. Suppose a particularly dastardly fellow had taken to putting lies into my friend's mouth, by sending mail on his supposed behalf, using the exact same method that I'm using to honestly send messages on my friend's behalf. Using the sender_agents modifier, or something close, my friend could then publish a comprehensive list of allowed sending agents, obviously not including the dastardly person on the list. When this person then sends a message to someone with body headers including "From: myfriend@example.com" and "Sender: forger@example.com", then the recipient, in looking up myfriend@example.com's sender_agents modifier, can see that the Sender is not on the allowed list, and reject the message. (Yes, this requires body checks--but these can be done after all other checks. Also, they can even be done by the user--if the rest of the spf checks have passed, then the user can even safely bounce the mail at that point.) So, with a sender_agents modifier, a recipient can know if the original From: address trusts any successive PRA, and how any successive PRA trusts subsequent ones. This lets you have a potentially testable line of trust in the direction of sender to recipient. sender->agent->agent->agent->...->agent->agent->agent->recipient The sender_agents modifier can help validate that line of trust. If the line of trust can be made into an unbroken link of permitted agents between the sender and recipient, then, well, we know that the recipient can trust that the message was sent via agents that either the sender or the recipient trusts. This has more or less been discussed earlier on the spf list multiple times. However, I would now like to make the startling claim that in determining trust, that we can skip agents going forward *and* backwards. (!!!) For a forward-skip example, imagine: ------------------------------------ sender->agent1->agent2->agent3->agent4->recipient. If sender trusts agent1 not to misrepresent him, agent1 trusts agent3 not to misrepresent him, and recipient trusts agent4 to honestly represent received messages, (ie, agent4 is a PRA that the recipient has whitelisted), then this is the same as: (sender->agent3)->(agent4->recipient) ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^ Agents of sender Agents of recipient There are no holes between the agents of the sender and agents of the recipient, so I claim that we can trust the whole authentication chain. I posit that we can ignore the "skipped" agent 2, because agent1 claims to trust agent3. This allows for there to be some internal MTA structure or forwarding between agent1 and agent3. By definition agent1 says he trusts agent3's judgement, so we can assume that agent3 knows some reason why agent2 is trustworthy enough to be in the middle. For a backward-skip example, imagine: ------------------------------------- sender->agent1->agent2->agent3->agent4->recipient. If sender trusts agent1 not to misrepresent him, recipient trusts agent2 to honestly represent received messages, and agent2 trusts agent4 not to represent him. then this is the same as: (sender->agent1)->(agent2->recipient) ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^ Agents of sender Agents of recipient So again I'd claim that since there are no holes between the agents of the sender and agents of the recipient, that again in this case we can trust the whole authentication chain. I posit that we can ignore the "skipped" agents 3 and 4, because the recipient trusts agent2 and agent2 trusts agent4. This allows for there to be some internal MTA/forwarding structure between agent2 and agent4. By definition, the recipient he trusts agent2's judgement, so we can assume that agent2 knows some reason why agent4 is trustworthy enough that the recipient can trust him to have properly validated the chain of trust, (agent4 presumably has his own PRA whitelist, but in any event agent2 trusts agent4's judgement). Backward compatibility: ----------------------- No one currently uses sender_agent modifiers, so how can a recipient go about implementing this functionality without rejecting lots of legitimate mail? I would suggest that since each sender would have the option of doing nothing, (which is the current setup), or participating, that a sensible rule to have here, (maybe there are better ones), for any recipient wanting to take advantage of this functionality could be: "If the claimed original sender (body header From:) participates in sender_agent functionality, then there *must* exist an unbroken and verifiable chain of PRA trust between the original sender and the end recipient, else the message is rejected/bounced." If the claimed original sender (body header From:) does not participate in sender_agent functionality, then you can't really reject immediately on that basis. However, any sender who wants to participate could prevent forgeries of their body header From: addresses fro affecting participating recipients. (I would suggest some sort of body header info added into the topmost Received-SPF: line detailing the result of these tests at message-receipt time. The result would basically be a binary result of PRA-chain validated or not validated.) Handwaving psuedocode: ---------------------- I've only gotten partway through handwaving pseudocode. 1. make a list "Senders", whose reverse is the current PRA and its successive ancestor PRA's going backwards through to the From: body header. 2. Create a list "agents_for", of the same length as senders, each element initialized as an empty list. 3. Create a list "participating_senders" of the same length as senders. 4. Create a list recipient_agents of the recipient's trusted PRAs. 5. Do the following: For each sender in the list senders: If the domain of sender has a sender_agents modifier: test the sender against itself according to the modifier: if the result was success or failure: set corresponding element of participating_senders to TRUE. else: (on nxdomain) set corresponding element of participating_senders to FALSE. else: (if sender domain doesn't have a sender_agents modifier) set corresponding element of participating_senders to FALSE. For each sender in list of senders that are participating_senders: test each successive address in senders against the modifier on success (last bit of result is a "1"): add sender in the corresponding agents_for list on nxdomain: error out For each sender in senders: if the sender is in recipient_agents: add recipient into the corresponding agents_for list That gives us a list of senders, and a list of list of agents in agents_for I'm not sure how to clearly write up the logic of: pass-if-Body_From:-participates-and-there's-a-trusted-link, fail/reject/bounce-if-Body_From:-participates-and-there's-not, error/test_impossible-if-Body_From:-doesn't-participate bit. (So I'm sending without this part really being done.) Side effects/Implications: -------------------------- 1. Since this implementation includes mailing lists as potential sender agents, (or I suppose recipient agents, though I don't think recipients would want to whitelist mailing lists like that), that implies that senders who wish to participate in this scheme would have to whitelist all the mailing lists they participate in. Also, since some senders will forget to do this but try to participate, mailing lists who want to prevent rejects/bounces this will cause can query the sender's sender_agent record and then rejecting or bouncing any messages the sender attempts to send, reminding him to edit his sender_agent record to include the mailing list. (Recipients can also whitelist the mailing lists they subscribe to--so this whitelisting can be done on both sides, since mailing lists are oddly enough both agents of the senders and recipients. Future tools and improvements to MUAs on subscribing/unsubscribing to mailing lists might include functionality to help do this whitelisting & whitelist publishing.) 2. MUA's can look at nonvalidated-sender messages, (ie, where the sender's don't participate so the message can't be outright rejected at receipt), do queries itself, and show the user how far back in the chain the message can be trusted. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Fri Aug 6 23: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 XAA15851 for ; Fri, 6 Aug 2004 23:50:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i773UWuD091627; Fri, 6 Aug 2004 20:30: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 i773UWMZ091626; Fri, 6 Aug 2004 20:30:32 -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 i773ULXD091618 for ; Fri, 6 Aug 2004 20:30:25 -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 8278116E1F for ; Fri, 6 Aug 2004 23:38:25 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: The real reason MARID won't work, RE: testing of MARID proposals In-Reply-To: Your message of "Fri, 06 Aug 2004 15:47:59 PDT." <20040806154615.O53863@protagonist.smi.sendmail.com> Date: Fri, 06 Aug 2004 23:38:25 -0400 Message-Id: <20040807033825.8278116E1F@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Murray S. Kucherawy" wrote: > In fact I have heard (admittedly, not seen) evidence to the contrary, > namely that even the large ISPs receive the vast majority of their e-mail > from only a few domains. The following stats are for how real email is distributed across source IP's. It's not what you're looking for, but it's indicative: http://www.striker.ottawa.on.ca/~aland/spam/sent.png http://www.striker.ottawa.on.ca/~aland/spam/sent-logscale.png That's more interesting. log-log across 4 orders of magnitude. http://www.striker.ottawa.on.ca/~aland/spam/cumulative.png Any successful system getting deployed to the *right* 70k IP's will touch 90% of the non-spam mail. > It follows that the DNS impact would quite possibly not be as > severe as we all assume. The data I posted above is for *all* recipient domains in the data set. My bet is that for most recipient domains, incoming messages are distributed exponentially across sending IP's. While the second doesn't follow from the first, it is often true. Also, DNS caching wil probably mean that non-cached lookups will most likely depend on the number of unique source IP's, and not on the message volume. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 02:59: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 CAA09503 for ; Sat, 7 Aug 2004 02:59: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 i776eVg1040598; Fri, 6 Aug 2004 23:40:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i776eV80040597; Fri, 6 Aug 2004 23:40:31 -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 i776eVGo040589 for ; Fri, 6 Aug 2004 23:40:31 -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 i776e9N25625; Fri, 6 Aug 2004 23:40:09 -0700 Date: Fri, 6 Aug 2004 23:40:04 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <917393469.20040806234004@brandenburg.com> To: Meng Weng Wong CC: Frank Ellermann , ietf-mxcomp@imc.org Subject: Re: "unified spf" In-Reply-To: <20040806134722.GE28401@dumbo.pobox.com> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <43098686-E53B-11D8-9BB9-000A95B3BA44@hxr.us> <3056.130.129.132.229.1091551103.squirrel@harry.mail-abuse.org> <4110E7CC.5796@xyzzy.claranet.de> <4111F07F.5049@xyzzy.claranet.de> <20040806134722.GE28401@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> Actually, we do. There is a set of drafts out there that MWW> collectively describe the "unified" model. "out there" is not meaningful for an IETF working group, as has been pointed out a few times. if you want the IETF to consider some work, you need to bring that work to it. Talking about it -- as you have done since you introduced it to the list and continue on with your latest posting -- without bringing the documents in, is not just distracting, it is confusing. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 03:04:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09849 for ; Sat, 7 Aug 2004 03:04:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i776oS7c043941; Fri, 6 Aug 2004 23:50: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 i776oSe8043940; Fri, 6 Aug 2004 23:50:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i776oRRN043928 for ; Fri, 6 Aug 2004 23:50:27 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i776oNMt012641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 7 Aug 2004 02:50:24 -0400 Subject: RE: sender_agents modifier From: Mark Shewmaker To: ietf-mxcomp@imc.org Cc: Jim Lyon In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF776D8D@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF776D8D@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1091861585.19694.453.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 07 Aug 2004 02:53:06 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Sat, 07 Aug 2004 02:50:25 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-06 at 20:31, Jim Lyon wrote: > The biggest problem with this is that most domains won't have enough > information to reasonably set "sender_agents". Clearly, if your domain > permits people to send personal e-mail, it can't possibly know. If they don't know, then they needn't enter information for that address. And if they want to know, they can just ask. :-) Right now it's quite common for ISPs to let their customers enter such things as forward-to addresses via web-based control panels. I'm sure they'll extend such functionality to allow customers to enter their authorized sender-agents, just as I'm sure they'll extend the functionality to allow their users to whitelist their forward-from (PRA) addresses. All the web page would have to do is ask. For instance: What mailing lists do you subscribe to? [Over time, this part should become more automated.] ________________________ ________________________ ________________________ ________________________ What email addresses do you always want to accept forwards from? The above mailing lists and: ________________________ ________________________ ________________________ ________________________ What email addresses do you allow to speak on your behalf? [ ] I allow everyone to speak on my behalf [ ] I make no claims one one way or another. [X] I allow only the following listed addresses to speak on my behalf: The above mailing lists and: _________________________ _________________________ _________________________ _________________________ _________________________ (Cool side issue: With a sender_agents modifier, domain-based block lists could become full-email-address-based block lists, blocking on the email address if the email address participates in sender_agents, and blocking on just the domain if it doesn't.) > However, I suspect that this inability to set "sender_agents" reasonably > won't prevent many domain owners from setting it unreasonably. > > Therefore, I don't think it's a good idea. Sorry, but that specific argument just doesn't fly. :-) There are probably other reasons you might disagree with the idea of a sender_agents type of modifier, but it doesn't make sense for that specific reason to be one of them. The reason is that that same argument would apply to the %l (local-part) macro variable. Are you saying that you want to get rid of all references to local-parts in the specs? :-) Do you really think a setting should be unavailable because of the disadvantage that domain owners might set it unreasonably? (Wouldn't they lose business/customers if they did that?) Compared to that disadvantage, look at the advantages that sender_agents would provide: Currently, recipient users and ISPs can only guess as to whether any particular email is a forgery of the unauthorized-body-sender type. These are guesses, educated guesses, but guesses nonetheless. If we had sender_agents, then when the purported Header-From/forward-PRA participates, recipients need not guess--they can *know*. So when sender scammer@scammer.example.com sends a mail with header "From: accounts@citibank.com" and with themselves in the header Sender: line, then a receiving MTA can safely reject the message, (yes, after DATA--sorry!), no matter *what* other verification tests happened. Or when spyware@spyware.example.com sends mail with header "From: microsoftupdates@microsoft.com", and themselves as the header Sender, (presumably including in the message an html link saying something along the lines of "click here to download the latest security patches"), receiving MTAs can safely reject the message, no matter what other verification tests happened. In neither of the above cases would it need to matter that the MX sending IPs of, or domain names of "scammer@scammer.example.com" or "spyware@spyware.example.com", had or had not entered block lists yet--if the companies listed in the header From:'s participated in sender_agents with defaults of "not allows", then participating recipients need never have any chance (absent DNS server hijacks and the like) of being a victim of such scams. In both cases, a sender_agents modifier would let recipients know that the purported header From: party does not allow the later PRAs to speak for it--it's a way of letting recipients know that messages such as those are *not* authentic. SPF/Sender-ID has always been focused around authentication, but with the spec as it is, recipients don't have the information they need to make this type of authentication test, and senders have no way of publishing such information. I suggest that it would be a good idea to allow people to publish records about and run test for this type of forgery. Please don't prevent the reliable detection of this type of forgery merely because some domain owners will post inaccurate information about how to identify what mails, purportedly sent under the authorization of addresses in their domain, fall under this category of forgery. From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 05:41:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16586 for ; Sat, 7 Aug 2004 05: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 i779GARc093930; Sat, 7 Aug 2004 02:16:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i779GALE093929; Sat, 7 Aug 2004 02:16:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from krypton.melitacable.com (ns.melitacable.com [212.56.128.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i779G9i5093903 for ; Sat, 7 Aug 2004 02:16:09 -0700 (PDT) (envelope-from james@drinkinginthesun.com) Received: from talibang2jl3jr (c211-94.i03-5.onvol.net [213.217.211.94]) by krypton.melitacable.com (8.12.3/8.12.3) with SMTP id i779GHGq028558 for ; Sat, 7 Aug 2004 11:16:17 +0200 (MEST) Reply-To: From: "James Pullicino" To: Subject: RE: "unified spf" Date: Sat, 7 Aug 2004 11:20:25 +0200 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.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <20040806134722.GE28401@dumbo.pobox.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> I have no plans to submit them as I-Ds. They have >> informational value at best. I hope they are a >> constructive contribution. Thanks Meng, I found pleny of value in these drafts. They look promising. I would like to see them put forward to IETF one day. Regards, James Pullicino -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Meng Weng Wong Sent: Friday, August 06, 2004 3:47 PM To: Frank Ellermann Cc: ietf-mxcomp@imc.org Subject: "unified spf" On Thu, Aug 05, 2004 at 10:31:59AM +0200, Frank Ellermann wrote: | | This _and_ is very important. Maybe we should mention it in | SPF/PRA resp. SPF/FROM, these tests make no sense without a | prior SPF/MAILFROM test. The important thing is SPF/MAILFROM, | and at the moment we have no draft for SPF/MAILFROM (= the old | draft-mengwong-spf-01.txt minus all stuff now covered by MARID | protocol-00.txt). | Actually, we do. There is a set of drafts out there that collectively describe the "unified" model. They have not been published to the list for fear of distraction; given the tight time constraints, it seems prudent to focus on getting Sender ID off the ground before opening the door to more theoretical discussion. But I will mention them for the record, and because there has been some interest in the past in defining the term "Unified SPF". At the WG meeting, some folks suggested we should extract the PRA algorithm from the core document because it has general utility in the 2822 space independent of MARID work. That refactoring represents a step in the direction of the unified drafts. The "unified" document describes the overall structure. The "protocol" document describes the SPF test. "ptr", "helo", "mailfrom", and "pra" describe the semantics of the SPF test in the context of each identity. "best" shows how the four instances interact. The documents at http://spf.pobox.com/unified/id/ are a rough draft. They represent only my take (together with Mark) on another way to present Sender ID. I have no plans to submit them as I-Ds. They have informational value at best. I hope they are a constructive contribution. --- Mail Scanned Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004 From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 06:36: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 GAA19098 for ; Sat, 7 Aug 2004 06:36: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 i77AHcRD014909; Sat, 7 Aug 2004 03:17:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i77AHcnx014908; Sat, 7 Aug 2004 03:17:38 -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 i77AHaFS014860 for ; Sat, 7 Aug 2004 03:17:37 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BtOGa-0007ob-00 for ; Sat, 07 Aug 2004 12:17:32 +0200 Received: from du-001-117.access.de.clara.net ([212.82.227.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Aug 2004 12:17:32 +0200 Received: from nobody by du-001-117.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Aug 2004 12:17:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: So ... did Dewey beat Truman? Date: Sat, 07 Aug 2004 12:16:28 +0200 Organization: Lines: 23 Message-ID: <4114ABFC.10A1@xyzzy.claranet.de> References: <015201c47b16$feb41c10$cec8d684@sraq.intra> <003501c47b35$6c27d750$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-117.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 John Glube wrote: > Prudent senders will take the time and effort to properly > configure their systems so that recipient's can run any > check they want. No, with SPF/FROM-HDR they will delete their sender policy. Users want to use "their" mailbox address in From: headers, even if it doesn't match the MAIL FROM. As soon as a mail is deleted after a mismatch they'll complain to the provider of "their" address. After the 2nd deletion they will go to another provider without "restrictive" sender policy. And after some complaints from unhappy users AOL or GMX or ... will delete their sender policy and stop to check sender policies. The typical user cannot define his own personal sender policy, just like a typical user cannot define his own personal REJECT rules. Big ISPs won't offer this, it's too expensive and too complex. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 07:14:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20928 for ; Sat, 7 Aug 2004 07:14:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77B13YP025356; Sat, 7 Aug 2004 04:01: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 i77B131Z025353; Sat, 7 Aug 2004 04:01:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77B13Xx025341 for ; Sat, 7 Aug 2004 04:01:03 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1BtOwh-000Pcd-00 for ietf-mxcomp@imc.org; Sat, 07 Aug 2004 12:01:03 +0100 Message-ID: <04de01c47c6d$92195630$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: Security-related Wording issues - section 6.3 Date: Sat, 7 Aug 2004 11:59:09 +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 reference draft-ietf-marid-core-02.txt, Section 6.3 Two wording points: 1) Section title I find the section title "Forged Resent-From Attacks" misleading. The Resent-From address in these attacks is not forged, it is valid. It is the sender address/es (From:, Sender:) which may have been forged. Maybe "Forged Sender Addresses" would be better? 2) The second para starts: "In order to avoid this attack, MUAs will need to ..." To me, this is not 'avoiding' the attack, this is 'assisting the user to detect the attack'. Using the provisions of Sender-ID there is no way the MTA or MUA can even detect this attack, let alone defend against it or avoid it. None of the technology involved has any idea which sender addresses may legitimately be paired with any given Resent-From address. This section should be re-worded to make it clear that its is only the end-user who can detect the possibility of an attack and make any judgement about it. HTH Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 07:15: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 HAA20979 for ; Sat, 7 Aug 2004 07:15: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 i77B139d025355; Sat, 7 Aug 2004 04:01: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 i77B13CP025354; Sat, 7 Aug 2004 04:01:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77B13ja025342 for ; Sat, 7 Aug 2004 04:01:03 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1BtOwh-000Pat-00 for ietf-mxcomp@imc.org; Sat, 07 Aug 2004 12:01:03 +0100 Message-ID: <04dd01c47c6d$91e0e110$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: Security issue: End-user dependence on MTA integrity Date: Sat, 7 Aug 2004 11:59:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I reference draft-ietf-marid-core-02.txt The basic aim of the MARID Sender ID appears to me to be the presentation to the end-user of a validated PRA. The MTA which receives an incoming message is required to determine and validate the PRA. If a valid PRA is found, the message may be delivered to the intended recipient. The draft recommends (albeit only in section 6.3 when discussing a particular mode of attack) that MUAs should display the PRA, and, by implication, the user of that MUA may trust that the PRA has been validated. There is no recommendation that I can see anywhere in this draft that the MTA should inform the MUA that a PRA test was successfully undertaken. Now consider the situation of a user who receives her eMail from an ISP. The ISP may make a one-off announcement that it is now "supporting Sender-ID". This would be taken by the user as an invitation to trust the ISP to be applying the test to all messages. If she has a compliant MUA she sees one or more addresses displayed. What she does not see is any indication of where any of these addresses have been validated. - Suppose the message has arrived at a back-up MTA which has not yet been fitted with the Sender-ID tests. - Suppose the main MTA has been mis-configured or some other fault. - Suppose the ISP has changed its policy and is no longer undertaking this test. - Suppose that the ISP has been required to cease use of a PRA-related patent by the issuer of its licence. How is the end-user supposed to know whether or not to trust any of the displayed addresses? The whole essence of the 'implied security contract' of Sender-ID is that the end-user is assured that the PRA has been validated, and can therefore be trusted. I contend that this inability to communicate to the MUA whether or not the Sender-ID test has been applied to any particular message is a significant security flaw. HTH Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 07: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 HAA21033 for ; Sat, 7 Aug 2004 07:16: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 i77B1544025368; Sat, 7 Aug 2004 04:01:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i77B15Uc025367; Sat, 7 Aug 2004 04:01:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77B14IN025359 for ; Sat, 7 Aug 2004 04:01:05 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1BtOwj-000PdV-00 for ietf-mxcomp@imc.org; Sat, 07 Aug 2004 12:01:05 +0100 Message-ID: <04df01c47c6d$936fbe70$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: The application of PRA-related IPR to MUAs Date: Sat, 7 Aug 2004 11:59:13 +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 reference draft-ietf-marid-core-02.txt May I just make an observation which may assist those considering the IPR issues? So far on this list I think I have only seen references to PRA IPR in relation to MTAs. The security consideration in Section 6.3 (Forged Resent-From Attacks) states that MUAs will need to start displaying 'at least the header that was verified'. I have written separately (Security issue: End-user dependence on MTA integrity) about the need for users to be shown exactly which address was validated as the PRA. Note that the Sender-ID drafts provide no means for the MTA to tell the MUA which address was determined to be PRA. The implication is that, for general usability and, in particular, for defence against the security attack described in section 6.3, the MUA will have to have the ability to determine the PRA for itself. The inference is that all such MUAs will be subject to whatever licencing is associated with the PRA algorithm, not just the MTAs. I trust that those considering these issues on behalf of the IETF have taken into account this possible need for all MUAs to be subject to the licence. HTH Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 07:17:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21077 for ; Sat, 7 Aug 2004 07:17:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77B0wqj025326; Sat, 7 Aug 2004 04:00: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 i77B0wem025325; Sat, 7 Aug 2004 04:00:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77B0wKf025319 for ; Sat, 7 Aug 2004 04:00:58 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1BtOwc-000Dhs-00 for ietf-mxcomp@imc.org; Sat, 07 Aug 2004 12:00:58 +0100 Message-ID: <04dc01c47c6d$8f1739c0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: Security issue: Minority installed base of compatible MUAs? Date: Sat, 7 Aug 2004 11:59:02 +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 reference draft-ietf-marid-core-02.txt The abstract states that the specification is 'carefully tailored to ensure that the overwhelming majority of legitimate emailers, remailers and mailing list operators are already compliant'. It says nothing about the compliance of / compatibility with existing MUAs. Section 6.3 acknowledges that there is no defence against a message sent with a forged From: header, but with a valid Resent-From: header. I would imagine that this attack is relatively easy to undertake, e.g. by trojan or zombie control of hosts which are valid 'marid1' mail originators. It would, I imagine be a mode of attack which would be very attractive to 'phishers'. The draft states that "in order to avoid this attack, MUAs will need to start displaying at least the header that was verified". My concern is the need for new MUA purchases. I can't find reliable market share statistics, but I would imagine that Outlook Express is the leading MUA in the world, being the default MUA supplied with the vast majority of the world's installed base of consumer PCs. AFAICT Outlook Express cannot directly 'display the header that was verified' (i.e. the Resent-From: header content) under these attack conditions. Therefore a large proportion of the world's consumer users will have to purchase (or otherwise obtain) new MUA software to obtain the ability to defend against this attack. Is the IETF MARID WG 'comfortable' with the implication that very many of the world's PC consumers will have to purchase a new product in order to be defended against this trivial and highly-likely attack? In 'educating' the world about this important and high-profile defence of the world's eMail service, is the IETF prepared to give adequate prominence to the need for hundreds of millions of replacement product purchases? Or, to put it another way (and one which is rather more to the point of the present editorial phase), I think that the security analysis of section 6.3 needs to be a lot more candid about the vulnerability of (what is probably) the majority of the world's installed base of MUAs to this attack, and about how long it will take for Sender-ID to play a significant role in solving the identified global problem. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 07:33: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 HAA21865 for ; Sat, 7 Aug 2004 07:33: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 i77BHrwC030405; Sat, 7 Aug 2004 04:17:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i77BHr1D030404; Sat, 7 Aug 2004 04:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77BHpWO030390 for ; Sat, 7 Aug 2004 04:17:52 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 7 Aug 2004 11:17:49 +0000 From: "Michael R. Brumm" To: Subject: Will Accepting SUBMITTER Get You Blacklisted? Date: Sat, 7 Aug 2004 05:17:47 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-OriginalArrivalTime: 07 Aug 2004 11:17:49.0828 (UTC) FILETIME=[2C848440:01C47C70] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i77BHqWO030397 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Here's a little problem I see with implementing SUBMITTER on an MTA... let me know if I'm wrong on anything. First, let's assume a domain "allows-submitter.com", who has MTAs which allow SUBMITTER to be specified on the "MAIL FROM" command. allows-submitter.com has the following MX records: mx1.allows-submitter.com MX preference = 0 mx2.allows-submitter.com MX preference = 10 A spammer/virus connects to mx2.allows-submitter.com because it knows that a message sent to a secondary MTA is much more likely to cause a bounce than a rejection. connection to mx2.allows-submitter.com ------ MAIL FROM: recipient@target.com SUBMITTER=hostile@throw-away.com RCPT TO: invalid@allows-submitter.com DATA (includes virus or spam as payload) When mx2 tries to relay to mx1 (the primary MTA), mx1 rejects the message because "invalid@allows-submitter.com" doesn't exist (or has mailbox full, etc...). Now, mx2 sends a DSN (attaching the payload) to "recipient@target.com". "recipient@target.com" (and probably a lot of other recipients in a lot of other domains) is now receiving spam/viruses from <> (postmaster@allows-submitter.com) and SPF evaluation proves that it is coming from "allows-submitter.com". So, the postmaster at target.com decides to blacklist the "allows-submitter.com" domain because (somewhat like an open-relay) they are allowing spam and viruses to be relayed through their MTA. Am I missing anything? Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 08:06: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 IAA24212 for ; Sat, 7 Aug 2004 08:06: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 i77BkkF2033228; Sat, 7 Aug 2004 04:46: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 i77BkkcM033225; Sat, 7 Aug 2004 04:46:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77Bki6A033211 for ; Sat, 7 Aug 2004 04:46:45 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i77BkckI021656 for ; Sat, 7 Aug 2004 12:46:38 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i77Bkcc8021655; Sat, 7 Aug 2004 12:46:38 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: So ... did Dewey beat Truman? References: <015201c47b16$feb41c10$cec8d684@sraq.intra> <003501c47b35$6c27d750$6c62fea9@ibmrkydk2ufvdd> <4114ABFC.10A1@xyzzy.claranet.de> From: Graham Murray Date: Sat, 07 Aug 2004 12:46:37 +0100 In-Reply-To: <4114ABFC.10A1@xyzzy.claranet.de> (Frank Ellermann's message of "Sat, 07 Aug 2004 12:16:28 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann writes: > No, with SPF/FROM-HDR they will delete their sender policy. > Users want to use "their" mailbox address in From: headers, > even if it doesn't match the MAIL FROM. [snip] > > The typical user cannot define his own personal sender policy, > just like a typical user cannot define his own personal REJECT > rules. Big ISPs won't offer this, it's too expensive and too > complex. But will the 'typical' big ISP user want to use a From: address which is different from the ISP allocated (MAIL FROM) address? If the customer wants to define his own sender or reject policy or use his own domain then he always has the option of using a mail hosting service or moving to a smaller ISP which does offer this. For larger companies, especially those like financial institutions who are likely targets of phishing, it would be to their advantage to ensure that all mail they send out has their domain in all of the MAIL FROM, EHLO, and From:. The current practice I have seen of well known companies sending out (legitimate) mailshots (to customers) with a MAIL FROM and EHLO of somepr-or-marketting-company.com with From: someuser@wellknowcompany.com does not help at all in the fight against phishing. From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 08:20: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 IAA24858 for ; Sat, 7 Aug 2004 08:20: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 i77C6M3e034190; Sat, 7 Aug 2004 05:06:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i77C6MKg034189; Sat, 7 Aug 2004 05:06:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77C6LWd034182 for ; Sat, 7 Aug 2004 05:06:21 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BtPxu-00012A-00 for ; Sat, 07 Aug 2004 14:06:22 +0200 Received: from du-001-117.access.de.clara.net ([212.82.227.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Aug 2004 14:06:22 +0200 Received: from nobody by du-001-117.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Aug 2004 14:06:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: changing the SPF record version number? Date: Sat, 07 Aug 2004 14:05:00 +0200 Organization: Lines: 42 Message-ID: <4114C56C.752F@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-117.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > I think that *just* changing the version number and > abandoning the SPF1 records is a bad idea. At least it's a consequent solution, and if SUBMITTER really reintroduces bounces to innocent bystanders it's necessary. Most existing v=spf1 records have one goal: Protect the 2821 MAIL FROM, stop useless bounces to forged MAIL FROM addresses. That's the one and only purpose of SPF classic, existing exp= explanations like are based on this assumption. > I think we should use SPF1 records For SPF/MAILFROM, and maybe for a compatible version of PRA, if we add a rule that MAIL FROM != From: without Sender: is implicitly handled like MAIL FROM == Sender (near step 4 in draft-ietf-marid-core-02.txt 4.4). > If domain owners feel that they need different records > when used with the PRA algorithm, they can publish SPF2 > records and use the scope variable to make the required > distinctions. Okay, something like "v=spf2 a -all check=2822" could allow incompatible header checks, and / or "check=2821" would be the same as an existing v=spf1 sender policy. In theory it's possible to add this modifier without changing the version: A "v=spf1" without "check=2822" would stand for SPF classic, and a "v=spf1" with "check=2822" would allow new incompatible checks like SPF/FROM-HDR resp. core-02 Sender-Id. Something like "forget SPF/MAILFROM, do only new stuff" isn't possible with protocol-00.txt and v=spf1, implementations are free to ignore unknown modifiers. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 09:26: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 JAA28675 for ; Sat, 7 Aug 2004 09:26: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 i77D83UG040915; Sat, 7 Aug 2004 06:08: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 i77D83sp040914; Sat, 7 Aug 2004 06:08:03 -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 i77D81Ei040907 for ; Sat, 7 Aug 2004 06:08:03 -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, 07 Aug 2004 09:08:00 -0400 id 0019767E.4114D430.00007920 In-Reply-To: <006701c47bf9$540b33f0$6c62fea9@ibmrkydk2ufvdd> References: <006701c47bf9$540b33f0$6c62fea9@ibmrkydk2ufvdd> 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 \"\(e-mail\)'" From: Andrew Newton Subject: Re: milestones for CSV Date: Sat, 7 Aug 2004 09:07:58 -0400 To: "John Glube" 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 Aug 6, 2004, at 5:07 PM, John Glube wrote: > If so, may we have these milestones sent to the list? I believe we settled on Oct. 11 for wglc of the CSV docs? -andy From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 11:58: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 LAA07515 for ; Sat, 7 Aug 2004 11:58:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77FciuG051891; Sat, 7 Aug 2004 08:38: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 i77Fciga051890; Sat, 7 Aug 2004 08:38:44 -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 i77Fcdkh051884 for ; Sat, 7 Aug 2004 08:38:40 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BtTHO-0004sR-00 for ; Sat, 07 Aug 2004 17:38:42 +0200 Received: from du-001-117.access.de.clara.net ([212.82.227.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Aug 2004 17:38:42 +0200 Received: from nobody by du-001-117.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Aug 2004 17:38:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: So ... did Dewey beat Truman? Date: Sat, 07 Aug 2004 17:36:19 +0200 Organization: Lines: 46 Message-ID: <4114F6F3.1531@xyzzy.claranet.de> References: <015201c47b16$feb41c10$cec8d684@sraq.intra> <003501c47b35$6c27d750$6c62fea9@ibmrkydk2ufvdd> <4114ABFC.10A1@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-117.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 Graham Murray wrote: > will the 'typical' big ISP user want to use a From: address > which is different from the ISP allocated (MAIL FROM) > address? If that typical user is me, then yes. The German market has a lot of call-by-call ISPs for modem / ISDN users, and depending on the time and the day of the week I use different ISPs. Most of these ISPs offer mail services. And a majority of the ISPs with mail services allow POP3 access independent of the IP (i.e. I can get my mail from ISP A even if I'm online using ISP B). But ISP A won't allow me to send mail while I'm using another ISP. Therefore I use my address at ISP A always as From: address, but my MAIL FROM depends on the mail provider (ISP A, or a MSA of a 3rd party, or the smart host of another ISP). I have no idea how usual or unusual that is, but the default smart host of the biggest German ISP enforces a From: address matching the MAIL FROM matching the identified user (RADIUS): They simply replace From: and MAIL FROM. Many Usenet users (not exactly "typical") are very unhappy with this practice. > he always has the option of using a mail hosting service or > moving to a smaller ISP which does offer this. Sure, but these services are generally not "free", i.e. not included by call-by-call ISP services. One of the SPF ideas is that this is a voluntary thing. Sender-Id would force MSAs of 3rd parties to implement RfC 2476 8.1 "MAY" even if they're not interested in Sender-Id, _or_ the users of these MSAs could upgrade their MUA to do this automatically, _or_ they insert a Sender: manually, _or_ they don't know what's going on, their mail is rejected, and they're unhappy with this MARID business, where they can't use their favourite From: address everywhere. If the only problem in this case is the missing Sender:, why not handle the Return-Path as "PRA" (only in this case) ? The MUA of the recipient wants to display a verified "PRA", so this MUA knows the new "PRA" concept, and therefore it could handle this obvious problem. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 12:39: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 MAA09303 for ; Sat, 7 Aug 2004 12:39:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77GJHPZ055898; Sat, 7 Aug 2004 09:19: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 i77GJHtw055897; Sat, 7 Aug 2004 09:19:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77GJG1H055891 for ; Sat, 7 Aug 2004 09:19:16 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LDCUYJ20CW00005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Sat, 07 Aug 2004 09:19:15 -0700 (PDT) Date: Sat, 07 Aug 2004 09:04:06 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Will Accepting SUBMITTER Get You Blacklisted? In-reply-to: "Your message dated Sat, 07 Aug 2004 05:17:47 -0600" To: Michael R Brumm Cc: ietf-mxcomp@imc.org Message-id: <01LDDM0NNU0600005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > Here's a little problem I see with implementing SUBMITTER on an MTA... let me > know if I'm wrong on anything. > First, let's assume a domain "allows-submitter.com", who has MTAs which allow > SUBMITTER to be specified on the "MAIL FROM" command. > allows-submitter.com has the following MX records: > mx1.allows-submitter.com MX preference = 0 > mx2.allows-submitter.com MX preference = 10 > A spammer/virus connects to mx2.allows-submitter.com because it knows that a > message sent to a secondary MTA is much more likely to cause a bounce than a > rejection. > connection to mx2.allows-submitter.com > ------ > MAIL FROM: recipient@target.com SUBMITTER=hostile@throw-away.com > RCPT TO: invalid@allows-submitter.com > DATA > (includes virus or spam as payload) This is only possible if mx2 implements the extension, and if the extension is implemented mx2 is also required to check the value of the SUBMITTER parameter against the header. If it doesn't match the message has to be rejected and not relayed. The only time the message will get through is if the SUBMITTER value matches the header PRA. > When mx2 tries to relay to mx1 (the primary MTA), mx1 rejects the message > because "invalid@allows-submitter.com" doesn't exist (or has mailbox full, > etc...). Now, mx2 sends a DSN (attaching the payload) to > "recipient@target.com". Which is no different than if SUBMITTER wasn't used - the PRA has to be the same as the SUBMITTER value for the message to get this far. > "recipient@target.com" (and probably a lot of other recipients in a lot of > other domains) is now receiving spam/viruses from <> > (postmaster@allows-submitter.com) and SPF evaluation proves that it is > coming from "allows-submitter.com". Which again is no different than if SUBMITTER wasn't used. > So, the postmaster at target.com decides to blacklist the > "allows-submitter.com" domain because (somewhat like an open-relay) they are > allowing spam and viruses to be relayed through their MTA. Relaying per se isn't the issue. This issue arises any time an MTA accepts a piece of spam and bounces it later to a forged MAIL FROM address. This happens all the time for a variety of reasons: Not all MTAs check address validity during the SMTP session, you're dealing with a secondary MX, the recipient is over quota, the recipient has filtering in place that causes a delivery time rejection, etc. etc. etc. Indeed, one of the main goals of these schemes is to try and prevent such messages from being accepted in the first place. > Am I missing anything? You're missing the fact that SUBMITTER is simply an optimization allowing a check to be performed earlier in the SMTP transaction than it otherwise could be; at most it will lead to a message being rejected sooner. By itself the use or non-use of the SUBMITTER extension neither solves the bounced spam/virus problem nor makes it any worse. Ned From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 20:15: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 UAA02099 for ; Sat, 7 Aug 2004 20:15: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 i77NvhFU084578; Sat, 7 Aug 2004 16: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 i77Nvhqe084577; Sat, 7 Aug 2004 16:57:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77Nvfsk084569 for ; Sat, 7 Aug 2004 16:57:42 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 7 Aug 2004 23:57:40 +0000 From: "Michael R. Brumm" To: Subject: RE: Will Accepting SUBMITTER Get You Blacklisted? Date: Sat, 7 Aug 2004 17:57:40 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <01LDDM0NNU0600005R@mauve.mrochek.com> Importance: Normal X-OriginalArrivalTime: 07 Aug 2004 23:57:40.0026 (UTC) FILETIME=[5264A9A0:01C47CDA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i77Nvgsk084572 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Ned Freed wrote: >This is only possible if mx2 implements the extension, and if the extension is >implemented mx2 is also required to check the value of the SUBMITTER parameter >against the header. If it doesn't match the message has to be rejected and not >relayed. The only time the message will get through is if the SUBMITTER value >matches the header PRA. Of course. I expect the spammer/virus to follow the rest of the SUBMITTER requirements and place "hostile@throw-away.com" in the PRA. Otherwise, the message probably wouldn't get onto mx2. Much of the rest of your message seems to imply that the PRA checking somehow prevents forged bounce injection, and I don't see how it would. Ned Freed wrote: >Relaying per se isn't the issue. This issue arises any time an MTA accepts a >piece of spam and bounces it later to a forged MAIL FROM address. This happens >all the time for a variety of reasons: Not all MTAs check address validity >during the SMTP session, you're dealing with a secondary MX, the recipient is >over quota, the recipient has filtering in place that causes a delivery time >rejection, etc. etc. etc. Indeed, one of the main goals of these schemes is to >try and prevent such messages from being accepted in the first place. I think you need to re-read my message. I don't see anything in your argument which would prevent the attack scheme I outlined from occurring. SUBMITTER allows forged bounces to be injected onto forwarders (even with PRA checks). The bounces go to a third party (the MAIL FROM), which may see the forged bounces as spam/viruses from the forwarder (not the injector). This could cause the forwarder (which is only following the SUBMITTER protocol) to be blacklisted. This means that with either 1) a throw-away domain or 2) a hijacked domain, someone could attack any domain with MTAs supporting SUBMITTER and make them appear to be sending spam/viruses in (what would appear to be) fake bounces. These messages would come directly from the attacked domain's MTAs and would pass SPF evaluations, making them look very much like they are fake bounces. Postmasters receiving these messages might consider themselves to be under attack from the attacked domain, thus causing the attacked domain to be blacklisted. SRS and DBBF do not appear to have this weakness. Just to make sure that our terminology is clear: forged bounce = bounce created when an MTA bounces a message that was forged, usually occurs when a spammer or virus sends out messages as someone else. fake bounce = bounce that has no complimentary message, usually a virus creating a fake DSN (spammers rarely use this). Ned Freed wrote: >You're missing the fact that SUBMITTER is simply an optimization allowing a >check to be performed earlier in the SMTP transaction than it otherwise could >be; at most it will lead to a message being rejected sooner. By itself the use >or non-use of the SUBMITTER extension neither solves the bounced spam/virus >problem nor makes it any worse. SUBMITTER is more than just an "optimization" to allow the 2822 PRA to be seen at the 2821 level. It is a forwarding scheme designed as an alternative to envelope-from rewriting schemes like SRS and DBBF. See http://www.michaelbrumm.com/spf-forwarding.html Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Sat Aug 7 21:02:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04264 for ; Sat, 7 Aug 2004 21:02:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i780n1R8088903; Sat, 7 Aug 2004 17:49: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 i780n1Ic088902; Sat, 7 Aug 2004 17:49:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i780mxgc088896 for ; Sat, 7 Aug 2004 17:49:00 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 8 Aug 2004 00:48:59 +0000 From: "Michael R. Brumm" To: Subject: RE: Will Accepting Using PRA Get You Blacklisted? Date: Sat, 7 Aug 2004 18:49:00 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 08 Aug 2004 00:48:59.0579 (UTC) FILETIME=[7DF328B0:01C47CE1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i780n0gc088897 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Ok, to reduce confusion, I have changed my discussion to that of the PRA. Accepting based on SUBMITTER implies the PRA check, but obviously doing evaluations based on the PRA-only also has the same attack weakness that I was discussing. Although this injected forged bounces weakness has been known for some time, it was previously only described as a minor annoyance which had no significant consequence. It is my belief that the attack scenario I outlined shows that it is more serious than that. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Sun Aug 8 01:37: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 BAA15839 for ; Sun, 8 Aug 2004 01:37:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i785GUXV013645; Sat, 7 Aug 2004 22:16:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i785GU9x013644; Sat, 7 Aug 2004 22:16:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i785GSQb013586 for ; Sat, 7 Aug 2004 22:16:29 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i785GSOv031249 for ; Sun, 8 Aug 2004 06:16:28 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i785GSEx031248; Sun, 8 Aug 2004 06:16:28 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Will Accepting SUBMITTER Get You Blacklisted? References: From: Graham Murray Date: Sun, 08 Aug 2004 06:16:27 +0100 In-Reply-To: (Michael R. Brumm's message of "Sat, 7 Aug 2004 17:57:40 -0600") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Michael R. Brumm" writes: > I think you need to re-read my message. I don't see anything in your > argument which would prevent the attack scheme I outlined from > occurring. SUBMITTER allows forged bounces to be injected onto > forwarders (even with PRA checks). The bounces go to a third party > (the MAIL FROM), which may see the forged bounces as spam/viruses from > the forwarder (not the injector). This could cause the forwarder > (which is only following the SUBMITTER protocol) to be blacklisted. Which can be avoided by the forwarder doing SPF classic (or equivalent) checks to validate the MAIL FROM, and rejecting the mail if this fails, as well as performing SUBMITTER checks. Which is why I think that it is important that whatever may be decided about PRA, SUBMITTER and RCF2822 checks, that it is still important to do perform MAIL FROM checks to prevent such injections. Your scenario also shows that it is unwise to include the message body in bounces. Forwarder is less likely to be blacklisted if the bounces do not contain the spam/virus payload (but that is not the province of this list) From owner-ietf-mxcomp@mail.imc.org Sun Aug 8 17:50: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 RAA14181 for ; Sun, 8 Aug 2004 17:50: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 i78LXVLH084605; Sun, 8 Aug 2004 14:33:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i78LXVMd084604; Sun, 8 Aug 2004 14:33:31 -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 i78LXU3w084591 for ; Sun, 8 Aug 2004 14:33:30 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1CE0DE06EE; Sun, 8 Aug 2004 17:33:23 -0400 (EDT) Date: Sun, 8 Aug 2004 17:33:23 -0400 From: John Leslie To: Michel Bouissou Cc: IETF MARID WG Subject: Re: IPR Disclosure for Sender-ID Message-ID: <20040808213323.GA72925@verdi> References: <004301c47933$7913a4c0$6c62fea9@ibmrkydk2ufvdd> <200408040034.08677@totor.bouissou.net> <20040804003700.GB91949@verdi> <200408040308.55135@totor.bouissou.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408040308.55135@totor.bouissou.net> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michel Bouissou wrote: > Le mercredi 4 Ao?t 2004 02:37, John Leslie a ?crit : >> >> If there is any "mandate" to use accreditation services, it won't be >> coming from MARID. However, burying our heads in the sand won't help: >> At best, MARID can verify that a domain intends to authorize particular >> actions by MTAs: we can say nothing about whether this authorization >> gives the receiver good reason to trust that MTA. >> >> There must be accreditation services (by whatever name we call them) >> to provide that critical information link. > > Do we actually need to have "good reasons to trust a MTA" to start > accepting mail from it, or do we barely need to be able to stop > accepting mail from ill-behaved domains once they're flagged as "bad" ? This is a distinction without a difference: we need "good enough" reasons to trust the MTA using that EHLO domain-name. "Good enough" is in the eye of the beholder. Hopefully, most sites will accept email from previously-unknown domains until the first instance of abuse (which can be propagated by reputation services within seconds); and accept email from previously-trusted domains until a pattern of abuse (possibly extending over several days) is seen. But all of that is a local option; and local options will drive the kinds of reputation services which are widely used. (Fortunately, there's a gray area between accept-unconditionally and reject-unconditionally, involving various devices like rate-limiting.) > Once we have a system that ensures that mail is not forged, and comes > from a MTA that is authorized by the domain to which it belongs, I > believe we have enough. Not everyone will agree with you... > If this domain is ill-behaved, it will rather soon get blacklisted at > spamhaus.org, ROKSO, (put the name of your favourite spam-operations > blacklist here), and we can soon stop accepting mail from it. ... a particular kind of reputation service which I'm sure will continue... > I don't believe that spammers can eternally keep on purchasing tens of > throw-away domains and change hosting or "their legitimate spam-sending > servers" everyday. Time will tell... > In this regard, reactive blacklists seems to me to be more useful than > "accreditation services". Reactive blacklists are one kind of reputation service. The importance of accreditation services is to allow a mechanism to automate recovery from listing by reactive blacklists. >> Yes, there will be costs associated with getting accreditation services >> to (favorably) list you. I believe we can minimize those costs; and I >> believe we can make it possible for many domains to avoid even minimal >> costs, so long as they're "well-behaved". > > Hummm... I think we yet have to see this. And I sincerely wonder if > every little business and shop-around-the-corner will get its domain > listed by such "accreditation services". Most likely not... until they run afoul of blacklists. > If they don't (and they mostly won't), then accreditation services > won't be of that much use, as you will never be able to reject mail > from all-the-domains-that-are-not-listed, just as today it is > impractical to reject mail from all the MTAs which doesn't have any > PTR in-addr record. I don't believe anyone in MARID is seriously proposing to reject all email which isn't listed. (The closest I've heard of is delaying email which doesn't come from a "listed" MTA; and that wasn't proposed for everyone: just for a few domains in order to jump-start implementation.) >> Conceivably, Michel would actually prefer to spend time trying to >> convince a swarm of "free" services to de-list an IP range, rather >> than to pay a few dollars to one accreditation service. Personally, >> I doubt that's the majority opinion... > > The best would be not to be listed at all ;-) Not always possible... > I already have lost some hours a couple of times trying to get delisted, > sometimes from some ISPs "internal" blacklists that had listed a > complete /16 or the like, and usually, being polite and professional is > enough to succeed quickly. "Usually" may not be good enough; and "some hours" may be more expensive for some than for others. (Not to mention the cases where you don't even learn which service is blacklisting you.) > Blacklists that keep you listed for no reason and refuse to delist you > forever, yes, there are some (check my IP at openrbl.org, you'll find > ONE that keeps a /16 listed and refuses to hear about delisting > innocents), but such unprofessional blacklists are seldom used by > serious companies for mail filtering. That they're used at all can be a problem. >>> IMHO, one should be deemed innocent until proved guilty, and the >>> "accreditation services" system turn the things upside-down : One >>> will be presumed guilty unless listed as innocent. Bad, bad, bad. >> >> I don't see that kind of "accreditation service" as useful -- >> though I agree it's going to happen. I believe we can best avoid it >> by offering a better alternative. > > ...which would be...? ...accreditation services which list you favorably at minimal charge until abuse is discovered. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 07:40:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21882 for ; Mon, 9 Aug 2004 07:40:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79BNKax060696; Mon, 9 Aug 2004 04:23: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 i79BNK7F060695; Mon, 9 Aug 2004 04:23:20 -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 i79BNIUM060686 for ; Mon, 9 Aug 2004 04:23:19 -0700 (PDT) (envelope-from shevek@astray.com) Received: from shevek (helo=localhost) by kanga.astray.com with local-esmtp (Exim 4.12) id 1Bu8FE-0000KU-00 for ietf-mxcomp@imc.org; Mon, 09 Aug 2004 12:23:12 +0100 Date: Mon, 9 Aug 2004 12:23:12 +0100 (BST) From: Shevek X-X-Sender: shevek@astray.com To: ietf-mxcomp@imc.org Subject: Re: Does marid-submitter-02 really make sense? In-Reply-To: <01LDAWC6X2SQ00005R@mauve.mrochek.com> Message-ID: References: <20040805164027.GA2443@danisch.de> <01LDAWC6X2SQ00005R@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 5 Aug 2004 ned.freed@mrochek.com wrote: > > Does the SUBMITTER parameter really make sense? > > > Case 1: The sender is authorized by some domain to > > send messages. The message will have to be accepted and therefore > > to be transmitted. No benefit in checking the parameter before > > transmission. Could do this also after transmission. > > Maybe, maybe not. Having the information early might in some MTAs allow for > throughput optimizations. You are proposing an optimisation of what will become the rare failure case. That's like optimising printing the 'bad password' message. It never happens. I agree with Hadmut. I don't think it's worth changing SMTP to introduce a new field to optimise what will soon become a fringe case. However, I also disagree with the introduction of any new header fields. S. -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 07: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 HAA22193 for ; Mon, 9 Aug 2004 07:51: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 i79BYs3e061860; Mon, 9 Aug 2004 04:34:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79BYsr9061858; Mon, 9 Aug 2004 04:34:54 -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 i79BYrwd061851 for ; Mon, 9 Aug 2004 04:34:53 -0700 (PDT) (envelope-from shevek@astray.com) Received: from shevek (helo=localhost) by kanga.astray.com with local-esmtp (Exim 4.12) id 1Bu8QY-0000m5-00 for ietf-mxcomp@imc.org; Mon, 09 Aug 2004 12:34:54 +0100 Date: Mon, 9 Aug 2004 12:34:54 +0100 (BST) From: Shevek X-X-Sender: shevek@astray.com To: ietf-mxcomp@imc.org Subject: Re: Will Accepting SUBMITTER Get You Blacklisted? 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 Sat, 7 Aug 2004, Michael R. Brumm wrote: > Here's a little problem I see with implementing SUBMITTER on an MTA... > let me know if I'm wrong on anything. > > First, let's assume a domain "allows-submitter.com", who has MTAs which > allow SUBMITTER to be specified on the "MAIL FROM" command. > > connection to mx2.allows-submitter.com > ------ > MAIL FROM: recipient@target.com SUBMITTER=hostile@throw-away.com > RCPT TO: invalid@allows-submitter.com > DATA > (includes virus or spam as payload) > > When mx2 tries to relay to mx1 (the primary MTA), mx1 rejects the > message because "invalid@allows-submitter.com" doesn't exist (or has > mailbox full, etc...). Now, mx2 sends a DSN (attaching the payload) to > "recipient@target.com". > > "recipient@target.com" (and probably a lot of other recipients in a lot > of other domains) is now receiving spam/viruses from <> > (postmaster@allows-submitter.com) and SPF evaluation proves that it is > coming from "allows-submitter.com". > > Am I missing anything? The problem illustrated here is that junk mail [containing an arbitrary payload] can be forwarded via a non-malicious mail server to an arbitrary address. This is currently a major problem on the internet: I see thousands of these bounces a day. The original design of SPF/Classic, which is now the design of Unified-SPF/Mail-From was intended to prevent this case. It is clear to see that the design would be successful in this aim. It is a source of increasing disappointment to me that this working group has turned away from these technically sound proposals in favour of more complex, less technically sound, and less clearly directed proposals which do not have the capability to prevent this relaying. S. -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 08:45: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 IAA26111 for ; Mon, 9 Aug 2004 08:45: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 i79CW6A1067263; Mon, 9 Aug 2004 05: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 i79CW66F067262; Mon, 9 Aug 2004 05:32:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79CW4dH067245 for ; Mon, 9 Aug 2004 05:32:05 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i79CVuHW012246 for ; Mon, 9 Aug 2004 13:31:56 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i79CVuNq012245; Mon, 9 Aug 2004 13:31:56 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Will Accepting SUBMITTER Get You Blacklisted? References: From: Graham Murray Date: Mon, 09 Aug 2004 13:31:55 +0100 In-Reply-To: (Shevek's message of "Mon, 9 Aug 2004 12:34:54 +0100 (BST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Shevek writes: > The original design of SPF/Classic, which is now the design of > Unified-SPF/Mail-From was intended to prevent this case. It is clear to > see that the design would be successful in this aim. > > It is a source of increasing disappointment to me that this working group > has turned away from these technically sound proposals in favour of more > complex, less technically sound, and less clearly directed proposals which > do not have the capability to prevent this relaying. I agree. But maybe there is room for both. First perform the SPF Mail-From checks (to verify the mail comes from the sender domain it claims), so that any subsequent bounces are not sent to innocent parties, and only if these pass continue to the 'responsible sender' checks to ensure that the RFC2822 'sender' is compatible with the MTA which originated the mail to detect phishing etc. From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 09:09:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27402 for ; Mon, 9 Aug 2004 09:09:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79CtNI2068859; Mon, 9 Aug 2004 05: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 i79CtNGU068858; Mon, 9 Aug 2004 05:55:23 -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 i79CtM8f068843 for ; Mon, 9 Aug 2004 05:55:22 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 17167 invoked from network); 9 Aug 2004 12:56:58 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 9 Aug 2004 12:56:58 -0000 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: <20040805164027.GA2443@danisch.de> <01LDAWC6X2SQ00005R@mauve.mrochek.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5EA09902-EA03-11D8-86C5-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit From: Margaret Olson Subject: Re: Does marid-submitter-02 really make sense? Date: Mon, 9 Aug 2004 08:55:20 -0400 To: Shevek , 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 Aug 9, 2004, at 7:23 AM, Shevek wrote: > > On Thu, 5 Aug 2004 ned.freed@mrochek.com wrote: > >>> Does the SUBMITTER parameter really make sense? >> >>> Case 1: The sender is authorized by some domain to >>> send messages. The message will have to be accepted and therefore >>> to be transmitted. No benefit in checking the parameter before >>> transmission. Could do this also after transmission. >> >> Maybe, maybe not. Having the information early might in some MTAs >> allow for >> throughput optimizations. > > You are proposing an optimisation of what will become the rare failure > case. That's like optimising printing the 'bad password' message. It > never > happens. > The advantage to SUBMITTER is more obvious in combination with reputation and accreditation. It lets you start the accreditation/reputation check early, either before accepting data or in parallel with the PRA check in the headers. Margaret. From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 10:01: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 KAA29776 for ; Mon, 9 Aug 2004 10:01: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 i79DjLqd072523; Mon, 9 Aug 2004 06:45: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 i79DjLZ7072522; Mon, 9 Aug 2004 06:45:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79DjJDU072515 for ; Mon, 9 Aug 2004 06:45:20 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i79DjGMt020856 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 9 Aug 2004 09:45:19 -0400 Subject: Another reason for sender_agents From: Mark Shewmaker To: ietf-mxcomp@imc.org Content-Type: text/plain Message-Id: <1092059299.19690.579.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 09 Aug 2004 09:48:20 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Mon, 09 Aug 2004 09:45:21 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Summary: Putting sender_agents into the spec would allow for the classic SPF and updated Sender-ID tests to separately authenticate the one (and different) thing they each authenticate, and authenticate that one thing well. Whether an incoming email has a forged bounce address is a different question from whether it has body forged header information. SPF classic with SRS gave recipients a pre-DATA test for forged bounce addresses, but SPF classic with SPF by itself gives recipients no tests for forged header info. Sender-ID gives recipients a post-DATA test(1) for some forged header info, but Sender-ID by itself gives recipients no way to test for forged bounce addresses.(2) These two tests test for different things--why not do both? 1. If we do classic SPF tests, (and do SRS on forwarding and SES/BATV-at-source), then: A. Recipients can know when they can safely bounce messages, and reject those that fail SPF tests. B. Senders can implement SES/BATV on all their new outgoing messages, so that they will never be a victim of receiving bounce forgeries directed at their domain. (Other than from denial-of-service types of attacks.) So both senders and recipients have ways to avoid being victims of forged bounces. (At least when the return-path domain participates.) 2. Then if sender_agents is added to Sender-ID and we do Sender-ID tests on the body headers, we'll have solved the phishing problem, (among domains who care to participate, at least.) --> But you *have* to have something like sender_agents, (or digital --> signatures) to do this sort of full anti-phishing test. With the above mindset, we're doing SPF tests to authenticate the return-path, and Sender-ID-with-sender-agents tests to authenticate the forwarding-hop-path.(4) We can do the SPF test before DATA, but since we can't do the complete Sender-ID tests until after DATA anyway, a SUBMITTER "sneak peak" doesn't isn't really needed--we could simply get rid of SUBMITTER altogether(3), and Sender-ID-looking-in-the-headers will still continue to work fine. Using SRS for classic-spf checks doesn't require a change in the SMTP protocol, or a new keyword to be added to the protocol, nor is a layer-violation, as it were, between 2821 and 2822. IMHO, this is a much cleaner solution than trying to get one or the other of those two types of tests to test both types of things. But you need sender_agents to do the end-to-end anti-phishing test. Notes: (1) Even with SUBMITTER, you have to wait until after DATA to see if SUBMITTER really matched up with the PRA. (2) With both classic SPF and Sender-ID, *Senders* can use SES, (or BATV) to prevent forged bounces from reaching *them*. That's all fine and good (and I've long been for it), but it still requires *recipients* to do a callback-verification test, which takes a lot longer than SPF classic type tests. (3) If you still want SUBMITTER for other reasons, there's no need to get rid of it--but there's no need to *require* it for Sender-ID or have flag days or the like. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 12: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 MAA08021 for ; Mon, 9 Aug 2004 12: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 i79FhL9K082855; Mon, 9 Aug 2004 08: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 i79FhL8H082854; Mon, 9 Aug 2004 08:43:21 -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 i79FhEVv082834 for ; Mon, 9 Aug 2004 08:43:20 -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 i79FhA9w013305 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 9 Aug 2004 08:43:11 -0700 Date: Mon, 9 Aug 2004 08:43:10 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Chris Haynes cc: IETF MARID WG Subject: Re: Security issue: Minority installed base of compatible MUAs? In-Reply-To: <04dc01c47c6d$8f1739c0$0200000a@ringo> Message-ID: References: <04dc01c47c6d$8f1739c0$0200000a@ringo> 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, 7 Aug 2004, Chris Haynes wrote: > The draft states that "in order to avoid this attack, MUAs will need to start > displaying at least the header that was verified". > > My concern is the need for new MUA purchases. Why can't the server-side check modify the message to display the results in an MUA-compatible way similar to the way that SpamAssassin modifies bodies and (optionally) headers today? -Rand From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 12:08: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 MAA08544 for ; Mon, 9 Aug 2004 12:08: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 i79FhJOm082847; Mon, 9 Aug 2004 08: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 i79FhJga082846; Mon, 9 Aug 2004 08:43:19 -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 i79FhIYj082838 for ; Mon, 9 Aug 2004 08:43:18 -0700 (PDT) (envelope-from shevek@astray.com) Received: from shevek (helo=localhost) by kanga.astray.com with local-esmtp (Exim 4.12) id 1BuCIy-000347-00 for ietf-mxcomp@imc.org; Mon, 09 Aug 2004 16:43:20 +0100 Date: Mon, 9 Aug 2004 16:43:20 +0100 (BST) From: Shevek X-X-Sender: shevek@astray.com To: ietf-mxcomp@imc.org Subject: Re: Will Accepting SUBMITTER Get You Blacklisted? 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 Mon, 9 Aug 2004, Graham Murray wrote: > > Shevek writes: > > > The original design of SPF/Classic, which is now the design of > > Unified-SPF/Mail-From was intended to prevent this case. It is clear to > > see that the design would be successful in this aim. > > > > It is a source of increasing disappointment to me that this working group > > has turned away from these technically sound proposals in favour of more > > complex, less technically sound, and less clearly directed proposals which > > do not have the capability to prevent this relaying. > > I agree. > > But maybe there is room for both. First perform the SPF Mail-From > checks (to verify the mail comes from the sender domain it claims), so > that any subsequent bounces are not sent to innocent parties, and only > if these pass continue to the 'responsible sender' checks to ensure > that the RFC2822 'sender' is compatible with the MTA which originated > the mail to detect phishing etc. In which case we must persuade Meng to put the Unified-SPF drafts back on the table for discussion instead of simply gesticulating in the general direction and annoying the chairs. I request a formal submission. S. -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 13:19: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 NAA15252 for ; Mon, 9 Aug 2004 13:19: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 i79GwStq090336; Mon, 9 Aug 2004 09:58: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 i79GwS4M090335; Mon, 9 Aug 2004 09:58:28 -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 i79GwRUE090329 for ; Mon, 9 Aug 2004 09:58:27 -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 1BuDTh-0000pk-00 for ietf-mxcomp@imc.org; Mon, 09 Aug 2004 17:58:29 +0100 Message-ID: <004701c47e31$ca1b98c0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <04dc01c47c6d$8f1739c0$0200000a@ringo> Subject: Re: Security issue: Minority installed base of compatible MUAs? Date: Mon, 9 Aug 2004 17:56:15 +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 "Rand Wacker" replied: > On Sat, 7 Aug 2004, Chris Haynes wrote: > > > The draft states that "in order to avoid this attack, MUAs will need to start > > displaying at least the header that was verified". > > > > My concern is the need for new MUA purchases. > > Why can't the server-side check modify the message to display the results > in an MUA-compatible way similar to the way that SpamAssassin modifies > bodies and (optionally) headers today? > > -Rand > > Could you please supply an example of the modifications you propose in such a way that: 1) It is displayable in Outlook Express 2) The display could not have been forged by the sender Thanks, Chris From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 13:52: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 NAA18991 for ; Mon, 9 Aug 2004 13:52: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 i79HXo8A093804; Mon, 9 Aug 2004 10:33: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 i79HXosd093803; Mon, 9 Aug 2004 10:33:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79HXoK2093788 for ; Mon, 9 Aug 2004 10:33:50 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LDCUYJ20CW00005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Mon, 09 Aug 2004 10:33:48 -0700 (PDT) Date: Mon, 09 Aug 2004 10:23:32 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Does marid-submitter-02 really make sense? In-reply-to: "Your message dated Mon, 09 Aug 2004 12:23:12 +0100 (BST)" To: Shevek Cc: ietf-mxcomp@imc.org Message-id: <01LDGH6S5X5800005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040805164027.GA2443@danisch.de> <01LDAWC6X2SQ00005R@mauve.mrochek.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > > > Does the SUBMITTER parameter really make sense? > > > Case 1: The sender is authorized by some domain to > > > send messages. The message will have to be accepted and therefore > > > to be transmitted. No benefit in checking the parameter before > > > transmission. Could do this also after transmission. > > Maybe, maybe not. Having the information early might in some MTAs allow for > > throughput optimizations. > You are proposing an optimisation of what will become the rare failure > case. That's like optimising printing the 'bad password' message. It never > happens. First, I am not proposing anything here. Not only is SUBMITTER not my idea, I have been quite clear that I am ambivalent about its inclusion in MARID. Second, the optimization in case 1 isn't a failure case but a success case. There may be a throughput improvement in some MTAs if the check can be done sooner. Mind you, I'm not saying there is guaranteed to be such an improvement - just that it is a possibility. Actual implementation experience would be needed to tell for sure. > I agree with Hadmut. I don't think it's worth changing SMTP to introduce a > new field to optimise what will soon become a fringe case. However, I also > disagree with the introduction of any new header fields. My objection to the use of a new header field for this was and continues to be the primary reason for participating in this thread. Unlike the SMTP extension, where there may be an upside and there's likely little if any downside, the header field notion is stamped "bad idea" right out of the box. Ned From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 14:55: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 OAA26994 for ; Mon, 9 Aug 2004 14:55: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 i79Ib0FQ000669; Mon, 9 Aug 2004 11:37: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 i79Ib0MJ000668; Mon, 9 Aug 2004 11:37:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Iawr5000657 for ; Mon, 9 Aug 2004 11:36:59 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Mon, 9 Aug 2004 20:33:46 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Aug 2004 19:16:17 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 19:18:16 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Aug 2004 19:15:39 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79GwStq090336; Mon, 9 Aug 2004 09:58: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 i79GwS4M090335; Mon, 9 Aug 2004 09:58:28 -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 i79GwRUE090329 for ; Mon, 9 Aug 2004 09:58:27 -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 1BuDTh-0000pk-00 for ietf-mxcomp@imc.org; Mon, 09 Aug 2004 17:58:29 +0100 Message-ID: <004701c47e31$ca1b98c0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <04dc01c47c6d$8f1739c0$0200000a@ringo> Subject: Re: Security issue: Minority installed base of compatible MUAs? Date: Mon, 9 Aug 2004 17:56:15 +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 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 09 Aug 2004 17:15:39.0475 (UTC) FILETIME=[7E402A30:01C47E34] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "Rand Wacker" replied: > On Sat, 7 Aug 2004, Chris Haynes wrote: > > > The draft states that "in order to avoid this attack, MUAs will need to start > > displaying at least the header that was verified". > > > > My concern is the need for new MUA purchases. > > Why can't the server-side check modify the message to display the results > in an MUA-compatible way similar to the way that SpamAssassin modifies > bodies and (optionally) headers today? > > -Rand > > Could you please supply an example of the modifications you propose in such a way that: 1) It is displayable in Outlook Express 2) The display could not have been forged by the sender Thanks, Chris From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 14:58:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27364 for ; Mon, 9 Aug 2004 14:58:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79IaiTJ000638; Mon, 9 Aug 2004 11:36: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 i79Iain0000637; Mon, 9 Aug 2004 11:36:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Iagva000626 for ; Mon, 9 Aug 2004 11:36:43 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Mon, 9 Aug 2004 20:33:45 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Aug 2004 17:58:47 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 18:00:45 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Aug 2004 17:56:28 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79FhL9K082855; Mon, 9 Aug 2004 08: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 i79FhL8H082854; Mon, 9 Aug 2004 08:43:21 -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 i79FhEVv082834 for ; Mon, 9 Aug 2004 08:43:20 -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 i79FhA9w013305 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 9 Aug 2004 08:43:11 -0700 Date: Mon, 9 Aug 2004 08:43:10 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Chris Haynes cc: IETF MARID WG Subject: Re: Security issue: Minority installed base of compatible MUAs? In-Reply-To: <04dc01c47c6d$8f1739c0$0200000a@ringo> Message-ID: References: <04dc01c47c6d$8f1739c0$0200000a@ringo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 09 Aug 2004 15:56:28.0633 (UTC) FILETIME=[6E873490:01C47E29] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 7 Aug 2004, Chris Haynes wrote: > The draft states that "in order to avoid this attack, MUAs will need to start > displaying at least the header that was verified". > > My concern is the need for new MUA purchases. Why can't the server-side check modify the message to display the results in an MUA-compatible way similar to the way that SpamAssassin modifies bodies and (optionally) headers today? -Rand From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 15:12:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29446 for ; Mon, 9 Aug 2004 15:12: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 i79IvPZ2003447; Mon, 9 Aug 2004 11:57: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 i79IvP6Z003446; Mon, 9 Aug 2004 11:57:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79IvNlL003424 for ; Mon, 9 Aug 2004 11:57:24 -0700 (PDT) (envelope-from ietf-mxcomp@anarres.org) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Mon, 9 Aug 2004 20:53:00 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Aug 2004 18:07:51 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 18:09:45 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Aug 2004 18:04:15 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79FhJOm082847; Mon, 9 Aug 2004 08: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 i79FhJga082846; Mon, 9 Aug 2004 08:43:19 -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 i79FhIYj082838 for ; Mon, 9 Aug 2004 08:43:18 -0700 (PDT) (envelope-from shevek@astray.com) Received: from shevek (helo=localhost) by kanga.astray.com with local-esmtp (Exim 4.12) id 1BuCIy-000347-00 for ietf-mxcomp@imc.org; Mon, 09 Aug 2004 16:43:20 +0100 Date: Mon, 9 Aug 2004 16:43:20 +0100 (BST) From: Shevek X-X-Sender: shevek@astray.com To: ietf-mxcomp@imc.org Subject: Re: Will Accepting SUBMITTER Get You Blacklisted? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 09 Aug 2004 16:04:16.0035 (UTC) FILETIME=[851F1730:01C47E2A] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 9 Aug 2004, Graham Murray wrote: > > Shevek writes: > > > The original design of SPF/Classic, which is now the design of > > Unified-SPF/Mail-From was intended to prevent this case. It is clear to > > see that the design would be successful in this aim. > > > > It is a source of increasing disappointment to me that this working group > > has turned away from these technically sound proposals in favour of more > > complex, less technically sound, and less clearly directed proposals which > > do not have the capability to prevent this relaying. > > I agree. > > But maybe there is room for both. First perform the SPF Mail-From > checks (to verify the mail comes from the sender domain it claims), so > that any subsequent bounces are not sent to innocent parties, and only > if these pass continue to the 'responsible sender' checks to ensure > that the RFC2822 'sender' is compatible with the MTA which originated > the mail to detect phishing etc. In which case we must persuade Meng to put the Unified-SPF drafts back on the table for discussion instead of simply gesticulating in the general direction and annoying the chairs. I request a formal submission. S. -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 15: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 PAA05236 for ; Mon, 9 Aug 2004 15:51: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 i79JRglo006905; Mon, 9 Aug 2004 12:27:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79JRgnJ006904; Mon, 9 Aug 2004 12:27:42 -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 i79JReo4006876 for ; Mon, 9 Aug 2004 12:27:40 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BuFo1-0004tb-00 for ; Mon, 09 Aug 2004 21:27:39 +0200 Received: from 62.80.58.242 ([62.80.58.242]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Aug 2004 21:27:37 +0200 Received: from nobody by 62.80.58.242 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Aug 2004 21:27:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Will Accepting SUBMITTER Get You Blacklisted? Date: Mon, 09 Aug 2004 21:22:22 +0200 Organization: Lines: 56 Message-ID: <4117CEEE.5605@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.242 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 Graham Murray wrote: > maybe there is room for both. First perform the SPF Mail-From > checks (to verify the mail comes from the sender domain it > claims), so that any subsequent bounces are not sent to > innocent parties So far I fully agree with you... > only if these pass continue to the 'responsible sender' > checks to ensure that the RFC2822 'sender' is compatible > with the MTA which originated the mail to detect phishing > etc. ...but I don't understand this part. What do you want to do if the MAIL FROM test was inconclusive, neither PASS nor FAIL ? MUAs should display a "PRA" (as specified in core-02 7.5), and this allows users to detect phishing. And this feature does not depend on any 2822 header tests by the MX / MDA, the MUA can evaluate all corresponding headers: Resent-Sender / Resent-From / Sender / From in this order, and if found one address in this header should match the MAIL FROM, and that's the "PRA". If there's only a From: header and it doesn't match MAIL FROM, then treat the MAIL FROM address as "PRA", to be compatible with 2476 MSAs if they "forgot" to insert a matching Sender. After this check the MUA has a "PRA" matching the MAIL FROM, or a dubious mail (e.g. From !~ Sender !~ MAIL FROM !~ From). If it has a "PRA" it can display it with the SPF result found in the SPF classic header Received-SPF: (PASS, SOFTFAIL, ERROR, UNKNOWN, but probably not FAIL, that should be handled before and never reach a MUA). So there's only one problem, MUAs must know who generated the Received-SPF, the phisher or their own mail provider. But in theory this could be configured per mail account, when users enter their mail address / password / host names / etc. I still don't get the idea why the MX should determine a "PRA", only the MUA wants to know and display this. The info passed from MX to MUA must be in a new header (or in a new parameter of the Received: header). No existing MUA knows this new header / parameter. Therefore it only works with new MUAs. If that's the case this new MUA can do the simple "PRA" check, and display it together with the SPF result found in a new Received-SPF. The MX cannot finally judge phishing problems, it's only a machine. But the MUA has a human user. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 17:25: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 RAA19938 for ; Mon, 9 Aug 2004 17:25:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79L9pUA016970; Mon, 9 Aug 2004 14:09: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 i79L9pcN016969; Mon, 9 Aug 2004 14:09:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79L9oDx016961 for ; Mon, 9 Aug 2004 14:09:51 -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); Mon, 9 Aug 2004 14:09:55 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Aug 2004 14:09:55 -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, 9 Aug 2004 14:09:54 -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); Mon, 9 Aug 2004 14:09:55 -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: Does marid-submitter-02 really make sense? Date: Mon, 9 Aug 2004 14:09:57 -0700 Message-ID: Thread-Topic: Does marid-submitter-02 really make sense? Thread-Index: AcR+ORUq6d22/V4KTgSNMbke2aaEhAAGunZQ From: "Harry Katz" To: , "Shevek" Cc: X-OriginalArrivalTime: 09 Aug 2004 21:09:55.0324 (UTC) FILETIME=[383083C0:01C47E55] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i79L9pDx016963 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, August 09, 2004 10:24 AM ned.freed@mrochek.com wrote: > First, I am not proposing anything here. Not only is > SUBMITTER not my idea, I have been quite clear that I am > ambivalent about its inclusion in MARID. > > Second, the optimization in case 1 isn't a failure case but a > success case. > There may be a throughput improvement in some MTAs if the > check can be done sooner. Mind you, I'm not saying there is > guaranteed to be such an improvement > - just that it is a possibility. Actual implementation > experience would be needed to tell for sure. > Ned is exactly correct here. The purpose of SUBMITTER is to allow early (i.e. at 2821-time) verification of the sender's identity, namely the PRA. At the IETF meetings last week there was some discussion of whether this would result in bandwidth saving, throughput improvement, or no benefit at all. I tend to think there will be modest throughput improvement, but agree with Ned that we need to verify through testing. From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 18:09: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 SAA25031 for ; Mon, 9 Aug 2004 18:09: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 i79Lrcdk022381; Mon, 9 Aug 2004 14:53:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79Lrc1e022380; Mon, 9 Aug 2004 14:53: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 i79LrZFE022367 for ; Mon, 9 Aug 2004 14:53:37 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.156] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id A790340E0 for ; Mon, 9 Aug 2004 14:53:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <90BAE9AA-EA4E-11D8-A694-000393A56BB6@glyphic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Mark Lentczner Subject: Upcoming changes in protocol draft Date: Mon, 9 Aug 2004 14:53:36 -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 Friends - Here is a partial list of changes that I've made for draft-ietf-marid-protocol-01: Major Changes * Adjusted domain-spec and macro-string ABNF to remove ambiguity about slash and percent characters, and the ambiguity with domain names * Specified handling of DNS server errors during mechanism evaluation * Changed recommendation to keeping name and record combined length less than 460 characters to keep with the DNS UDP limit of 512 octets Descriptive Changes * Changed the title to: "The Sender-ID Record: Format and Interpretation" * Added a statement about URLs to the Security Considerations, and additional information in the exp= modifier * Added a statement about publishing of wildcard records * Added a statement about location of records * Clarified discussion of expansions for exp modifier * Clarified discussion of splitting on delimiters in macro expansion * Clarified definition of SoftFail * Reformatted the table describing "include" processing results Minor Changes * Reformatted using xml2rfc. This resulted in several changes: - boilerplate text and formatting improved - some slight changes in the ascii artwork - minor formatting changes * Spelling fixes and minor grammar fixes In addition, I'm still working on these changes: * Change the version string, add a minor version number field * Add a statement about new mechanisms * Add information from DNS-EXT folks * Add IANA info to request new RR type I expect all of this to be done and submitted to the draft editor by end of day Friday. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 19:37: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 TAA03605 for ; Mon, 9 Aug 2004 19:37:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79NEo1P031282; Mon, 9 Aug 2004 16:14: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 i79NEoTL031281; Mon, 9 Aug 2004 16:14: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 i79NEmC5031255 for ; Mon, 9 Aug 2004 16:14: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 63DAC132CD1 for ; Mon, 9 Aug 2004 19:18:06 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id AB5575AC; Mon, 9 Aug 2004 19:14:52 -0400 (EDT) Date: Mon, 9 Aug 2004 19:14:52 -0400 From: Meng Weng Wong To: IETF MARID WG Subject: change of version string Message-ID: <20040809231452.GF28401@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: First of all, thanks Mark for a whole lot of work! At the WG meeting in San Diego, a number of arguments were cogently advanced regarding the change of version string. I would like to comment on the proposed change. Because v=spf1 strings were semantically associated with the 2821.mail-from parameter, and because Sender ID prefers the 2822.PRA/2821.SUBMITTER above 2821.mail-from, a change of version string (to v=spf2 or suchlike) was proposed. This change is intended to disambiguate SPF Classic from Sender ID, to accommodate sender domains whose policies regarding the PRA might differ from their policies regarding the mail-from. While such a change is, from the standpoint of architectural purity, absolutely the correct thing to do, I fear that in practice it may lead to confusion, needless duplication of records, and a failure to achieve the intended objective. In other words, it is my opinion that engineering considerations do not weigh in favour of changing the string. I particularly do not want to see a world where the norm is: example.com TXT "v=spf1 a mx ptr" example.com TXT "v=spf2 a mx ptr" Both records would contain the same content, yet senders might feel the need to publish both "just to be on the safe side". Assuming that the email ecosystem adopts the recommendations of this working group, I believe that the number of scenarios which would benefit from a distinction between v=spf1 and v=spf2 is practically nil. If I am right, and if we change the string, I fear that implementors will complain that we have inconvenienced them gratuitously. While it is true that anyone who has already implemented SPF Classic will need to make a number of changes in response to PRA and SUBMITTER, changes that relate to the version string are of a different order. Therefore, I recommend that we do not change the version string. To accommodate the rare (and so far hypothetical) cases where disambiguation is desired, we can instead define a scope modifier or scope macro which will serve the same function at a much lower cost. I do not feel particularly strongly about this. If the working group as a whole feels that changing the string is a wiser course of action than not changing it, I will not press my objection further, especially in light of the deadlines. I just want to share a point of view which I feel is underrepresented. From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 20:05: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 UAA05939 for ; Mon, 9 Aug 2004 20:05:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Nmpo8033943; Mon, 9 Aug 2004 16:48: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 i79NmpEv033942; Mon, 9 Aug 2004 16:48:51 -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 i79Nmoeu033935 for ; Mon, 9 Aug 2004 16:48:51 -0700 (PDT) (envelope-from shevek@astray.com) Received: from shevek (helo=localhost) by kanga.astray.com with local-esmtp (Exim 4.12) id 1BuJst-0003qz-00 for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 00:48:55 +0100 Date: Tue, 10 Aug 2004 00:48:55 +0100 (BST) From: Shevek X-X-Sender: shevek@astray.com To: ietf-mxcomp@imc.org Subject: RE: Does marid-submitter-02 really make sense? 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 Mon, 9 Aug 2004, Harry Katz wrote: > On Monday, August 09, 2004 10:24 AM ned.freed@mrochek.com wrote: > > > First, I am not proposing anything here. Not only is > > SUBMITTER not my idea, I have been quite clear that I am > > ambivalent about its inclusion in MARID. > > > > Second, the optimization in case 1 isn't a failure case but a > > success case. > > There may be a throughput improvement in some MTAs if the > > check can be done sooner. Mind you, I'm not saying there is > > guaranteed to be such an improvement > > - just that it is a possibility. Actual implementation > > experience would be needed to tell for sure. > > Ned is exactly correct here. The purpose of SUBMITTER is to allow early > (i.e. at 2821-time) verification of the sender's identity, namely the > PRA. At the IETF meetings last week there was some discussion of > whether this would result in bandwidth saving, throughput improvement, > or no benefit at all. I tend to think there will be modest throughput > improvement, but agree with Ned that we need to verify through testing. This is incorrect. At 2821 time, we know only who the sender CLAIMS to be via SUBMITTER. It's not until after 2822 time, when we can compare the SUBMITTER value to the PRA value computed from the 2822 headers that we have verified the identity of the sender. S. -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 20:13: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 UAA06492 for ; Mon, 9 Aug 2004 20:13: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 i79NpGYg034098; Mon, 9 Aug 2004 16:51: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 i79NpGoO034097; Mon, 9 Aug 2004 16:51:16 -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 i79NpEeE034090 for ; Mon, 9 Aug 2004 16:51:16 -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 i79NpHj15838; Mon, 9 Aug 2004 16:51:17 -0700 Date: Mon, 9 Aug 2004 16:51:11 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <314387198.20040809165111@brandenburg.com> To: Mark Lentczner CC: IETF MARID WG Subject: Re: Upcoming changes in protocol draft In-Reply-To: <90BAE9AA-EA4E-11D8-A694-000393A56BB6@glyphic.com> References: <90BAE9AA-EA4E-11D8-A694-000393A56BB6@glyphic.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 Mark, ML> Here is a partial list of changes that I've made for ML> draft-ietf-marid-protocol-01: ... ML> * Changed the title to: ML> "The Sender-ID Record: Format and Interpretation" so, marid-protocol is not a protocol specification? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 20:54: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 UAA10306 for ; Mon, 9 Aug 2004 20:54:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0eSdI038303; Mon, 9 Aug 2004 17:40: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 i7A0eSjB038300; Mon, 9 Aug 2004 17:40:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0eQMq038182 for ; Mon, 9 Aug 2004 17:40:26 -0700 (PDT) (envelope-from millenix@zemos.net) Received: from fda.zemos.net (millenix-fda.no-ip.org[68.39.78.137]) by comcast.net (rwcrmhc12) with ESMTP id <2004081000402701400r9arle>; Tue, 10 Aug 2004 00:40:27 +0000 Received: from localhost (fda [127.0.0.1]) by fda.zemos.net (Postfix) with ESMTP id B09F318695; Mon, 9 Aug 2004 20:40:24 -0400 (EDT) Received: from fda.zemos.net ([127.0.0.1]) by localhost (fda.zemos.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12738-09; Mon, 9 Aug 2004 20:40:24 -0400 (EDT) Received: from [10.0.0.2] (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id 4B5EF18694; Mon, 9 Aug 2004 20:40:24 -0400 (EDT) Message-ID: <41181979.90001@zemos.net> Date: Mon, 09 Aug 2004 20:40:25 -0400 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040802 Debian/1.7.1-5 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Shevek Cc: ietf-mxcomp@imc.org Subject: Re: Does marid-submitter-02 really make sense? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at fda.zemos.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Shevek wrote: > On Mon, 9 Aug 2004, Harry Katz wrote: >>On Monday, August 09, 2004 10:24 AM ned.freed@mrochek.com wrote: >>>First, I am not proposing anything here. Not only is >>>SUBMITTER not my idea, I have been quite clear that I am >>>ambivalent about its inclusion in MARID. >>> >>>Second, the optimization in case 1 isn't a failure case but a >>>success case. >>>There may be a throughput improvement in some MTAs if the >>>check can be done sooner. Mind you, I'm not saying there is >>>guaranteed to be such an improvement >>>- just that it is a possibility. Actual implementation >>>experience would be needed to tell for sure. >> >>Ned is exactly correct here. The purpose of SUBMITTER is to allow early >>(i.e. at 2821-time) verification of the sender's identity, namely the >>PRA. At the IETF meetings last week there was some discussion of >>whether this would result in bandwidth saving, throughput improvement, >>or no benefit at all. I tend to think there will be modest throughput >>improvement, but agree with Ned that we need to verify through testing. > > This is incorrect. At 2821 time, we know only who the sender CLAIMS to be > via SUBMITTER. It's not until after 2822 time, when we can compare the > SUBMITTER value to the PRA value computed from the 2822 headers that we > have verified the identity of the sender. The idea is that the DNS lookup and check can be parallelized with the continuation of the mail transaction, and then the final response to the DATA payload will be sent when the PRA matches the SUBMITTER and the SUBMITTER is allowed by its domain's DNS record. Philip Miller From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 21:13: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 VAA11942 for ; Mon, 9 Aug 2004 21:13: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 i7A0uBHB040728; Mon, 9 Aug 2004 17:56: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 i7A0uBB4040727; Mon, 9 Aug 2004 17:56:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0uBAN040721 for ; Mon, 9 Aug 2004 17:56:11 -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); Mon, 9 Aug 2004 17:56:16 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Aug 2004 17:56:16 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Aug 2004 17:56:17 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 17:56:45 -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: Does marid-submitter-02 really make sense? Date: Mon, 9 Aug 2004 17:56:14 -0700 Message-ID: Thread-Topic: Does marid-submitter-02 really make sense? Thread-Index: AcR+bVljlaCyOYByQsiz/fRq+JpcNwABrjfQ From: "Harry Katz" To: "Shevek" , X-OriginalArrivalTime: 10 Aug 2004 00:56:45.0752 (UTC) FILETIME=[E8A30380:01C47E74] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7A0uBAN040722 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, August 09, 2004 4:49 PM Shevek wrote: > On Mon, 9 Aug 2004, Harry Katz wrote: > > > On Monday, August 09, 2004 10:24 AM ned.freed@mrochek.com wrote: > > > > > First, I am not proposing anything here. Not only is > SUBMITTER not > > > my idea, I have been quite clear that I am ambivalent about its > > > inclusion in MARID. > > > > > > Second, the optimization in case 1 isn't a failure case but a > > > success case. > > > There may be a throughput improvement in some MTAs if the > check can > > > be done sooner. Mind you, I'm not saying there is > guaranteed to be > > > such an improvement > > > - just that it is a possibility. Actual implementation experience > > > would be needed to tell for sure. > > > > Ned is exactly correct here. The purpose of SUBMITTER is to allow > > early (i.e. at 2821-time) verification of the sender's identity, > > namely the PRA. At the IETF meetings last week there was some > > discussion of whether this would result in bandwidth saving, > > throughput improvement, or no benefit at all. I tend to > think there > > will be modest throughput improvement, but agree with Ned > that we need to verify through testing. > > This is incorrect. At 2821 time, we know only who the sender > CLAIMS to be via SUBMITTER. It's not until after 2822 time, > when we can compare the SUBMITTER value to the PRA value > computed from the 2822 headers that we have verified the > identity of the sender. Actually, it is correct. From section 4.2 of the submitter-02 draft: If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed." 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." In other words, if SUBMITTER is present and fails the Sender ID check at 2821 time, then the message SHOULD be rejected. The subsequent matching of SUBMITTER to 2822 headers is only to confirm - if DATA is accepted - that the SMTP client didn't lie about the value. From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 21:13:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11976 for ; Mon, 9 Aug 2004 21:13:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A12UKL041296; Mon, 9 Aug 2004 18:02: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 i7A12UB2041295; Mon, 9 Aug 2004 18:02:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A12TmL041289 for ; Mon, 9 Aug 2004 18:02:29 -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); Mon, 9 Aug 2004 18:02:35 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Aug 2004 18:02:35 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Aug 2004 18:02:36 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 18:03:06 -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: Does marid-submitter-02 really make sense? Date: Mon, 9 Aug 2004 18:02:33 -0700 Message-ID: Thread-Topic: Does marid-submitter-02 really make sense? Thread-Index: AcR+dBhUND3q7c8PToyrDgA/c6MrzQAAOmQA From: "Harry Katz" To: "Philip Miller" , "Shevek" Cc: X-OriginalArrivalTime: 10 Aug 2004 01:03:06.0054 (UTC) FILETIME=[CB507E60:01C47E75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7A12TmL041290 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, August 09, 2004 5:40 PM Philip Miller wrote: > Shevek wrote: > > On Mon, 9 Aug 2004, Harry Katz wrote: > >>On Monday, August 09, 2004 10:24 AM ned.freed@mrochek.com wrote: > >>>First, I am not proposing anything here. Not only is > SUBMITTER not my > >>>idea, I have been quite clear that I am ambivalent about its > >>>inclusion in MARID. > >>> > >>>Second, the optimization in case 1 isn't a failure case > but a success > >>>case. > >>>There may be a throughput improvement in some MTAs if the > check can > >>>be done sooner. Mind you, I'm not saying there is guaranteed to be > >>>such an improvement > >>>- just that it is a possibility. Actual implementation experience > >>>would be needed to tell for sure. > >> > >>Ned is exactly correct here. The purpose of SUBMITTER is to allow > >>early (i.e. at 2821-time) verification of the sender's identity, > >>namely the PRA. At the IETF meetings last week there was some > >>discussion of whether this would result in bandwidth saving, > >>throughput improvement, or no benefit at all. I tend to > think there > >>will be modest throughput improvement, but agree with Ned > that we need to verify through testing. > > > > This is incorrect. At 2821 time, we know only who the > sender CLAIMS to > > be via SUBMITTER. It's not until after 2822 time, when we > can compare > > the SUBMITTER value to the PRA value computed from the 2822 headers > > that we have verified the identity of the sender. > > The idea is that the DNS lookup and check can be parallelized > with the continuation of the mail transaction, and then the > final response to the DATA payload will be sent when the PRA > matches the SUBMITTER and the SUBMITTER is allowed by its > domain's DNS record. Sure, that's one possible implementation choice, but not the only one. The spec recommends rejection if the SUBMITTER value fails the Sender ID check. Matching the SUBMITTER value to the 2822 headers is a separate requirement. From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 22:08: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 WAA17719 for ; Mon, 9 Aug 2004 22:08: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 i7A1nKWA045715; Mon, 9 Aug 2004 18: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 i7A1nKQ1045714; Mon, 9 Aug 2004 18:49:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A1nIf0045707 for ; Mon, 9 Aug 2004 18:49:18 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1BuLlT-000Bqw-00 for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 02:49:23 +0100 Message-ID: <010a01c47e7b$f5305880$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: Subject: Re: Does marid-submitter-02 really make sense? Date: Tue, 10 Aug 2004 02:47:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At Tuesday, August 10, 2004 12:48 AM "Shevek" objected: > > On Mon, 9 Aug 2004, Harry Katz wrote: > > > On Monday, August 09, 2004 10:24 AM ned.freed@mrochek.com wrote: > > > > > First, I am not proposing anything here. Not only is > > > SUBMITTER not my idea, I have been quite clear that I am > > > ambivalent about its inclusion in MARID. > > > > > > Second, the optimization in case 1 isn't a failure case but a > > > success case. > > > There may be a throughput improvement in some MTAs if the > > > check can be done sooner. Mind you, I'm not saying there is > > > guaranteed to be such an improvement > > > - just that it is a possibility. Actual implementation > > > experience would be needed to tell for sure. > > > > Ned is exactly correct here. The purpose of SUBMITTER is to allow early > > (i.e. at 2821-time) verification of the sender's identity, namely the > > PRA. At the IETF meetings last week there was some discussion of > > whether this would result in bandwidth saving, throughput improvement, > > or no benefit at all. I tend to think there will be modest throughput > > improvement, but agree with Ned that we need to verify through testing. > > This is incorrect. At 2821 time, we know only who the sender CLAIMS to be > via SUBMITTER. It's not until after 2822 time, when we can compare the > SUBMITTER value to the PRA value computed from the 2822 headers that we > have verified the identity of the sender. > > S. > > -- > Shevek http://www.anarres.org/ > I am the Borg. http://www.gothnicity.org/ > The situation is actually rather amazing, AFAICT. So long as a client has a SUBMITTER domain which can pass the receiver's 2821-time test, it will so arrange things that it will_never_ fail the SUBMITTER == PRA? test undertaken at 2822 time. The reason: Section 4.1 of submitter-02 states that clients "...MUST if necessary, insert ... RFC 2822 headers ... to .[make the PRA] .. match the SUBMITTER address". Now, if you look at step 1 of the PRA algorithm in core-02, the first non-empty Resent-Sender header can supply the PRA. There may be any number of subsequent Resent-Sender headers - the first one wins. So, if I were a client wishing to avoid the 'hassle' of bounces I would just automatically prepend all messages I sent with a Resent-Sender header containing the same as my SUBMITTER address. The PRA algorithm will always deduce this to be the PRA and so the 2822-time test will always be passed. It would not matter what the 'real' headers were in the message I was asked to send - I can always trump them with my SUBMITTER address in a leading Resent-Sender field. OK - this does not sound honest. But look again at section 4.1 of submitter-02. It *requires* the client to adjust the headers so that SUBMITTER and PRA match, and I have shown above that this can *always* be done. A rather smarter / honest / helpful client could use the PRA algorithm in reverse and try adding a From, or a Sender, or a Resent-From header in order to pass the PRA test in preference to just going straight for a Resent-Sender header. But why should it bother, and on what semantic basis should it / could it choose any of the other available headers to use? So, it appears to me that the two drafts combine to ensure that clients which can pass the SUBMITTER test at 2811 time should *never* fail the 2822-time test. In fact, a client which sends a message which then fails a 2822-time test is non-conformant to the drafts! HTH Chris Haynes From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 22:32: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 WAA19767 for ; Mon, 9 Aug 2004 22:32: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 i7A2Jkt6048988; Mon, 9 Aug 2004 19:19: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 i7A2JkPX048987; Mon, 9 Aug 2004 19:19:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A2Jj1U048981 for ; Mon, 9 Aug 2004 19:19:45 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7A2Jm8R019585; Mon, 9 Aug 2004 19:19:48 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 9 Aug 2004 19:19:48 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dave Crocker'" , Mark Lentczner Cc: IETF MARID WG Subject: RE: Upcoming changes in protocol draft Date: Mon, 9 Aug 2004 19:19: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: Fortunately, the resulting RFC will only have a number and the title. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Dave Crocker > Sent: Monday, August 09, 2004 7:51 PM > To: Mark Lentczner > Cc: IETF MARID WG > Subject: Re: Upcoming changes in protocol draft > > > > Mark, > > ML> Here is a partial list of changes that I've made for > ML> draft-ietf-marid-protocol-01: > ... > ML> * Changed the title to: > ML> "The Sender-ID Record: Format and Interpretation" > > > so, marid-protocol is not a protocol specification? > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > From owner-ietf-mxcomp@mail.imc.org Mon Aug 9 23:14: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 XAA23947 for ; Mon, 9 Aug 2004 23: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 i7A2wAup053847; Mon, 9 Aug 2004 19:58: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 i7A2wA3X053846; Mon, 9 Aug 2004 19:58:10 -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 i7A2w9pV053840 for ; Mon, 9 Aug 2004 19:58:09 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040810025809.EDTB19123.tomts20-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 9 Aug 2004 22:58:09 -0400 From: "John Glube" To: "'Harry Katz'" , , "'Shevek'" Cc: Subject: RE: Does marid-submitter-02 really make sense? Date: Mon, 9 Aug 2004 22:57:57 -0400 Message-ID: <012701c47e85$d80bab10$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7A2w9pV053841 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I have a couple of concerns and perhaps people can clarify matters. Based on my understanding of what transpired at last week's MARID WG meeting one of the issues surrounding Sender-ID is the implementation of Submitter in the 'wild.' My concern is whether in how we are approaching the problem we are creating a potential security issue for ourselves. Let me explain. My premise is that the spammer's objective is to find a security hole, be it at the authentication stage, (which may also include reputation and accreditation checks), or at the filtering stage and to exploit these gaps to allow for message delivery, while hiding his, her or its identity. This raises a number of problems: * Until the Submitter extension is widely implemented, those relying solely on PRA checks will have nothing to check, unless one allows for checking SMTP mail from in the absence of the Submitter extension. * Sending direct from the IP address to the recipient MX is the way a lot of spoofed and phishing messages are sent. This happened with the US Bank phish coming from a Chinese IP address, which was discussed at length on the MARID mailing list. Until the Submitter extension is widely implemented, those relying solely on PRA checks, would not have verified whether the SMTP mail from is malformed and so would have failed to reject this type of message during the authentication stage. (This is a short list. I know there are many more issues.) As a result: * By not checking whether the SMTP mail from is properly formed, and * By not checking the SMTP mail from and/or EHELO address for spoofing during the data transfer stage, Does this create a security problem, unless one says, we will reject email without a Submitter extension. Why? I go back to my original premise. A spammer who sends spoofed email or wants to go phishing has no interest in complying with the rules we write. Rather, he or she is seeking to utilize any 'security holes' we allow for message delivery. The problem? We can't say we will reject email without a Submitter extension because an implementation time frame is required. The argument has been put forward, yes but the gap is filled with the use of reputation and accreditation services. The concern is that reputation and accreditation services are not designed to thwart spoofing and the use of other technical means to hide a spammers identity, but rather to deal with whether the sender does or does not have a good reputation. A reputation service says in essence, this sender whom we can identify, based on past mailing practices has a good reputation. An accreditation service says in essence, based on our review of this sender's actual or proposed practices, we are satisfied this sender either: (i) has honourable intentions, if it is a market newcomer; or (ii) has a good history and in either case we are prepared to vouch for this sender whom you can identify. Oh and by the way, should it turn out this sender does not live up to his, her or its commitments, and we find out, either through our own means, or based on relationships we have, we will 'tar and feather the person':-) Without the ability to specifically identify the sender, are we not into blacklisting and filtering, along with the related collateral damage, which is a concern for the sending community and makes email unreliable for users. As such until: * there is sufficient implementation of Submitter in the wild; or * the receiving community says, want to send us email, you must use the Submitter extension, without calling for the use of a malformed SMTP mail from check, a spoofed SMTP mail from and an EHELO check, my concern is we have not moved towards the underlying objective of sender authentication which is to thwart spoofing and the use of other technical means to hide identity. The other concern involves the less developed parts of the world, and the use of the Internet infrastructure in these communities by spammers to play havoc. Do we know whether these communities can bear the cost if any of Submitter implementation? If we can rely on accreditation and reputation services to fill the gap, do we know whether 'legitimate' senders in under developed countries can realistically bear the cost of accessing accreditation services? Do we have any idea of a realistic time frame to allow for sufficient implementation of Submitter in these parts, so that receivers can fairly say, "we will require all email sent to us to have a Submitter extension by such and such a date?" I am not saying based on all these concerns this means we should reject Sender-ID. (In my view, crunch time will likely occur when MS comes forward with any IPR disclosure and the form of license, if any it may require and how this pans out.) What I am saying is either: * Allow for a draft of marid - core to come forward which takes these concerns into consideration; or, * If it is felt the better course is to keep the marid drafts pure, which is understandable, then we need to quickly move ahead with review and implementation of proposals like CSV and any others which directly confront these gaps. This will allow the receiving community if it wishes to receive a full stream of data sets and achieve the underlying objective of sender authentication, being to thwart spoofing and the use of other technical means to hide identity, while allowing prudent senders to clearly know and comply with the agreed rules. 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.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 01:39: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 BAA05913 for ; Tue, 10 Aug 2004 01:39: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 i7A5MTd8072058; Mon, 9 Aug 2004 22:22: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 i7A5MT1q072057; Mon, 9 Aug 2004 22:22:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A5MS2W072026 for ; Mon, 9 Aug 2004 22:22:28 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2004 22:23:41 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7A5MPUp008548; Mon, 9 Aug 2004 22:22:26 -0700 (PDT) Received: from fenton-w2k01.cisco.com (sjc-vpn4-620.cisco.com [10.21.82.108]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7A5sOkZ029334; Mon, 9 Aug 2004 22:54:27 -0700 Message-Id: <4.3.2.7.2.20040809220517.04243018@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 22:23:51 -0700 To: "Chris Haynes" , "IETF MARID WG" From: Jim Fenton Subject: Re: Security issue: Minority installed base of compatible MUAs? In-Reply-To: <004701c47e31$ca1b98c0$0200000a@ringo> References: <04dc01c47c6d$8f1739c0$0200000a@ringo> 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:"1092117268.68408"; x:"432000"; a:"rsa-sha1"; b:"0:1490"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"ZOovpJpCD8nrUqvioNhjjGUb0qEliSl0gUQE6M2ePKfeO5WP+VS1TZcyHgeme" "Eln3nHh1T8NsDuGFCubAtNckyuwCIQ1csKJhLV13Le5ucU7fNlxEDe9SKVuyW" "IpfuHCqx0y1UP0XBMzOFQ0z6TKgoD9c5efb/Js7MIlnWLjOI4="; c:"Date: Mon, 09 Aug 2004 22:23:51 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: Security issue: Minority installed base of compatible MUA" "s?" 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 05:56 PM 8/9/2004 +0100, Chris Haynes wrote: >"Rand Wacker" replied: > > >> On Sat, 7 Aug 2004, Chris Haynes wrote: >> >> > The draft states that "in order to avoid this attack, MUAs will need to >start >> > displaying at least the header that was verified". >> > >> > My concern is the need for new MUA purchases. >> >> Why can't the server-side check modify the message to display the results >> in an MUA-compatible way similar to the way that SpamAssassin modifies >> bodies and (optionally) headers today? >> >> -Rand >> >> > >Could you please supply an example of the modifications you propose in such a >way that: > >1) It is displayable in Outlook Express > >2) The display could not have been forged by the sender I share Chris's concern. Unless the PRA is displayed prominently to the user, the From address (when it isn't the PRA) can be anything it wants. I'm not an OE user, but I'd suggest something like the following: The MTA verifying the source of the email would rewrite the From line to something like: From: {original From address} via {PRA address} It would also copy the original From address into a newly-created header, perhaps Originally-From: There needs to be a chain of trust between where the source of the email is verified and the recipient. I believe that is needed whether you do the rewriting I'm describing or not. If that chain of trust exists, the sender shouldn't be able to forge it. -Jim From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 02:36: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 CAA24551 for ; Tue, 10 Aug 2004 02:36: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 i7A6LImB085370; Mon, 9 Aug 2004 23: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 i7A6LIAT085369; Mon, 9 Aug 2004 23:21:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A6LInF085346 for ; Mon, 9 Aug 2004 23:21:18 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 09 Aug 2004 23:23:14 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7A6L8Up002214; Mon, 9 Aug 2004 23:21:08 -0700 (PDT) Received: from fenton-w2k01.cisco.com (sjc-vpn4-620.cisco.com [10.21.82.108]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7A6r7kZ029714; Mon, 9 Aug 2004 23:53:10 -0700 Message-Id: <4.3.2.7.2.20040809225744.02e56da0@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 23:22:30 -0700 To: ned.freed@mrochek.com, Hadmut Danisch From: Jim Fenton Subject: Re: Does marid-submitter-02 really make sense? Cc: ietf-mxcomp@imc.org In-Reply-To: <01LDAWC6X2SQ00005R@mauve.mrochek.com> References: <"Your message dated Thu, 05 Aug 2004 09:40:27 -0700" <20040805164027.GA2443@danisch.de> <20040805164027.GA2443@danisch.de> 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:"1092120791.120871"; x:"432000"; a:"rsa-sha1"; b:"0:3243"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"ChfDxG0Uldd6WbAg22+QaXiKKrjNBY/zU+VcqkcmY5sorycUILii8QYA+Ly1/" "LFb1LLqFtbHIXf0FiJEhroyM/wNGLcPwDI4ltwoBbHhN5+pjvatzK0S0mQez6" "9s5zG+UwqMZMFxMDgJArWE/6rLi4F3BDaDCTKu/qNSGioF2+Y="; c:"Date: Mon, 09 Aug 2004 23:22:30 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: Does marid-submitter-02 really make sense?" 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:11 AM 8/5/2004 -0700, ned.freed@mrochek.com wrote: >> Does the SUBMITTER parameter really make sense? > >> Case 1: The sender is authorized by some domain to >> send messages. The message will have to be accepted and therefore >> to be transmitted. No benefit in checking the parameter before >> transmission. Could do this also after transmission. > >Maybe, maybe not. Having the information early might in some MTAs allow for >throughput optimizations. Some other correspondents (thank you Margaret!) have clarified that the optimization here is in being able to begin an accreditation/reputation check earlier. But even without Submitter it should be possible to begin this check as soon as the last header is received. This seems like a rather small optimization. >> Case 2: The sender is not authorized or does not want >> to reveal her identity (e.g. spammer). Sender would be stupid >> if she gave a SUBMITTER parameter not covering her IP address. >> So the sender will certainly do as if she had not yet implemented the >> SUBMITTER, i.e. omit it. Message will be transmitted as well. > >You're missing cases 3 and 4: > >Case 3: The sender should be authorized by some domain but for whatever >reason is not. This extension allows this condition to be detected early >and may avoid transfer of a large message. Again, I think that the savings are small: this is presumably an isolated case (an "honest mistake", not a bulk mailing) so this would not happen very often. Even if the bits need to be transferred, the recipient need not store them once a decision has been made not to accept the message. >Case 4: The sender should not be authorized and uses SUBMITTER anyway. >(Even if you assume spammers never do this directly, which may or may >not be true, there are cases where mail is forced through intermediaries >that might not be prepared to do a validation check but would be able to add a >SUBMITTER field.) This again transfer of the message body to be avoided. >This is clearly a corner case, but it needs to be on the >list. There are actually two cases here: 4a: The sender should not be authorized and uses SUBMITTER with an address that corresponds to the PRA. Savings do result, but I would not expect bulk mailers to do this. 4b: The sender should not be authorized but uses SUBMITTER with an authorized address. A spammer might do this in order to make sure that, if the message is rejected, the recipient has to do as much work as possible to reject it, or might not go to the trouble of verifying SUBMITTER against the PRA. This is a reason that, IMO, any SMTP server which implements submitter, MUST verify it against the PRA (not "SHOULD" as in section 4.2 of the current draft). I consider the optimizations provided by Submitter to not be worth the additional complexity it introduces. This is particularly true when there is discussion about making it mandatory at some point (not really a "service extension" any more but a change to SMTP itself). At that point not only MTAs but also firewalls (which often allow only specific ESMTP options, since others are considered "dangerous") will need to change to accommodate this. -Jim From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 04:12: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 EAA01160 for ; Tue, 10 Aug 2004 04:12:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A7o0DZ013212; Tue, 10 Aug 2004 00:50: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 i7A7o06F013211; Tue, 10 Aug 2004 00:50:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A7nxWp013189 for ; Tue, 10 Aug 2004 00:50:00 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7A7mxMt012248 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 10 Aug 2004 03:49:00 -0400 Subject: Re: Security issue: Minority installed base of compatible MUAs? From: Mark Shewmaker To: Jim Fenton Cc: Chris Haynes , IETF MARID WG In-Reply-To: <4.3.2.7.2.20040809220517.04243018@mira-sjc5-1.cisco.com> References: <04dc01c47c6d$8f1739c0$0200000a@ringo> <4.3.2.7.2.20040809220517.04243018@mira-sjc5-1.cisco.com> Content-Type: text/plain Message-Id: <1092124329.19728.782.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 03:52:09 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Tue, 10 Aug 2004 03:49:01 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-10 at 01:23, Jim Fenton wrote: > > There needs to be a chain of trust between where the source of the email > is verified and the recipient. I believe that is needed whether you do > the rewriting I'm describing or not. If that chain of trust exists, > the sender shouldn't be able to forge it. If we had a sender_agents modifier (or something close), and the purported previous senders participated in sender_agents, then receiving MTAs could reject messages with broken chains of trust between the body header address that the mail purports to originally be made on behalf of, and the final recipient. So then the modified MUA displays need only alert people about "questionable" messages, ie, message that were accepted but for which either: o the purported original senders don't participate in sender_agents, *AND* there are forwarding PRAs not authorized and white-listed by the recipient, (I would think this would be rare for legitimate mails--large legitimate bulk mailers should have the expertise to properly participate in sender_agents.) OR o The purported original senders do participate in sender_agents, but the Sender_ID tests don't result in a complete PASS because of recipient forwarding hops that result in NEUTRAL or SOFTFAIL answers. (This problem is under the control of the recipient.) The end-users wouldn't have to be worry about messages with provably-forged chain-of-trust forwarding hops, as they'd have been rejected. They'd only have to worry about "questionable" mails, and for any legitimate ones they could go complain to their ISPs who don't do forwarding properly, or they could complain to the the real sender who doesn't participate in sender_agents, depending on the circumstance. That is, in most cases I would think the receipt of legitimate but "questionable" mails according to the Sender-ID/sender_agents tests would be a solvable problem given customer feedback. (For instance, I couldn't imagine citibank and paypal not having spf records *and* sender_id modifiers in those records, say, 2 years from now, as their existence could eliminate almost all body-header-address forgeries using their real domain names in the body From: line. Obviously you'd need domain-name block lists to catch things like From: lines with paypa2.com (or with a numeral 1 instead of numeral 2)) (Of course all the above still doesn't address the bounce problems that classic SPF and SES&SRS handle so well--just the authorized-by-onbehalfof-person-to-submit problem that SenderID purportedly addresses. So I'd hope people would do spf classic tests on MAIL FROM at message receipt as well to address the bounce problem, and SES/BATV on message transmission to address filter forged bounces bounced back to you.) -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 06:19:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10097 for ; Tue, 10 Aug 2004 06:19:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AA6nOj048209; Tue, 10 Aug 2004 03:06:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AA6n0D048208; Tue, 10 Aug 2004 03:06:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AA6mq6048194 for ; Tue, 10 Aug 2004 03:06:48 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1BuTWg-000329-00 for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 11:06:38 +0100 Message-ID: <016901c47ec1$6d308220$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG vla PHISHER" References: <04dc01c47c6d$8f1739c0$0200000a@ringo> <4.3.2.7.2.20040809220517.04243018@mira-sjc5-1.cisco.com> Subject: Re: Security issue: Minority installed base of compatible MUAs? Date: Tue, 10 Aug 2004 11:04:19 +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 At 20040810 0623 "Jim Fenton" suggested: > At 05:56 PM 8/9/2004 +0100, Chris Haynes wrote: > > > > >"Rand Wacker" replied: > > > > > >> On Sat, 7 Aug 2004, Chris Haynes wrote: > >> > >> > The draft states that "in order to avoid this attack, MUAs will need to > >start > >> > displaying at least the header that was verified". > >> > > >> > My concern is the need for new MUA purchases. > >> > >> Why can't the server-side check modify the message to display the results > >> in an MUA-compatible way similar to the way that SpamAssassin modifies > >> bodies and (optionally) headers today? > >> > >> -Rand > >> > >> > > > >Could you please supply an example of the modifications you propose in such a > >way that: > > > >1) It is displayable in Outlook Express > > > >2) The display could not have been forged by the sender > > I share Chris's concern. Unless the PRA is displayed prominently to the user, the > From address (when it isn't the PRA) can be anything it wants. > > I'm not an OE user, but I'd suggest something like the following: > > The MTA verifying the source of the email would rewrite the From line to something like: > > From: {original From address} via {PRA address} Do you mean like the To: part of this eMail? AFAIK the only way to get OE to display anything like this is to put the text into the displayable version of the address. This contaminates the address used in the Address Book, used in replies, forwards etc. Now how about preventing forgery? I think you suggest that receiving MTAs should strip off any pre-existing 'via' text before adding its own. Look closely at my demonstration. Would your MTA strip this suffix? Would the user read it as "via PHISHER" (hope you've got crisp glyphs in your display)? In which RFC do we make "via" a prohibited word in the free-text part of addresses? Exactly which character sequences do we prohibit? How about encoding "via" in octet encodings intended for the display of non-US-ASCII? And what about the cases (listed in my Saturday eMail Security issue: End-user dependence on MTA integrity" 40040807 11:59) in which the last MTA in the chain is not undertaking the tests? Forged "via"s could get straight through without being challenged. > > It would also copy the original From address into a newly-created header, perhaps >Originally-From: Useful in OE only to those who know and understand the "RightClick-Properties - Details" dialog sequence. > > There needs to be a chain of trust between where the source of the email is verified > and the recipient. I believe that is needed whether you do the rewriting I'm > describing or not. If that chain of trust exists, the sender shouldn't be able to forge it. I absolutely agree that any time we display information to the user a chain of trust is needed. My points are: 1) The drafts on the table today do not provide even the basis for such a chain, 2) I would be very surprised if there are many MUAs in the consumer market today which have the capability to play their role in that chain - by displaying the information to be trusted in a way which (a) cannot be forged and (b) does not contaminate the message itself. That's why I have suggested to the authors of -core-02 that their "Security Considerations" section needs to be much more candid about this difficulty in displaying the PRA in a trustworthy way, and that both the draft and the IETF's decision-making process needs to understand (what I believe is) the need to replace a large proportion of the world's MUAs in order to provide the trust-worthy display of the PRA, which is an _essential_ aspect of Sender-ID. > > -Jim > > > HTH Chris From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 06:19: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 GAA10112 for ; Tue, 10 Aug 2004 06:19:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AA22oS046685; Tue, 10 Aug 2004 03:02: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 i7AA22u5046684; Tue, 10 Aug 2004 03:02:02 -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 i7AA206l046662 for ; Tue, 10 Aug 2004 03:02:00 -0700 (PDT) (envelope-from shevek@astray.com) Received: from shevek (helo=localhost) by kanga.astray.com with local-esmtp (Exim 4.12) id 1BuTSD-0005lH-00; Tue, 10 Aug 2004 11:02:01 +0100 Date: Tue, 10 Aug 2004 11:02:01 +0100 (BST) From: Shevek X-X-Sender: shevek@astray.com To: ietf-mxcomp@imc.org cc: Harry Katz Subject: RE: Does marid-submitter-02 really make sense? 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 Mon, 9 Aug 2004, Harry Katz wrote: > On Monday, August 09, 2004 4:49 PM Shevek wrote: > > > On Mon, 9 Aug 2004, Harry Katz wrote: > > > > > On Monday, August 09, 2004 10:24 AM ned.freed@mrochek.com wrote: > > > > > > > First, I am not proposing anything here. Not only is SUBMITTER not > > > > my idea, I have been quite clear that I am ambivalent about its > > > > inclusion in MARID. > > > > > > > > Second, the optimization in case 1 isn't a failure case but a > > > > success case. There may be a throughput improvement in some MTAs > > > > if the check can be done sooner. Mind you, I'm not saying there is > > > > guaranteed to be such an improvement - just that it is a > > > > possibility. Actual implementation experience would be needed to > > > > tell for sure. > > > > > > Ned is exactly correct here. The purpose of SUBMITTER is to allow > > > early (i.e. at 2821-time) verification of the sender's identity, > > > namely the PRA. At the IETF meetings last week there was some > > > discussion of whether this would result in bandwidth saving, > > > throughput improvement, or no benefit at all. I tend to think there > > > will be modest throughput improvement, but agree with Ned that we > > > need to verify through testing. > > > > This is incorrect. At 2821 time, we know only who the sender CLAIMS to > > be via SUBMITTER. It's not until after 2822 time, when we can compare > > the SUBMITTER value to the PRA value computed from the 2822 headers > > that we have verified the identity of the sender. > > Actually, it is correct. From section 4.2 of the submitter-02 draft: > > If these tests indicate that the connecting SMTP client is not > authorized to transmit e-mail messages on behalf of the SUBMITTER > domain, the receiving SMTP server SHOULD reject the message and when > rejecting MUST use "550 5.7.1 Submitter not allowed." > > 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." > > In other words, if SUBMITTER is present and fails the Sender ID check at > 2821 time, then the message SHOULD be rejected. The subsequent matching > of SUBMITTER to 2822 headers is only to confirm - if DATA is accepted - > that the SMTP client didn't lie about the value. This is NOT equivalent to a verification of the sender's identity, as suggested above, and therefore does not permit an early success optimisation. There is no shortcut.[0] It does permit early failure, but if implemented correctly, one would hope that the spammers would be forced to use the success case. Thus this optimisation offers no saving of bandwidth, CPU or anything else. S. [0] I fully expect many implementations to implement this as a shortcut, and weaken the system. The later processing is too complex and breaks the layers which so many MTAs are architected to respect. -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 08: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 IAA23259 for ; Tue, 10 Aug 2004 08:58:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ACdGdN092062; Tue, 10 Aug 2004 05:39: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 i7ACdGdp092061; Tue, 10 Aug 2004 05:39:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ACdFHj092053 for ; Tue, 10 Aug 2004 05:39:16 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7ACd9Mt018568 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 10 Aug 2004 08:39:10 -0400 Subject: RE: Does marid-submitter-02 really make sense? From: Mark Shewmaker To: Shevek Cc: ietf-mxcomp@imc.org, Harry Katz In-Reply-To: References: Content-Type: text/plain Message-Id: <1092141740.19690.855.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 08:42:21 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Tue, 10 Aug 2004 08:39:11 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-10 at 06:02, Shevek wrote: > > It does permit early failure, but if implemented correctly, one would hope > that the spammers would be forced to use the success case. Thus this > optimisation offers no saving of bandwidth, CPU or anything else. Nah, there are some minor, meager optimizations. And there is a super-duper, super-serious, point-blank, shockingly huge optimization. First the boring, minor optimizations: -------------------------------------- The existence of a SUBMITTER in the MAIL command could provide meager throughput optimizations, even in the success cases: 1. If the receiving MTA is doing SenderID tests and no SPF-Classic tests: Then the receiving MTA could immediately start doing DNS queries and Sender-ID tests at MAIL time, even if it doesn't act on the results until after DATA. So instead of taking N network-limited milliseconds to do the Sender-ID test after data, tacking N to the length of time otherwise needed to process the hole message, it could do that N milliseconds worth of work/waiting in parallel. 2. If the receiving MTA is doing SenderID tests *and* Classic SPF tests: Then there's going to be a short delay at MAIL FROM *anyway* just to do the classic SPF tests. I'm *guessing* the classic SPF tests would take about the same amount of time as the Sender ID tests, so why not just do them in parallel? 3. Any other not-directly-SenderID test based on SUBMITTER could be substituted in (1) or (2) above, such as domain-based reputation tests. (Or full-email-address (!!!) based reputation tests.) However, since these are merely optimizations, and probably not overly noticable ones at that, I wasn't big on any requirement to use Submitter. (At one point way back when there were flag days and the like where you'd be required to use Submitter.) The shockingly huge optimization: --------------------------------- ***HOWEVER***, there is one serious advantage to using SUBMITTER that I had completely forgotten about: Per-Recipient Rejects. Imagine that one recipient has white-listed a given PRA, and a second recipient hasn't--and so there's a situation where an incoming message should be sent to only the first recipient and not the second. Here are three possibilities for that situation for a receiving MTA: If you're given SUBMITTER: Possibility 1: Accept the first RCPT TO: Reject the second RCPT TO: with 5.7.1 Accept DATA. If you're not given SUBMITTER: Possibility 2: Accept the first RCPT TO: Accept the second RCPT TO: Accept DATA. Run SenderID tests. Find the second RCPT TO: fails SenderID tests. BOUNCE the second RCPT TO with 5.7.1 This choice means you're running the risk of being a source of forged bounces if you didn't also do Classic SPF tests. Oops. Possibility 3: Accept the first RCPT TO: Reject any subsequent RCPT TO: "too many recipients" Accept DATA. You soon get another connection from the same MTA. Reject the first RCPT TO: with 5.7.1 (which was recipient #2 earlier) You're supposed to always be able to accept 100 recipients, but if you always max out at one when you don't have SUBMITTER, then you can safely do per-recipient rejects that way, without bouncing. So, here SUBMITTER is a *serious* optimization! So if you allow recipient white-listing, you either have to either: 1. Max out at just one recipient, and get 100 separate connections for 100 separate attempted recipients, OR 2. Run SPF Classic tests on MAIL FROM, and *bounce* messages failing SenderID tests. Either way, your bandwidth is sucked away like crazy. But wait--it's worse!! What if you chose option (2), running SPF classic and doing SenderID tests--you *still* can't safely bounce unless you get an SPF pass result! That means that if you're running SenderID tests with recipient white-listing (and hopefully with sender_agents, plug-plug), and your MTA gets a connection without SUBMITTER, the only safe way to proceed is to: Run SPF Classic tests on MAIL FROM: If result==PASS: Accept as many recipients as you like. Bounce messages failing SenderID tests. else: Accept only ONE recipient maximum. be prepared for multiple reconnects. (Anyone want to suggest an SMTP extension for after-data per-recipient rejects?) If you're given SUBMITTER, you can do per-recipient rejects safely, of course. But folks who want to trick you into sending their bounce spam won't be all nice and give you a cool SUBMITTER to play with--and without SUBMITTER you have this yucky issue. (Side note: If you do get SUBMITTER and SUBMITTER!=PRA, then it's safe to reject after DATA for *all* recipients, because this is clearly either a corrupt or forged mail transmission.) -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 13:58:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17410 for ; Tue, 10 Aug 2004 13:58:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AHeZeB049918; Tue, 10 Aug 2004 10:40:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AHeZSd049917; Tue, 10 Aug 2004 10:40:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AHeZdi049905 for ; Tue, 10 Aug 2004 10:40:35 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7AHeM1i005425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2004 10:40:23 -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 i7AHeKtZ022694; Tue, 10 Aug 2004 10:40:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <20040809231452.GF28401@dumbo.pobox.com> References: <20040809231452.GF28401@dumbo.pobox.com> Date: Tue, 10 Aug 2004 10:40:19 -0700 To: Meng Weng Wong , IETF MARID WG From: Ted Hardie Subject: Re: change of version string 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 7:14 PM -0400 8/9/04, Meng Weng Wong wrote: > >While such a change is, from the standpoint of architectural >purity, absolutely the correct thing to do, I fear that in >practice it may lead to confusion, needless duplication of >records, and a failure to achieve the intended objective. >In other words, it is my opinion that engineering >considerations do not weigh in favour of changing the string. > >I particularly do not want to see a world where the norm is: > > example.com TXT "v=spf1 a mx ptr" > example.com TXT "v=spf2 a mx ptr" > >Both records would contain the same content, yet senders >might feel the need to publish both "just to be on the safe side". Both records do _not_ contain the same information. The first record has a target of MAIL_FROM; the second has a target of PRA. The fact that the strings "a mx ptr" happen to be the same in both records does not change that fundamental fact. The fact that the same IPv4 dotted quad might appear in an MX record and NS record for example.com doesn't change the fact that the records tell you different things about how that domain's systems are set up. The situation here is parallel; it isn't as obvious because you're using the overloaded TXT record rather than the new RR. As an aside, this is one of the practical reasons why subtyping the TXT record is a bad idea; it gets very easy to confuse the types, even for folks who have been working with it for a long time. regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 14:49: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 OAA20446 for ; Tue, 10 Aug 2004 14:49: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 i7AIYtiX054819; Tue, 10 Aug 2004 11:34:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AIYtTP054818; Tue, 10 Aug 2004 11:34: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 i7AIYsPq054811 for ; Tue, 10 Aug 2004 11:34: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 ADF0C4149B; Tue, 10 Aug 2004 11:34:56 -0700 (PDT) Subject: RE: Does marid-submitter-02 really make sense? From: Douglas Otis To: Mark Shewmaker Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092141740.19690.855.camel@localhost.localdomain> References: <1092141740.19690.855.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1092162895.25379.104.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 11:34: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 Tue, 2004-08-10 at 05:42, Mark Shewmaker wrote: > On Tue, 2004-08-10 at 06:02, Shevek wrote: > > > > It does permit early failure, but if implemented correctly, one would hope > > that the spammers would be forced to use the success case. Thus this > > optimisation offers no saving of bandwidth, CPU or anything else. > > Nah, there are some minor, meager optimizations. > > And there is a super-duper, super-serious, point-blank, shockingly huge > optimization. > > First the boring, minor optimizations: > -------------------------------------- > > The existence of a SUBMITTER in the MAIL command could provide meager > throughput optimizations, even in the success cases: > > 1. If the receiving MTA is doing SenderID tests and no SPF-Classic > tests: > > Then the receiving MTA could immediately start doing DNS > queries and Sender-ID tests at MAIL time, even if it doesn't > act on the results until after DATA. > > So instead of taking N network-limited milliseconds to do the > Sender-ID test after data, tacking N to the length of time > otherwise needed to process the hole message, it could do that > N milliseconds worth of work/waiting in parallel. > > 2. If the receiving MTA is doing SenderID tests *and* Classic SPF > tests: > > Then there's going to be a short delay at MAIL FROM *anyway* just > to do the classic SPF tests. > > I'm *guessing* the classic SPF tests would take about the same > amount of time as the Sender ID tests, so why not just do them > in parallel? > > 3. Any other not-directly-SenderID test based on SUBMITTER could > be substituted in (1) or (2) above, such as domain-based reputation > tests. > > (Or full-email-address (!!!) based reputation tests.) The Mailbox Domain identified by Submitter can not be used for reputation checks! This Mailbox Domain does not indicate the origin of the message, being the entity granting access to the mail stream. There would be little upon which to base repudiations and thus little gained from such check. Using this Submitter Mailbox Domain repudiation would expose the many opportunities for Sender-ID spoofing that still exist, and harm those left vulnerable by many shared MTA channels. > However, since these are merely optimizations, and probably not overly > noticable ones at that, I wasn't big on any requirement to use > Submitter. (At one point way back when there were flag days and the > like where you'd be required to use Submitter.) > > The shockingly huge optimization: > --------------------------------- > > ***HOWEVER***, there is one serious advantage to using SUBMITTER that I > had completely forgotten about: > > Per-Recipient Rejects. > > Imagine that one recipient has white-listed a given PRA, and a second > recipient hasn't--and so there's a situation where an incoming message > should be sent to only the first recipient and not the second. > > Here are three possibilities for that situation for a receiving MTA: > > If you're given SUBMITTER: > > Possibility 1: Accept the first RCPT TO: > Reject the second RCPT TO: with 5.7.1 > Accept DATA. > > If you're not given SUBMITTER: > > Possibility 2: Accept the first RCPT TO: > Accept the second RCPT TO: > Accept DATA. > Run SenderID tests. > Find the second RCPT TO: fails SenderID tests. > BOUNCE the second RCPT TO with 5.7.1 > > This choice means you're running the risk of being > a source of forged bounces if you didn't also do > Classic SPF tests. Oops. Neither Sender-ID nor Submitter stop bounces as there are no checks against the MAIL FROM. As mail, at many nodes, operates using a store and forward mechanism, there will always be ample opportunity to create a bounce. This example is applying a per recipient white-list at the initial MTA receiver. This assumes all MTAs have been provided these per-recipient white-lists. This assumption is flawed as there will be configurations where this does not apply and spammers are expert at finding them. > Possibility 3: Accept the first RCPT TO: > Reject any subsequent RCPT TO: "too many recipients" > Accept DATA. > > You soon get another connection from the same MTA. > Reject the first RCPT TO: with 5.7.1 (which was > recipient #2 > earlier) > > You're supposed to always be able to accept 100 > recipients, but if you always max out at one > when you don't have SUBMITTER, then you can safely > do per-recipient rejects that way, without bouncing. The white-listing could be based upon the MAIL FROM without using Submitter. If the PRA is not the RFC 2822 From, what would Submitter white-listing accomplish? Would this be greatly different from the use of MAIL FROM? A reaction by large ISPs to the use of Sender-ID could be to then include a Resent-From header to allow customers an ability to continue their normal practices. (Saving them a fortune is their support center.) In such a case, MAIL FROM is still as good, if not better than Submitter. > So, here SUBMITTER is a *serious* optimization! This is ignoring the likely outcome of this mechanism and the defensive strategy likely to result. > So if you allow recipient white-listing, you either have to either: > > 1. Max out at just one recipient, and get 100 separate connections for > 100 separate attempted recipients, > > OR > > 2. Run SPF Classic tests on MAIL FROM, and *bounce* messages failing > SenderID tests. I assume you mean Reject messages failing Sender-ID checks. > Either way, your bandwidth is sucked away like crazy. This ignores the required 10 host_checks() functions calls. Assume each TXT record references 8 MX records which then requires 5 A record lookups, as in the example by John Levine. That would be 400 DNS lookups resulting in about 1.3 queries per lookup (520) to arrive at the 400 answers. If each query resulted in a normal mean of about 100 ms, that would be 52 seconds, well within the 200 seconds alloted by the draft. If at about 400 bytes per record (counting both directions), the resulting traffic could be over 200 kbytes of UDP traffic, for about 8 kbytes of an average message. Spam is even smaller at about 4 kbytes. If the DNS cache hit rate is 80%, assuming the cache can withstand the added amount of Sender-ID records, the traffic is still 40 kbytes. Spammers however often employ a wildcard record and random sub-domains, making caching ineffective. Bandwidth can definitely be a concern, but Submitter does not offer a solution for this. > But wait--it's worse!! > > What if you chose option (2), running SPF classic and doing SenderID > tests--you *still* can't safely bounce unless you get an SPF pass > result! > > That means that if you're running SenderID tests with recipient > white-listing (and hopefully with sender_agents, plug-plug), and your > MTA gets a connection without SUBMITTER, the only safe way to proceed is > to: > > Run SPF Classic tests on MAIL FROM: > > If result==PASS: > Accept as many recipients as you like. > Bounce messages failing SenderID tests. > else: > Accept only ONE recipient maximum. > be prepared for multiple reconnects. > > (Anyone want to suggest an SMTP extension for after-data per-recipient > rejects?) It seems refusing to accept multiple recipients, as you indicated, on a normal basis would arrive at the same result. This would work with or without Submitter, when applying per recipient white-lists at the MTA. This could be seen as a means to avoid bounces at all costs, to bolster Sender-ID that does not check MAIL FROM. > If you're given SUBMITTER, you can do per-recipient rejects safely, of > course. But folks who want to trick you into sending their bounce spam > won't be all nice and give you a cool SUBMITTER to play with--and > without SUBMITTER you have this yucky issue. It seems you have concluded Submitter is not an optimization after all. This problem of multiple recipients is only when they share the same receiving MX server as well. > (Side note: If you do get SUBMITTER and SUBMITTER!=PRA, then it's safe > to reject after DATA for *all* recipients, because this is clearly > either a corrupt or forged mail transmission.) That assumes there is a check made at this point. This is the great downside when allowing Submitter. This check becomes optional and the modicum of security goes out the window. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 15:03: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 PAA21317 for ; Tue, 10 Aug 2004 15:03: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 i7AIkqAr055796; Tue, 10 Aug 2004 11:46: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 i7AIkqEq055795; Tue, 10 Aug 2004 11:46: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 i7AIkptk055789 for ; Tue, 10 Aug 2004 11:46:52 -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 1Bube1-0005X2-R1 for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 13:46:55 -0500 To: "IETF MARID WG" References: <20040809231452.GF28401@dumbo.pobox.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 10 Aug 2004 13:46:45 -0500 In-Reply-To: (Ted Hardie's message of "Tue, 10 Aug 2004 10:40:19 -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: change of version string 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 Ted Hardie writes: > At 7:14 PM -0400 8/9/04, Meng Weng Wong wrote: >> >>While such a change is, from the standpoint of architectural >>purity, absolutely the correct thing to do, I fear that in >>practice it may lead to confusion, needless duplication of >>records, and a failure to achieve the intended objective. >>In other words, it is my opinion that engineering >>considerations do not weigh in favour of changing the string. >> >>I particularly do not want to see a world where the norm is: >> >> example.com TXT "v=spf1 a mx ptr" >> example.com TXT "v=spf2 a mx ptr" >> >>Both records would contain the same content, yet senders >>might feel the need to publish both "just to be on the safe side". > > Both records do _not_ contain the same information. The first > record has a target of MAIL_FROM; the second has a target > of PRA. The fact that the strings "a mx ptr" happen to be > the same in both records does not change that fundamental > fact. *sigh* 1) Meng said that they "contain the same content", not "contain the same information". You appear to be confusing content with information. 2) Meng, and many others, have pointed out that in the vast majority of cases, the information *will* be the same and changing the version number will cause far more problems than it solves. > The fact that the same IPv4 dotted quad might appear in > an MX record and NS record for example.com doesn't change > the fact that the records tell you different things about how > that domain's systems are set up. The situation here is > parallel; it isn't as obvious because you're using the overloaded > TXT record rather than the new RR. This has *NOTHING* to do with RR types. The same problems would exist if we were talking about changing example.com TXTspf1 "a mx ptr" example.com TXTspf2 "a mx ptr" That is, deleting a few characters and moving a quote doesn't change anything. The huge problem with *just* changing the version string is that it cuts off future expansion. Earlier this spring, the co-chairs rules that 2822 identities would be held off until 2821 identities could be finished, but that we would return to 2822 identities. It was made clear that people wanted both, but the 2822 identities had not been tested (and still haven't), and it wasn't clear how to check the 2822 identities without creating large error rates (confirmed by the very limited testing done so far on the PRA). At the interim meeting this somehow magically got flipped (without a confirmation of this decision on the mailing list) and now we are working on 2822 identities. Even so, it was made clear that people wanted to test both. By simply changing the version number, we are limiting out options on how to proceed with 2821 checks. As I said here: http://www.imc.org/ietf-mxcomp/mail-archive/msg03081.html the problems with both changing and not changing the version number can be easily solved by falling back to SPF1 records if no SPF2 record is published and by defining the Unified-SPF scope macro-variable in the SPF2 record. For the vast majority of people, publishing SPF1 records will be all they need to do or worring about. For those that require different records for the PRA check vs the MAIL FROM and HELO checks, they can publish SPF2 records. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 15:27:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23676 for ; Tue, 10 Aug 2004 15:27: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 i7AJAnre057527; Tue, 10 Aug 2004 12:10: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 i7AJAnGU057526; Tue, 10 Aug 2004 12:10:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJAmAo057518 for ; Tue, 10 Aug 2004 12:10:48 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:47830) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1Buc1H-0004BB-NB (from fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 20:10:47 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Buc1H-0000Ab-HF for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 20:10:47 +0100 Date: Tue, 10 Aug 2004 20:10:47 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: When SPF is incompatible with Sender-ID 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: You can use SPF records and a custom DNS server to allow SPF-aware recipients to verify signed envelope return paths using the exists mechanism. This SPF record does not work for Sender-ID because the PRA will not be signed so will FAIL. 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 Tue Aug 10 15: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 PAA24138 for ; Tue, 10 Aug 2004 15: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 i7AJIesh058812; Tue, 10 Aug 2004 12:18:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AJIenm058811; Tue, 10 Aug 2004 12:18:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJIdhD058805 for ; Tue, 10 Aug 2004 12:18:39 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48831) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1Buc8u-00039Q-G8 (from fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 20:18:40 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Buc8u-0000pS-FH for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 20:18:40 +0100 Date: Tue, 10 Aug 2004 20:18:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: you must fill your zones with TXT records 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: Traditional remote domain verification involves checking that the domain stated in an email address has a valid MX or A record published in the DNS. This implies that a spammer could send email "from" any old machine with an A record and expect it to be accepted. Sender-ID does not solve this problem unless you publish a -all record for EVERY HOST on your network, since in the absence of a Sender-ID record the recipient will fall back to the current behaviour. With CSV the problem is slightly worse, because traditionally no checking is done on the HELO domain. To prevent a spammer from making up names in your zone, you must publish a wildcard -all record to ensure that the recipient knows that you are aware of CSV and wish to ban the use of nonexistent naes. 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 Tue Aug 10 17:19: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 RAA07918 for ; Tue, 10 Aug 2004 17: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 i7AKw0Cx067291; Tue, 10 Aug 2004 13:58: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 i7AKw0bu067290; Tue, 10 Aug 2004 13:58:00 -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 i7AKvxAF067274 for ; Tue, 10 Aug 2004 13:57:59 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7AKvu57017271; Tue, 10 Aug 2004 13:57:57 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7AKvsIb020040; Tue, 10 Aug 2004 13:57:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: <20040809231452.GF28401@dumbo.pobox.com> Date: Tue, 10 Aug 2004 13:57:53 -0700 To: "IETF MARID WG" From: Ted Hardie Subject: Re: change of version string Cc: wayne Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Inline. At 1:46 PM -0500 8/10/04, wayne wrote: >In Ted Hardie > writes: > >> At 7:14 PM -0400 8/9/04, Meng Weng Wong wrote: >>> >>>While such a change is, from the standpoint of architectural >>>purity, absolutely the correct thing to do, I fear that in >>>practice it may lead to confusion, needless duplication of >>>records, and a failure to achieve the intended objective. >>>In other words, it is my opinion that engineering >>>considerations do not weigh in favour of changing the string. >>> >>>I particularly do not want to see a world where the norm is: >>> >>> example.com TXT "v=spf1 a mx ptr" >>> example.com TXT "v=spf2 a mx ptr" >>> >>>Both records would contain the same content, yet senders >>>might feel the need to publish both "just to be on the safe side". >> >> Both records do _not_ contain the same information. The first >> record has a target of MAIL_FROM; the second has a target >> of PRA. The fact that the strings "a mx ptr" happen to be >> the same in both records does not change that fundamental >> fact. > >*sigh* > >1) Meng said that they "contain the same content", not "contain the > same information". You appear to be confusing content with > information. No. I chose the word information to contrast with "content". I wish to highlight that their containing the same string does not mean they are answering the same question. >2) Meng, and many others, have pointed out that in the vast majority > of cases, the information *will* be the same and changing the > version number will cause far more problems than it solves. I don't think so. They have tried to say "the answer to the two questions would be the same", which is not the same as "the information will be the same". The answer to the question "What is the last name of the current occupant of the U.S. presidency?" and "What is the last name of the artist whose debut album was 'The Kick Inside'?" may be the same, but Bush, George W. and Bush, Kate are not the same. As I pointed out in the recent face-to-face meeting, re-using the same version string to answer a different question creates a problem for those deploying these systems: they must understand how their string would be understood as an answer to either question. Given that we hope this will have very wide deployment, and given that cost gets paid by every domain from now on, this is a high price. As I channeled John Klensin at the mic, don't look at the current deployment, look at the rate of deployment to make this call. > >> The fact that the same IPv4 dotted quad might appear in >> an MX record and NS record for example.com doesn't change >> the fact that the records tell you different things about how >> that domain's systems are set up. The situation here is >> parallel; it isn't as obvious because you're using the overloaded >> TXT record rather than the new RR. > >This has *NOTHING* to do with RR types. The same problems would exist >if we were talking about changing > > example.com TXTspf1 "a mx ptr" > example.com TXTspf2 "a mx ptr" > >That is, deleting a few characters and moving a quote doesn't change >anything. I personally think this is a lot clearer that the two records are answering different questions. The following example.com 3600 IN 104 "a mx ptr" example.com 3600 IN 105 "a mx ptr" is even clearer, since there is no implication that two RRs who happen to be next to each in type code have anything to do with each other. Mnemonics like TXTspf1 and TXTspf2 might imply they do. >For the vast majority of people, publishing SPF1 records will be all >they need to do or worring about. For those that require different >records for the PRA check vs the MAIL FROM and HELO checks, they can >publish SPF2 records. > > This doesn't seem to me an argument *against* making them distinct; it seems to be an argument that the working group should not have chosen PRA. Given that it has, making them distinct seems to be pretty much required. Speaking without hats, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 17:32: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 RAA08647 for ; Tue, 10 Aug 2004 17:32: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 i7ALEFMB068488; Tue, 10 Aug 2004 14:14:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ALEFsE068486; Tue, 10 Aug 2004 14:14:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from 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 i7ALEEAU068472 for ; Tue, 10 Aug 2004 14:14:14 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: you must fill your zones with TXT records X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 10 Aug 2004 16:14:13 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D0553CA@srv1.pan-am.ca> Thread-Topic: you must fill your zones with TXT records Thread-Index: AcR/EkHCDUZYw+gwS+KEjCaqlub/YwADHOIA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7ALEEAU068480 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Traditional remote domain verification involves checking that > the domain > stated in an email address has a valid MX or A record published in the > DNS. This implies that a spammer could send email "from" any > old machine > with an A record and expect it to be accepted. Sender-ID does > not solve > this problem unless you publish a -all record for EVERY HOST on your > network, since in the absence of a Sender-ID record the recipient will > fall back to the current behaviour. This is where the automated tools come in. Something to inspect the zone and then push records through ddns for every node that doesn't already have a MARID-style record.[1] This is a flaw with every proposal that uses DNS, but it is not an insurmountable one. Not to mention that the wildcard issues were beaten to a greasy spot on the floor, never mind beaten to death. [1] Someone again said this was inexcusable but I never received an explanation as to why. Any takers? -- 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 Aug 10 18:19: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 SAA12700 for ; Tue, 10 Aug 2004 18: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 i7ALx27k072386; Tue, 10 Aug 2004 14:59: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 i7ALx2bU072385; Tue, 10 Aug 2004 14:59:02 -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 i7ALx1Ms072379 for ; Tue, 10 Aug 2004 14:59:02 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7ALx14v024228 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 14:59:02 -0700 Date: Tue, 10 Aug 2004 14:59:00 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Meng Weng Wong cc: IETF MARID WG Subject: Re: change of version string In-Reply-To: <20040809231452.GF28401@dumbo.pobox.com> Message-ID: References: <20040809231452.GF28401@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 9 Aug 2004, Meng Weng Wong wrote: > I particularly do not want to see a world where the norm is: > > example.com TXT "v=spf1 a mx ptr" > example.com TXT "v=spf2 a mx ptr" > > Both records would contain the same content, yet senders > might feel the need to publish both "just to be on the safe side". I'm torn between the "records really are validating different things so they should have different version string" and the "keep the adoption ball rolling" camps, but I am going to bring up a separate point here. Forgive me if this snake has been addressed before, but at the WG meeting last week it seemed to be slightly different. According to both folks from Cisco and the in-house DNS experts I've asked, I believe that if you put in multiple TXT records for the same FQDN (example.com as above), then *all* of those TXT records are sent back in a single UDP reply packet, so the 512 (more like 420) byte UDP packet restriction applies to THE AGGREGATE SIZE of ALL text records for a single FQDN. While the above example may be reasonably small, AOL's current SPF record is pushing 170 bytes, which would limit them to publishing only three concurrent records in the same FQDN space. I believe that the working group made no objection to sub-domaining records (publishing TXT in _marid.example.com), so if we go down the path of changing the version number or even the format we should take that in to consideration. -Rand From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 18:52: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 SAA14668 for ; Tue, 10 Aug 2004 18:52:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AMVxJY074910; Tue, 10 Aug 2004 15: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 i7AMVxPi074909; Tue, 10 Aug 2004 15:31: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 i7AMVxDp074903 for ; Tue, 10 Aug 2004 15:31: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 E00464149B for ; Tue, 10 Aug 2004 15:32:01 -0700 (PDT) Subject: Wildcards not useable From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1092177120.5943.3.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 15:32:01 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit As I understand, Sender-ID also does not provide a wildcard mechanism. This leaves a general problem of needing a means to express various mail polices regarding a domain and perhaps subsequent sub-domains. This could include whether all messages are signed digitally, all use CSV, etc. The Not Authorized aspect of CSV-CSA was intended only to offer added protection, should a system be considered vulnerable to being compromised. Such as a system may provide web or shell services, but is not intended to be sending mail. A specific removal of this host from being authorized adds additional protections from Trojans. The CSV-CSA record was not intended to be published at every SOA. A general policy record could fulfill this role, but it should not be encumbered with excess baggage, as to make obtaining the information problematic or require additional lookups. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 19:27: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 TAA16622 for ; Tue, 10 Aug 2004 19:27: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 i7ANDTlL079025; Tue, 10 Aug 2004 16:13: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 i7ANDTVs079024; Tue, 10 Aug 2004 16:13:29 -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 i7ANDSjK079014 for ; Tue, 10 Aug 2004 16:13:29 -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 i7ANDW96003480 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 19:13:33 -0400 Date: Tue, 10 Aug 2004 19:13:32 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 3 Aug 2004, Hallam-Baker, Phillip wrote: > > > Wrong and misleading as well. I have given you a large number > > of specific faults: (I'll summarize) > > > > 1) Abuser can forge addresses at domain > > This is a risk, not a specific threat. it appears that you are referring > to the fact that forwarded mail can only authenticate to the last sender, > not the original sender. > > This is an understood issue for which other controls are relevant. It is a way to circumvent SPF. It is not a "risk", it is a vulnerability. > > 2) Abuser can use stolen credential > > This claim makes no sense whatsoever in the context of Sender-ID since > there is no private key coresponding to the DNS record, there is no > knowledge that can be stolen. > > The vulnerabilities to DNS and BGP spoofing are understood and are > out of scope. This has nothing to do with DNS. "Stolen Credential" means username and password. Virus infected machines have the credentials of the machines' owner. The virus can use these. I didn't list DNS spoofing or BGP spoofing. BGP spoofing is beyond the capabilities of most spammers. Its happened, but its rare. DNS spoofing, however, is within their capabilities, but I didn't list that. > > 3) DNS cache problems (more records per domain, same cache size) > > Irrelevant. Impact on other protocols is relevent. > > 4) DNS load (more records per domain) > > Irrelevant. Impact on other protocols is relevent. > > > 5) Ongoing Maintenance issues > > Vague. You obviously haven't read the emails. Maintainence issues were clearly explained. > > 6) Migration issues > > Vague and irrelevant. You obviously haven't read the emails. Migration issues were clearly explained. > > 7) IP Renumbering issues > > Utterly irrelevant. Impact on business activities is relevant. > > 8) Lost non-spam emails > > Not an issue, all Sender-ID does is to provide a means of whitelising > good email, it is not a mechanism for rejecting bad emails, that Impact on business activities is relevant. Lost email is an issue for those who will lose emails and business as a result. But I agree that SPF is just a whitelist scheme, and we already have a perfectly good whitelist method in DNS already. We've had DNS blacklists for many years, and it is trivial to make a DNS whitelist. > > 9) Lack of universal compliance.* > > Uninterested. I see that. That doesn't mean that it isn't an issue. "Lack of interest" seems to be a common problem with anti-spam proposals. I think that's why they fail so often. From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 19:30:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16784 for ; Tue, 10 Aug 2004 19:30: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 i7ANIYVQ079351; Tue, 10 Aug 2004 16:18: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 i7ANIYdV079350; Tue, 10 Aug 2004 16:18:34 -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 i7ANIXgP079344 for ; Tue, 10 Aug 2004 16:18:33 -0700 (PDT) (envelope-from sb0-0640997d0c-johnl@iecc.com) Received: (qmail 21730 invoked by uid 100); 10 Aug 2004 23:18:38 -0000 Date: 10 Aug 2004 23:18:38 -0000 Message-ID: <20040810231838.21729.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: record size and wild cards, was change of version string In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: rand@sendmail.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I believe that if you put in multiple TXT records for the same FQDN > (example.com as above), then *all* of those TXT records are sent > back in a single UDP reply packet, so the 512 (more like 420) byte > UDP packet restriction applies to THE AGGREGATE SIZE of ALL text > records for a single FQDN. Yes, that's correct. If a response includes multiple records, which it will if the query is a TXT query and there are multiple TXT records for the name, they're all sent in one response packet, which will have well known problems if they don't fit in a 512 byte UDP response packet, and less well known but more serious problems if they don't fit in a single TCP packet. One of the reasons that the DNS has multiple record types is so that a query can specify the type it wants and just get the relevant records, keeping responses small. Overloading TXT breaks that. > I believe that the working group made no objection to sub-domaining > records (publishing TXT in _marid.example.com) The problem with _marid subdomains is that they break wildcards, since DNS wildcards don't permit _marid.*.foo.com. Some of us have per-user subdomains implemented with wildcards, and there's no good workaround. We could publish the TXT records for *.foo.com and let the clients throw out the ones they don't understand, but then we're back to stuffing all the TXT records into the same packet. The only band-aid I can see is to hack up our servers to special case _marid.*.foo.com, which we weenies can do but I wouldn't wish on the net in general. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 19: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 TAA17137 for ; Tue, 10 Aug 2004 19:35: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 i7ANL2Yh079594; Tue, 10 Aug 2004 16: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 i7ANL2Ol079593; Tue, 10 Aug 2004 16:21: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 i7ANL1ul079587 for ; Tue, 10 Aug 2004 16:21: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 1BufvL-0007XI-IT for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 18:21:06 -0500 To: "IETF MARID WG" References: <20040809231452.GF28401@dumbo.pobox.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 10 Aug 2004 18:16:16 -0500 In-Reply-To: (Ted Hardie's message of "Tue, 10 Aug 2004 13:57:53 -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: change of version string 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 Ted Hardie writes: >>2) Meng, and many others, have pointed out that in the vast majority >> of cases, the information *will* be the same and changing the >> version number will cause far more problems than it solves. > > I don't think so. They have tried to say "the answer to the two > questions would be the same", which is not the same as > "the information will be the same". The answer to the question > "What is the last name of the current occupant of the U.S. > presidency?" and "What is the last name of the artist whose > debut album was 'The Kick Inside'?" may be the same, > but Bush, George W. and Bush, Kate are not the same. I can appreciate your comparisons of the same IP address showing up in an MX and NS record and the above anlogy about two people with the same last name of Bush. You are trying to draw a shart distinction between the questions and the answers. The thing is that the two MARID questions being ask are: 1) Is it valid for this IP address send an email with a MAIL FROM and/or HELO claiming from being from the given domain? (SPF-classic) 2) Is it valid for this IP address send an email with a From: header claiming from being from the given domain? (SenderID) These questions are much more closely related than NS or MX records. To use your analogy, it is like asking these two questions about the president: a) Is the current occupant of the U.S. Presidency over the age of 35? b) Is the current occupant of the U.S. Presidency a U.S. citizen? The answer two these two questions is "yes" for all U.S. Presidents that have ever been and will likely to ever be. This is not just because of some cosmic coincidence, but because these two questions have a common root in the requirements of being a U.S. President. Similarly, the answer to the two MARID questions are also almost always the same because of common roots. Understanding the common roots leads to a deeper understanding of what we are doing. Understanding what the co-chairs have said we will try to address in the foreseeable future make finding this deeper understanding very relavant to what we are doing today. As far as cosmic coincidences go, I suspect many people can guess the answers to the following questions: 1) Which week did the warranty of my laptop run out? 2) Which week did my laptop die? 3) Which week did I really need to post a bunch of stuff to MARID list about the current I-Ds, but is sitting on a dead laptop? *heavy sigh* (Yes, I have backups. No, backups are not an easy replacement.) In another message: In Rand Wacker writes: > Forgive me if this snake has been addressed before, but at the WG meeting > last week it seemed to be slightly different. According to both folks >>From Cisco and the in-house DNS experts I've asked, I believe that if you > put in multiple TXT records for the same FQDN (example.com as above), then > *all* of those TXT records are sent back in a single UDP reply packet, so > the 512 (more like 420) byte UDP packet restriction applies to THE > AGGREGATE SIZE of ALL text records for a single FQDN. Yes, is a well known issue and one of the goals of SPF was to make records as small as practical. > While the above example may be reasonably small, AOL's current SPF record > is pushing 170 bytes, which would limit them to publishing only three > concurrent records in the same FQDN space. AOL is not the largest SPF record I found when doing the surveys of 1.3 million email domains, but it is certainly one of the largest. Even so, AOL can fit two SPF-like record into a UDP DNS packet. Meng et al worked hard to make the print of SPF records small, and first thing the IETF doing doubling the space used. > I believe that the working group made no objection to sub-domaining > records (publishing TXT in _marid.example.com), so if we go down the path > of changing the version number or even the format we should take that in > to consideration. Publishing into a sub-domain doesn't really help if this working group is going to turn about and create more records for 2821 identities. Changing just the version number of SPF records is bad engineering, bad for maintenance, creates confusion, and is short-sighted. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 19:39:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17320 for ; Tue, 10 Aug 2004 19:39:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANSaYo079934; Tue, 10 Aug 2004 16:28: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 i7ANSaJj079933; Tue, 10 Aug 2004 16:28:36 -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 i7ANSalt079927 for ; Tue, 10 Aug 2004 16:28:36 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7ANSYpv003753 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 19:28:34 -0400 Date: Tue, 10 Aug 2004 19:28:34 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: John Glube cc: "'Michel Bouissou'" , "'IETF MARID WG'" Subject: RE: How is SPF different from RMX? In-Reply-To: <003601c47900$2204fe50$6c62fea9@ibmrkydk2ufvdd> 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, 2 Aug 2004, John Glube wrote: > > But all this does not matter. The main issue John is disputing above seems to be whether junk mail mostly comes from virus infected machines (as I suspect) or whether it comes from commercial emailers breaking the law (as I think John thinks). This is basically a quibble. In either case, the abuser is violating the law in some way, and that has a couple implications: 1) They won't be concerned with breaking other laws of similar severity, such as spoofing DNS, theft of user credentials, etc. 2) The solution is to have the law enforced. 3) The solution is not technical. We already have the best authentication and accountability we can obtain in the tuple of IP address and time of use. This tuple is sufficient for law enforcement to identify the virus infected machine (if that is the problem) or the commercial emailer (if that is the problem) > At present, the proposal is sender accountability, which > includes authentication, accreditation and reputation. I don't see how reputation has anything to do with SPF. The domain owner simply puts in an SPF txt record. Entities of bad reputation can easily create SPF records. The authentication and accountability aspects of SPF are illusory and are not achievable in the SPF proposal as it stands, nor can DNS be used to achieve these goals. This subject has been discussed at length on the DNSOP and DNSEXT lists, and it is generally agreed that DNS cannot be the basis of authentication. Having found that its goals aren't achievable, it seems that the Working Group is obligated to report this finding. Failing to report honestly on research is inappropriate. Dean Anderson Av8 Internet, Inc From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 19:57:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18101 for ; Tue, 10 Aug 2004 19:57: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 i7ANiwlW080863; Tue, 10 Aug 2004 16:44: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 i7ANiwXX080862; Tue, 10 Aug 2004 16:44:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANivi4080856 for ; Tue, 10 Aug 2004 16:44:57 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7ANj28S004110 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 19:45:02 -0400 Date: Tue, 10 Aug 2004 19:45:02 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: How is SPF different from RMX? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 10 Aug 2004, Dean Anderson wrote: > On Tue, 3 Aug 2004, Hallam-Baker, Phillip wrote: > > > > > > Wrong and misleading as well. I have given you a large number > > > of specific faults: (I'll summarize) > > > > > > 1) Abuser can forge addresses at domain > > > > This is a risk, not a specific threat. it appears that you are referring > > to the fact that forwarded mail can only authenticate to the last sender, > > not the original sender. And no, I'm not referring to the fact that forwarded mail can only authenticate to the last sender. I'm refering to the fact that anyone at AOL.com can pretend to be anyone else at AOL.com. From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 20:08:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18484 for ; Tue, 10 Aug 2004 20:08: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 i7ANtriJ082092; Tue, 10 Aug 2004 16:55: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 i7ANtrXh082091; Tue, 10 Aug 2004 16:55:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANtqhD082083 for ; Tue, 10 Aug 2004 16:55:52 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7ANtvNo004307 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 10 Aug 2004 19:55:57 -0400 Date: Tue, 10 Aug 2004 19:55:57 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "'IETF MARID WG'" Subject: Analysis of SPF benefits for reduced filtering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It has been reported that AOL is already using SPF to give reduced filtering to SPF-using domains. Is this a good idea? IF you use SPF to provide less stringent anti-spam processing, then you are MORE vulnerable than you were before. You have shot yourself in the foot. Suppose for example that AOL subjects MSN users to less stringent anti-spam filtering because MSN uses SPF. MSN is still vulnerable to viruses as it was before it used SPF, and it is just as vulnerable to disposable account creation as it was before. Using SPF will __attract__ abusers to MSN, because they can get more spam through to AOL, because it is subject to less processing. Since AOL is doing less processing on the same spam, AOL users get more spam. SPF is bad for both companies. And of course, anyone who sets up a disposable domain can also get spam through to AOL by creating an SPF record for the domain. Disposable domains along with disposable or stolen accounts is a major problem now, and it remains a major problem under SPF. Anything that reduces spam filtering without reducing the number of abusers will be harmful. Basically, SPF gives abusers the opportunity to whitelist themselves, or the opportunity to identify ISPs that may be whitelisted. Any kind of whitelist that is under the control of the sender, rather than the recipient is also going to be ineffective and harmful. Dean Anderson Av8 Internet, Inc From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 20:27: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 UAA19264 for ; Tue, 10 Aug 2004 20:27: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 i7B0E61E083197; Tue, 10 Aug 2004 17:14: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 i7B0E6CL083196; Tue, 10 Aug 2004 17:14:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0E6BI083188 for ; Tue, 10 Aug 2004 17:14:06 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 10 Aug 2004 20:14:06 -0400 id 002F4089.411964CE.000055C3 From: David Blacka Organization: VeriSign, Inc. To: ietf-mxcomp@imc.org Subject: Re: change of version string Date: Tue, 10 Aug 2004 20:13:53 -0400 User-Agent: KMail/1.6.2 References: <20040809231452.GF28401@dumbo.pobox.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408102013.53483.davidb@verisignlabs.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tuesday 10 August 2004 1:40 pm, Ted Hardie wrote: > Both records do _not_ contain the same information. The first > record has a target of MAIL_FROM; the second has a target > of PRA. The fact that the strings "a mx ptr" happen to be > the same in both records does not change that fundamental > fact. The fact that the same IPv4 dotted quad might appear in > an MX record and NS record for example.com doesn't change > the fact that the records tell you different things about how > that domain's systems are set up. The situation here is > parallel; it isn't as obvious because you're using the overloaded > TXT record rather than the new RR. Just as an annoying DNS nit: IPv4 dotted quad addresses in MX or NS records are misconfigurations (in the MX case, this is somewhat common, but it is still wrong). The targets of MX and NS records are DNS names, not IP address. Those names then map to IP addresses via A or AAAA records. Not that this diminishes Ted's point. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 20:27: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 UAA19288 for ; Tue, 10 Aug 2004 20:27: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 i7B09CLo082906; Tue, 10 Aug 2004 17:09:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B09Ckp082905; Tue, 10 Aug 2004 17:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B09CVX082897 for ; Tue, 10 Aug 2004 17:09:12 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 10 Aug 2004 20:09:10 -0400 id 002F4079.411963A6.00005531 From: David Blacka Organization: VeriSign, Inc. To: ietf-mxcomp@imc.org Subject: Re: record size and wild cards, was change of version string Date: Tue, 10 Aug 2004 20:08:57 -0400 User-Agent: KMail/1.6.2 References: <20040810231838.21729.qmail@xuxa.iecc.com> In-Reply-To: <20040810231838.21729.qmail@xuxa.iecc.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200408102008.57168.davidb@verisignlabs.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tuesday 10 August 2004 7:18 pm, John Levine wrote: > > I believe that if you put in multiple TXT records for the same FQDN > > (example.com as above), then *all* of those TXT records are sent > > back in a single UDP reply packet, so the 512 (more like 420) byte > > UDP packet restriction applies to THE AGGREGATE SIZE of ALL text > > records for a single FQDN. > > Yes, that's correct. If a response includes multiple records, which > it will if the query is a TXT query and there are multiple TXT records > for the name, they're all sent in one response packet, which will have > well known problems if they don't fit in a 512 byte UDP response > packet, and less well known but more serious problems if they don't > fit in a single TCP packet. I admit to hearing this statement at San Diego last week, but I didn't understand it then, and I don't understand it now. What is being referred to with the term "TCP packet"? Is this a reference to the MTU? I will admit to not being familiar with *all* DNS software, but I am having a hard time believing that there is DNS resolver software that a) does TCP, but b) somehow is unable to read an entire DNS message using TCP if it requires more than a few IP packets to transmit. It is more credible for me to believe that there is DNS software that won't fall back to TCP, or that there are some that don't actually allocate 64k (the actual maximum) of space for receiving a message. > One of the reasons that the DNS has multiple record types is so that a > query can specify the type it wants and just get the relevant records, > keeping responses small. Overloading TXT breaks that. > > > I believe that the working group made no objection to sub-domaining > > records (publishing TXT in _marid.example.com) > > The problem with _marid subdomains is that they break wildcards, since > DNS wildcards don't permit _marid.*.foo.com. Some of us have per-user > subdomains implemented with wildcards, and there's no good workaround. > We could publish the TXT records for *.foo.com and let the clients > throw out the ones they don't understand, but then we're back to > stuffing all the TXT records into the same packet. Since no one seems to be talking about removing the "v=spf1/2" from the beginning of TXT RDATA, I don't think "break" is the correct term here. The _marid subdomain seems to improve the subtyping situtation in the non-wildcard case, and leave the status quo in the wildcard case. This looks like a net improvement to me. So if you need multiple TXT records at your wildcard, you will have to be careful about the size of that TXT RR set, but everyone else gets more leeway. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 21: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 VAA21493 for ; Tue, 10 Aug 2004 21:10: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 i7B0uSwS087743; Tue, 10 Aug 2004 17:56: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 i7B0uSrL087742; Tue, 10 Aug 2004 17:56:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0uR91087736 for ; Tue, 10 Aug 2004 17:56:27 -0700 (PDT) (envelope-from sb0-0641cb1178-johnl@iecc.com) Received: (qmail 23053 invoked by uid 100); 11 Aug 2004 00:56:33 -0000 Date: 11 Aug 2004 00:56:33 -0000 Message-ID: <20040811005633.23052.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: record size and wild cards, was change of version string In-Reply-To: <200408102008.57168.davidb@verisignlabs.com> Organization: I.E.C.C., Trumansburg NY USA Cc: davidb@verisignlabs.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> for the name, they're all sent in one response packet, which will have >> well known problems if they don't fit in a 512 byte UDP response >> packet, and less well known but more serious problems if they don't >> fit in a single TCP packet. > >I admit to hearing this statement at San Diego last week, but I didn't >understand it then, and I don't understand it now. What is being referred to >with the term "TCP packet"? Is this a reference to the MTU? Yes. I was surprised to learn that there is a bug in widely used resolver libraries so that if it makes a TCP request, and the response isn't entirely contained in the first packet, the resolver gives up and retries. A large DNS provider thought it was being DDOS'ed (actually, it was being DDOS'ed) and tracked it down to this bug being triggered by some large response data. >I will admit to not being familiar with *all* DNS software, but I am having a >hard time believing that there is DNS resolver software that a) does TCP, but >b) somehow is unable to read an entire DNS message using TCP if it requires >more than a few IP packets to transmit. Believe it. I think it's due to bugs in the code that waits for a response or a timeout and doesn't go back to look for more data after getting the first data chunk back. Given how few DNS queries have needed TCP, and how few of the responses have been too big to fit in a 1500 MTU, it's not surprising nobody's noticed before. >Since no one seems to be talking about removing the "v=spf1/2" from the >beginning of TXT RDATA, I don't think "break" is the correct term here. The >_marid subdomain seems to improve the subtyping situtation in the >non-wildcard case, and leave the status quo in the wildcard case. This looks >like a net improvement to me. > >So if you need multiple TXT records at your wildcard, you will have to be >careful about the size of that TXT RR set, but everyone else gets more >leeway. I suppose that's true. It still seems to me to be asking for trouble, since any unrelated application with TXT records is going to load up the responses as well. From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 22:07:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24477 for ; Tue, 10 Aug 2004 22:07: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 i7B1p455093050; Tue, 10 Aug 2004 18:51: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 i7B1p46A093049; Tue, 10 Aug 2004 18:51: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 i7B1p3wj093042 for ; Tue, 10 Aug 2004 18:51:03 -0700 (PDT) (envelope-from kent@raven.songbird.com) Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7B1p7j20943 for ; Tue, 10 Aug 2004 18:51:07 -0700 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i7B1p77R015211 for ietf-mxcomp@imc.org; Tue, 10 Aug 2004 18:51:07 -0700 Date: Tue, 10 Aug 2004 18:51:07 -0700 From: kent crispin To: IETF MARID WG Subject: Re: change of version string Message-ID: <20040811015107.GA602@raven.songbird.com> Mail-Followup-To: IETF MARID WG References: <20040809231452.GF28401@dumbo.pobox.com> 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: On Tue, Aug 10, 2004 at 01:57:53PM -0700, Ted Hardie wrote: > >This has *NOTHING* to do with RR types. The same problems would exist > >if we were talking about changing > > > > example.com TXTspf1 "a mx ptr" > > example.com TXTspf2 "a mx ptr" > > > >That is, deleting a few characters and moving a quote doesn't change > >anything. > > I personally think this is a lot clearer that the two records are answering > different questions. The following > > example.com 3600 IN 104 "a mx ptr" > example.com 3600 IN 105 "a mx ptr" > > is even clearer, since there is no implication that two RRs who happen > to be next to each in type code have anything to do with each other. > Mnemonics like TXTspf1 and TXTspf2 might imply they do. But it would then follow that a new dns record type would have to be generated for every change. Alternatively, you could have a version in the data: example.com 3600 IN SPF "104 a mx ptr" example.com 3600 IN SPF "105 a mx ptr" (In this case the full rr set would be returned, and the client would then know all supported versions and could make a choice, for whatever that's worth.) The issue of where the version number is located is independent of the record type. -- Kent Crispin kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 22:31: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 WAA25815 for ; Tue, 10 Aug 2004 22:31:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B2I9cJ094848; Tue, 10 Aug 2004 19:18: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 i7B2I9Qd094847; Tue, 10 Aug 2004 19:18:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp2g.bellsouth.com (aismtp2g.bellsouth.com [139.76.165.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B2I9qo094832 for ; Tue, 10 Aug 2004 19:18:09 -0700 (PDT) (envelope-from Damon.Sauer@BellSouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp2g.bellsouth.com with ESMTP; Tue, 10 Aug 2004 22:18:07 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Analysis of SPF benefits for reduced filtering X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Tue, 10 Aug 2004 21:18:06 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB9B7D4B2@bremocog-55> Thread-Topic: Analysis of SPF benefits for reduced filtering Thread-Index: AcR/Ng/2TUngmwnhSc2LhsLH9c6MGwAEup6A From: "Sauer, Damon" To: "Dean Anderson" , "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7B2I9qo094842 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I think, no- I *know* that you are failing to understand what SPF *IS*. Wondering about what AOL is doing is an exercise in futility AND I seriously doubt that AOL's email services group would be as inept as you are suggesting here. Regards, Damon Sauer -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Dean Anderson Sent: Tuesday, August 10, 2004 7:56 PM To: 'IETF MARID WG' Subject: Analysis of SPF benefits for reduced filtering It has been reported that AOL is already using SPF to give reduced filtering to SPF-using domains. Is this a good idea? IF you use SPF to provide less stringent anti-spam processing, then you are MORE vulnerable than you were before. You have shot yourself in the foot. Suppose for example that AOL subjects MSN users to less stringent anti-spam filtering because MSN uses SPF. MSN is still vulnerable to viruses as it was before it used SPF, and it is just as vulnerable to disposable account creation as it was before. Using SPF will __attract__ abusers to MSN, because they can get more spam through to AOL, because it is subject to less processing. Since AOL is doing less processing on the same spam, AOL users get more spam. SPF is bad for both companies. And of course, anyone who sets up a disposable domain can also get spam through to AOL by creating an SPF record for the domain. Disposable domains along with disposable or stolen accounts is a major problem now, and it remains a major problem under SPF. Anything that reduces spam filtering without reducing the number of abusers will be harmful. Basically, SPF gives abusers the opportunity to whitelist themselves, or the opportunity to identify ISPs that may be whitelisted. Any kind of whitelist that is under the control of the sender, rather than the recipient is also going to be ineffective and harmful. Dean Anderson Av8 Internet, Inc ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 22:54: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 WAA26998 for ; Tue, 10 Aug 2004 22:54: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 i7B2cRi5096905; Tue, 10 Aug 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 i7B2cRMM096904; Tue, 10 Aug 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 emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B2cRvO096897 for ; Tue, 10 Aug 2004 19:38:27 -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 19B65132D08; Tue, 10 Aug 2004 22:41:56 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id A909482B; Tue, 10 Aug 2004 22:38:30 -0400 (EDT) Date: Tue, 10 Aug 2004 22:38:30 -0400 From: Meng Weng Wong To: Tony Finch Cc: ietf-mxcomp@imc.org Subject: Re: you must fill your zones with TXT records Message-ID: <20040811023830.GG28401@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 Tue, Aug 10, 2004 at 08:18:40PM +0100, Tony Finch wrote: | | Traditional remote domain verification involves checking that the domain | stated in an email address has a valid MX or A record published in the | DNS. This implies that a spammer could send email "from" any old machine | with an A record and expect it to be accepted. Sender-ID does not solve | this problem unless you publish a -all record for EVERY HOST on your | network, since in the absence of a Sender-ID record the recipient will | fall back to the current behaviour. | I wonder how feasible it would be to deprecate the implicit MX rule. From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 23:07: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 XAA27820 for ; Tue, 10 Aug 2004 23:07: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 i7B2rBsq098270; Tue, 10 Aug 2004 19:53: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 i7B2rBTZ098269; Tue, 10 Aug 2004 19:53:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B2rAnp098263 for ; Tue, 10 Aug 2004 19:53:10 -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 i7B2rCdu030548 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 19:53:12 -0700 Date: Tue, 10 Aug 2004 19:53:12 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: John Levine cc: ietf-mxcomp@imc.org Subject: Re: record size and wild cards, was change of version string In-Reply-To: <20040810231838.21729.qmail@xuxa.iecc.com> Message-ID: References: <20040810231838.21729.qmail@xuxa.iecc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 10 Aug 2004, John Levine wrote: > > I believe that the working group made no objection to sub-domaining > > records (publishing TXT in _marid.example.com) > > The problem with _marid subdomains is that they break wildcards, since > DNS wildcards don't permit _marid.*.foo.com. I seem to recall at the WG meeting that people *did not object* to breaking wildcards. If I am incorrect I'll be happy to retract, but we should probably refrain from rehashing what I'm pretty sure is a discussion that has been archived around here once or twice. -Rand From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 23:11:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28179 for ; Tue, 10 Aug 2004 23:11:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B2twg5099029; Tue, 10 Aug 2004 19:55: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 i7B2twHN099028; Tue, 10 Aug 2004 19:55:58 -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 i7B2tv5H099022 for ; Tue, 10 Aug 2004 19:55:57 -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 i7B2u3Wr030936 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 19:56:04 -0700 Date: Tue, 10 Aug 2004 19:56:03 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: David Blacka cc: ietf-mxcomp@imc.org Subject: Re: record size and wild cards, was change of version string In-Reply-To: <200408102008.57168.davidb@verisignlabs.com> Message-ID: References: <20040810231838.21729.qmail@xuxa.iecc.com> <200408102008.57168.davidb@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 10 Aug 2004, David Blacka wrote: > It is more credible for me to believe that there is DNS software that won't > fall back to TCP, or that there are some that don't actually allocate 64k > (the actual maximum) of space for receiving a message. The issue is more operational, there will be quite a bit of resistance by site security admins to open up TCP port 53 for queries of that size, and even more resitance by sites that receive A LOT of mail to accept the possibility of making outbound TCP queries for large number of incoming messages. -Rand From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 23:19: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 XAA28774 for ; Tue, 10 Aug 2004 23:19: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 i7B31RBn099401; Tue, 10 Aug 2004 20:01: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 i7B31RX2099400; Tue, 10 Aug 2004 20:01:27 -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 i7B31RIw099393 for ; Tue, 10 Aug 2004 20:01:27 -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 i7B31U1e032312 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 20:01:31 -0700 Date: Tue, 10 Aug 2004 20:01:30 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Dean Anderson cc: "'IETF MARID WG'" Subject: Re: Analysis of SPF benefits for reduced filtering 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 Tue, 10 Aug 2004, Dean Anderson wrote: > It has been reported that AOL is already using SPF to give reduced > filtering to SPF-using domains. Is this a good idea? Incorrect, see http://postmaster.aol.com/spf/: --- AOL will begin using SPF records to maintain our whitelist in the near future. If you want to remain on AOL's whitelist, you will need to establish an SPF record for your domain as AOL will begin to query whitelisted IP addresses from a domain's SPF record shortly. Without an SPF record, your whitelist entries may expire. --- And you are right, giving *preferred* treatment for successful authentication (without other tools like a whitelist) is a bad thing to do. Subjecting /un-authenticated/ messages to increased scrutiny might be justified to do though (as Microsoft has announced they will start doing). -Rand From owner-ietf-mxcomp@mail.imc.org Tue Aug 10 23:26:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29235 for ; Tue, 10 Aug 2004 23:26:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B352Eh099681; Tue, 10 Aug 2004 20:05:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B352x8099680; Tue, 10 Aug 2004 20:05:02 -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 i7B352j0099673 for ; Tue, 10 Aug 2004 20:05:02 -0700 (PDT) (envelope-from msk@sendmail.com) Received: from protagonist.smi.sendmail.com ([10.210.202.26]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7B34wSn000601 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 20:04:59 -0700 Received: from protagonist.smi.sendmail.com (localhost [127.0.0.1]) by protagonist.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i7B34wsP070594; Tue, 10 Aug 2004 20:04:58 -0700 (PDT) (envelope-from msk@sendmail.com) Received: from localhost (msk@localhost) by protagonist.smi.sendmail.com (8.12.9/8.12.9/Submit) with ESMTP id i7B34wOI070591; Tue, 10 Aug 2004 20:04:58 -0700 (PDT) (envelope-from msk@sendmail.com) X-Authentication-Warning: protagonist.smi.sendmail.com: msk owned process doing -bs Date: Tue, 10 Aug 2004 20:04:58 -0700 (PDT) From: "Murray S. Kucherawy" X-X-Sender: msk@protagonist.smi.sendmail.com To: Meng Weng Wong cc: Tony Finch , ietf-mxcomp@imc.org Subject: Re: you must fill your zones with TXT records In-Reply-To: <20040811023830.GG28401@dumbo.pobox.com> Message-ID: <20040810200434.O67502@protagonist.smi.sendmail.com> References: <20040811023830.GG28401@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 10 Aug 2004, Meng Weng Wong wrote: > I wonder how feasible it would be to deprecate the implicit MX rule. You mean RFC974? I imagine such a notion would face a great deal of opposition. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 00:37: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 AAA03394 for ; Wed, 11 Aug 2004 00:37: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 i7B4JpeH008432; Tue, 10 Aug 2004 21:19:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B4JpWO008430; Tue, 10 Aug 2004 21:19:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B4JoTu008421 for ; Tue, 10 Aug 2004 21:19:50 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from [192.168.1.13] ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Wed, 11 Aug 2004 00:19:51 -0400 id 002F4041.41199E67.00007656 In-Reply-To: References: <20040810231838.21729.qmail@xuxa.iecc.com> <200408102008.57168.davidb@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: David Blacka Subject: Re: record size and wild cards, was change of version string Date: Wed, 11 Aug 2004 00:19:48 -0400 To: Rand Wacker X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 10, 2004, at 10:56 PM, Rand Wacker wrote: > On Tue, 10 Aug 2004, David Blacka wrote: > >> It is more credible for me to believe that there is DNS software that >> won't >> fall back to TCP, or that there are some that don't actually allocate >> 64k >> (the actual maximum) of space for receiving a message. > > The issue is more operational, there will be quite a bit of resistance > by > site security admins to open up TCP port 53 for queries of that size, > and > even more resitance by sites that receive A LOT of mail to accept the > possibility of making outbound TCP queries for large number of incoming > messages. I'm not sure what you are arguing about, here. I was merely expressing incredulity that a bug of a particular nature would exist, but, I suppose I will have to take John's word for it. I am still trying to imagine *how* this bug could have been written, but I suppose that is really just a lack of imagination on my part. Seriously, falling back to TCP is how DNS works. Firewalls can block it, software can not support it, clients can refuse to do it, but, in doing so, they must accept the responsibility that some of their DNS queries/responses will not work. All we can do is recognize that operational constraints exist and suggest that folks do not publish overly large RR sets, which we appear to be doing. -- David Blacka Sr. Engineer Verisign Applied Research From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 01:09: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 BAA04673 for ; Wed, 11 Aug 2004 01:09: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 i7B4tp46012228; Tue, 10 Aug 2004 21:55: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 i7B4tpF1012227; Tue, 10 Aug 2004 21:55:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B4todo012214 for ; Tue, 10 Aug 2004 21:55:51 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2004 00:55:53 -0400 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7B4tnlF017552; Wed, 11 Aug 2004 00:55:50 -0400 (EDT) Received: from fenton-w2k01.cisco.com (sjc-vpn4-953.cisco.com [10.21.83.184]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7B5S5kZ006098; Tue, 10 Aug 2004 22:28:08 -0700 Message-Id: <4.3.2.7.2.20040810214405.041abdb8@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Aug 2004 21:57:15 -0700 To: Rand Wacker , Meng Weng Wong From: Jim Fenton Subject: Re: change of version string Cc: IETF MARID WG In-Reply-To: References: <20040809231452.GF28401@dumbo.pobox.com> <20040809231452.GF28401@dumbo.pobox.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:"1092202088.674134"; x:"432000"; a:"rsa-sha1"; b:"0:1788"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"ox9l5NNLyh3We58S0yAibqfvy3ZJ0aO9sO0AyHNodjubfX6vMKqFoY+SKbgHb" "aVTlqeqVnYgXJeK9icxA9wbNU3GA7Dsc88w33Yx68lvMeIhAHo89/USsDiP5L" "blWjcKAB1yW6CYAdETk5AWhr0Q6TtrXYkuodmmUv1cP+nC7Ig="; c:"Date: Tue, 10 Aug 2004 21:57:15 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: change of version string" 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 02:59 PM 8/10/2004 -0700, Rand Wacker wrote: >I believe that the working group made no objection to sub-domaining >records (publishing TXT in _marid.example.com), so if we go down the path >of changing the version number or even the format we should take that in >to consideration. I remember that one problem with _marid.example.com was that one lost wildcard behavior; it isn't possible to have _marid.*.example.com to resolve requests for sub.example.com. But it was less clear to me whether one could publish a record for *.example.com and have it work "as desired" for messages from sub.example.com. I have been a bit concerned about the loss of an outgoing counterpart to wildcard MX record behavior. In other words, if you can have wildcard MX records to accept mail for *.example.com, you should be able to have something that indicates the outgoing mail servers for *.example.com. This might be an area where a new RR has an advantage over _marid TXT records. Short of wildcarding, here are a couple of options: 1. The recipient tries the domain in the PRA, and if that fails starts walking up the tree (first sub.example.com, then example.com, then (hopefully not) com) looking for a MARID record. 2. The originator includes a message header indicating the appropriate level of abstraction for the MARID record. So a message from jdoe@sub.example.com might have a header like "MARID-Domain: example.com". I suspect this runs counter to the MARID approach of not changing the 2822 headers. In the MASS world, Identified Internet Mail and DomainKeys both include this with the signature in order to find their keys or key authorization data. Do either of these seem workable? I'm concerned that the wildcards won't do the Right Thing. -Jim From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 01:42: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 BAA05896 for ; Wed, 11 Aug 2004 01:42: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 i7B5RqU9015883; Tue, 10 Aug 2004 22:27: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 i7B5RqJ5015882; Tue, 10 Aug 2004 22:27:52 -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 i7B5Rpbb015860 for ; Tue, 10 Aug 2004 22:27:51 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.153] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 24D3640DD; Tue, 10 Aug 2004 22:27:52 -0700 (PDT) In-Reply-To: <1092177120.5943.3.camel@ddev.mail-abuse.org> References: <1092177120.5943.3.camel@ddev.mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <308F6682-EB57-11D8-A41D-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit Cc: Douglas Otis From: Mark Lentczner Subject: Re: Wildcards not useable Date: Tue, 10 Aug 2004 22:27:51 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 10, 2004, at 3:32 PM, Douglas Otis wrote: > The Not Authorized aspect of CSV-CSA was intended only to offer added > protection, should a system be considered vulnerable to being > compromised. Such as a system may provide web or shell services, but > is > not intended to be sending mail. A specific removal of this host from > being authorized adds additional protections from Trojans. Actually, the Not Authorized CSV record doesn't help against Trojans: Those mailers are never going to use the infected host's domain name in HELO/EHLO. What would help is simply blocking outgoing port 25 access for those hosts. In fact this is much more effective: The receiving MTA doesn't have to support CSV for it to work! If I were a sys. admin., that's what I'd do. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 02:17: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 CAA23227 for ; Wed, 11 Aug 2004 02:17: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 i7B61gB6018779; Tue, 10 Aug 2004 23:01: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 i7B61g4x018778; Tue, 10 Aug 2004 23:01:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B61fUn018769 for ; Tue, 10 Aug 2004 23:01:41 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7B61M77009725 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 11 Aug 2004 02:01:23 -0400 Subject: RE: Does marid-submitter-02 really make sense? From: Mark Shewmaker To: Douglas Otis Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092162895.25379.104.camel@ddev.mail-abuse.org> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1092204280.19686.954.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 02:04:41 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Wed, 11 Aug 2004 02:01:25 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-10 at 14:34, Douglas Otis wrote: > On Tue, 2004-08-10 at 05:42, Mark Shewmaker wrote: > > On Tue, 2004-08-10 at 06:02, Shevek wrote: > > > > 3. Any other not-directly-SenderID test based on SUBMITTER could > > be substituted in (1) or (2) above, such as domain-based reputation > > tests. > > > > (Or full-email-address (!!!) based reputation tests.) > > The Mailbox Domain identified by Submitter can not be used for > reputation checks! Sure you can--you can see if you have white-listed that PRA yourself, or if your trusted friends have--thus giving you reason to believe claims made by this PRA, Or you could filter out PRAs with bad reputations--those appearing on domain-based block lists. This isn't as useful as a sender_agents based end-to-end trust chain, but then again, I did put this "optimization" under the "boring, minor" heading. > Neither Sender-ID nor Submitter stop bounces as there are no checks > against the MAIL FROM. As mail, at many nodes, operates using a store > and forward mechanism, there will always be ample opportunity to create > a bounce. This example is applying a per recipient white-list at the > initial MTA receiver. This assumes all MTAs have been provided these > per-recipient white-lists. This assumption is flawed as there will be > configurations where this does not apply and spammers are expert at > finding them. The problem comes with configurations with per-recipient controls. That's the case I'm worried about. If you're doing per-recipient white-lists, and you don't have SUBMITTER but you want to do SenderID PRA checks anyway, you have to check after DATA. But since you can't reject per-recipient after data, you have to bounce after data instead. But you can't safely bounce after data unless you've had an classic SPF PASS result. And that's a opportunity for spammers to have you send out forged bounces, if you've put yourself into a position to have to send out potentially forged bounces or throw away accepted mail. > > So, here SUBMITTER is a *serious* optimization! > > This is ignoring the likely outcome of this mechanism and the defensive > strategy likely to result. I meant it a bit tongue-in-cheek. If you do get SUBMITTER, then you don't have to worry about being used to generate bounce spam, since you can do per-recipient rejects. (Obviously, there's a problem if another machine of yours has just relayed the message to you--so your rejecting the message would cause it to bounce the message--but that's a separate vulnerability in your setup.) And so you don't have to do all this extra work to counter possible bounce forgery attempts directed at you. Hence, "optimization." > > 2. Run SPF Classic tests on MAIL FROM, and *bounce* messages failing > > SenderID tests. > > I assume you mean Reject messages failing Sender-ID checks. No, I actually mean "bounce." If you are sent a message without SUBMITTER, you have to do SenderID tests after data. But if one recipient's policies has you accepting that message and the other has you not accepting it--after DATA you can't reject per-user, so you have to bounce instead. But you're stuck if you can't safely bounce if you don't have a full SPF PASS. > > Either way, your bandwidth is sucked away like crazy. > > This ignores the required 10 host_checks() functions calls. Assume each > TXT record references 8 MX records which then requires 5 A record > lookups, as in the example by John Levine. That would be 400 DNS > lookups resulting in about 1.3 queries per lookup (520) to arrive at the > 400 answers. If each query resulted in a normal mean of about 100 ms, > that would be 52 seconds, well within the 200 seconds alloted by the > draft. If at about 400 bytes per record (counting both directions), the > resulting traffic could be over 200 kbytes of UDP traffic, for about 8 > kbytes of an average message. But at worst all these queries should be locally cached by the time you get to the first RCPT TO: value. So if your test code doesn't cache data itself, you're just querying dns records cached on your own machine, or on a machine very close to you. And two of the spf test libraries actually do caching internal to the libraries. I'm not very worried about DNS bandwidth. > It seems refusing to accept multiple recipients, as you indicated, on a > normal basis would arrive at the same result. This would work with or > without Submitter, when applying per recipient white-lists at the MTA. > This could be seen as a means to avoid bounces at all costs, to bolster > Sender-ID that does not check MAIL FROM. Yeah. I'm wondering if, were any RFC to come out for an smtp extension allowing per-recipient after-data rejects, if it would soon become acceptable to give "too many recipient" errors on second and subsequent recipients when the sending MTA (!) doesn't support such an extension. > > If you're given SUBMITTER, you can do per-recipient rejects safely, of > > course. But folks who want to trick you into sending their bounce spam > > won't be all nice and give you a cool SUBMITTER to play with--and > > without SUBMITTER you have this yucky issue. > > It seems you have concluded Submitter is not an optimization after all. > This problem of multiple recipients is only when they share the same > receiving MX server as well. It is a meager optimization for the single-recipient case, but in the multiple-recipient case, it's an "optimization" in that it allows you to avoid wasting bandwidth that's necessary to waste if you want to avoid the security issues inherent in doing per-recipient after-data checks. > > (Side note: If you do get SUBMITTER and SUBMITTER!=PRA, then it's safe > > to reject after DATA for *all* recipients, because this is clearly > > either a corrupt or forged mail transmission.) > > That assumes there is a check made at this point. This is the great > downside when allowing Submitter. This check becomes optional and the > modicum of security goes out the window. Without sender_agents, which has end-to-end tests, I don't see why it's so bad if some implementations skip the required SUBMITTER==PRA test, because if you got a message with SUBMITTER!=PRA where the SUBMITTER value would have caused you to accept it if it were equal to the PRA, then the sending machine could have just added a "Resent-From:" at the top of the body headers to have had it pass that SUBMITTER==PRA check. I don't see how the fact that it didn't bother to fill in some paperwork mean that there's a security check. (Now, if Resent-From: included some cryptographic checksum of the rest of the message, that would be a different story--but it doesn't.) -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 03: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 DAA09305 for ; Wed, 11 Aug 2004 03: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 i7B7CUff026747; Wed, 11 Aug 2004 00:12: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 i7B7CUPJ026746; Wed, 11 Aug 2004 00:12:30 -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 i7B7CQvL026737 for ; Wed, 11 Aug 2004 00:12:27 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BunHe-00040P-00 for ; Wed, 11 Aug 2004 09:12:26 +0200 Received: from du-001-193.access.de.clara.net ([212.82.227.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Aug 2004 09:12:26 +0200 Received: from nobody by du-001-193.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Aug 2004 09:12:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: record size and wild cards Date: Wed, 11 Aug 2004 09:11:26 +0200 Organization: Lines: 23 Message-ID: <4119C69E.5C1A@xyzzy.claranet.de> References: <20040810231838.21729.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-193.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 John Levine wrote: > The problem with _marid subdomains is that they break > wildcards, since DNS wildcards don't permit _marid.*.foo.com I'm not exactly sure what you're talking about, my nslookup is not exactly new - what says 5.42 UCB 3/3/91 - and it has no problem with wildcards: _marid.xyzzy.claranet.de text = "v=spf1 redirect=claranet.de" xyzzy.claranet.de text = "v=spf1 redirect=claranet.de" > Some of us have per-user subdomains implemented with > wildcards, and there's no good workaround. xyzzy.claranet.de _is_ a per user vanity host, it's only used for addresses @xyzzy (catch-all), and for http://www.xyzzy So if you have a sender policy for *.example.org now and it covers foo.example.org, then it would automatically cover _marid.foo.example.org Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 03:48:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10248 for ; Wed, 11 Aug 2004 03:48: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 i7B7ZZDY029318; Wed, 11 Aug 2004 00:35: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 i7B7ZZvi029317; Wed, 11 Aug 2004 00:35:35 -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 i7B7ZYSh029311 for ; Wed, 11 Aug 2004 00:35:34 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bune2-0004mA-00 for ; Wed, 11 Aug 2004 09:35:34 +0200 Received: from du-001-193.access.de.clara.net ([212.82.227.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Aug 2004 09:35:34 +0200 Received: from nobody by du-001-193.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Aug 2004 09:35:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Upcoming changes in protocol draft Date: Wed, 11 Aug 2004 09:33:55 +0200 Organization: Lines: 11 Message-ID: <4119CBE3.6069@xyzzy.claranet.de> References: <90BAE9AA-EA4E-11D8-A694-000393A56BB6@glyphic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-193.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: > Here is a partial list of changes that I've made for > draft-ietf-marid-protocol-01: [...] Did you get the minor fix for the IPv6 example (RfC 3849) ? Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 04:17:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11631 for ; Wed, 11 Aug 2004 04:17:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B7vr3u031504; Wed, 11 Aug 2004 00:57:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B7vrrG031503; Wed, 11 Aug 2004 00:57:53 -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 i7B7vq2t031496 for ; Wed, 11 Aug 2004 00:57:52 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49404) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1BunzW-0001XQ-Q4 (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 11 Aug 2004 08:57:46 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BunzW-0008N3-4T; Wed, 11 Aug 2004 08:57:46 +0100 Date: Wed, 11 Aug 2004 08:57:46 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Gordon Fecyk cc: ietf-mxcomp@imc.org Subject: RE: you must fill your zones with TXT records In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553CA@srv1.pan-am.ca> Message-ID: References: <700EEF5641B7E247AC1C9B82C05D125D0553CA@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 Tue, 10 Aug 2004, Gordon Fecyk wrote: > > This is a flaw with every proposal that uses DNS, but it is not an > insurmountable one. The underlying problem is that all the proposals look at one individual RR set at a time. They have no way of advertising a default policy that covers an entire zone. There were some discussions on the SPF list about searching for zone cuts (which would allow you to locate such a default policy) but they didn't get very far. 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 Wed Aug 11 05: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 FAA16265 for ; Wed, 11 Aug 2004 05: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 i7B9KK50055009; Wed, 11 Aug 2004 02:20:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B9KKOL055008; Wed, 11 Aug 2004 02:20:20 -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 i7B9KIIH054981 for ; Wed, 11 Aug 2004 02:20:19 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BupHO-0007jz-00 for ; Wed, 11 Aug 2004 11:20:18 +0200 Received: from du-001-193.access.de.clara.net ([212.82.227.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Aug 2004 11:20:18 +0200 Received: from nobody by du-001-193.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Aug 2004 11:20:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: change of version string Date: Wed, 11 Aug 2004 11:18:05 +0200 Organization: Lines: 52 Message-ID: <4119E44C.6C6E@xyzzy.claranet.de> References: <20040809231452.GF28401@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-193.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > For the vast majority of people, publishing SPF1 records > will be all they need to do or worring about. For those > that require different records for the PRA check vs the MAIL > FROM and HELO checks, they can publish SPF2 records. Existing sender policies use v=spf1 and are meant to check only the MAIL FROM. They don't allow SUBMITTER, where some bounces would be sent again to an innocent MAIL FROM when a malicious SUBMITTER got a PASS for his PRA, and something between MX and MUA detects this or another problem too late for a REJECT. If that's the case then SUBMITTER is incompatible with SPF. And if SUBMITTER is only an accelerated PRA test (allowing early rejection before DATA) then anything not rejected by PRA could later result in bounces to the forged MAIL FROM. I really hate these bounces, and writing a script to send MAIL FROM: SUBMITTER=phisher@directi.example with Sender: trust me is easy, and getting directi.example IN TXT "v=spf1 +all" is cheap. At the moment this would result in a Sender-Id PASS and later probably in a bounce to me. And I don't want this. But I do want to use "my" address From: nobody@xyzzy with an MSA forcing MAIL FROM:, and I don't want this to be rejected based on the v=spf1 sender policy for xyzzy. Therefore somebody wanting PRA _and_ MAIL FROM tests has to say so in his sender policy, because that's the unusual case after months of propagating and implementig SPF classic. There are numerous documents and articles "in the wild" explaining classic SPF, and they don't say "but you can't use your address in From: headers anymore unless [PRA]". > it is like asking these two questions about the president: > a) Is the current occupant of the U.S. Presidency over > the age of 35? > b) Is the current occupant of the U.S. Presidency a U.S. > citizen? PRA asks "is a U.S. citizen over the age of 35 eligible as president ?" SPF classic asks "is the U.S. president a U.S. citizen over the age of 35 ?" The answers can be different. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 06:07: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 GAA17482 for ; Wed, 11 Aug 2004 06:07: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 i7B9nxnK067217; Wed, 11 Aug 2004 02:49: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 i7B9nxaf067216; Wed, 11 Aug 2004 02:49:59 -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 i7B9nun9067181 for ; Wed, 11 Aug 2004 02:49:58 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: you must fill your zones with TXT records X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 11 Aug 2004 04:49:57 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D0553CB@srv1.pan-am.ca> Thread-Topic: you must fill your zones with TXT records Thread-Index: AcR/eOX/bMbCEKrORgGHLVX68SGOdwADYLPw From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7B9nxn9067210 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > The underlying problem is that all the proposals look at one > individual RR set at a time. > They have no way of advertising a default policy that > covers an entire zone. That is a fault of using DNS to begin with. At least, without modifying DNS software to synthesize "default" records to certain kinds of lookups. DNS is supposed to respond with NXDOMAIN if a record isn't found. Now, last I checked, nothing stops a DNS implementation from returning a "default" record. That's not the same as a wildcard record as wildcard semantics are clearly defined in RFC 1034 4.3.2. What I'm talking about could be implementation-specific, for example in BIND 9-speak: zone "example.com." { type master; file "forward/example.com.dns"; if (query == TXT && record == FALSE) record = (whatever a "deny" is); }; This wouldn't require a site to use such a DNS server, but it would give operators using such a capable DNS server an advantage. It also wouldn't require changing the specs here. I can see DNS folks cringing now. -- 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 Aug 11 06:07: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 GAA17514 for ; Wed, 11 Aug 2004 06:07: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 i7B9nvhm067194; Wed, 11 Aug 2004 02:49:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B9nvHc067193; Wed, 11 Aug 2004 02:49:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B9nuRP067169 for ; Wed, 11 Aug 2004 02:49:56 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7B9x3WC017931 for ; Wed, 11 Aug 2004 02:59:03 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7B9x3Ms017928 for ; Wed, 11 Aug 2004 02:59:03 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 11 Aug 2004 02:59:03 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID WG Subject: Re: change of version string In-Reply-To: <20040811015107.GA602@raven.songbird.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: > > > example.com TXT "v=spf1 a mx ptr" > > > example.com TXT "v=spf2 a mx ptr" > > > > > example.com 3600 IN 104 "a mx ptr" > > example.com 3600 IN 105 "a mx ptr" Perhaps it would be usefull if we allow one type of SPF record to reference (include, refer to) another type of SPF record, this would eliminate duplication problems in case of long records and avoid issues with large dns packet (because of multiple large txt records) as well. Right now in the drafts published it is not clear if this is allowed, but my reading from MARID drafts is that for MARID (i.e. v=spf2 or v=marid1, whatever) it is not and in case of reference, it must refer to the same v=marid type/version txt record. I understand this to be the resolt of an issue in that we can not easily reference different txt records for the same domain (FQDN), especially a problem when you have to reference same FQDN as the record itself (i.e. like with above example). So to change that it would be necessary to slightly enhanced syntax to allow include to specify type (version) of SPF txt record. An example of what I'm proposing is below: example.com TXT "v=spf1 a mx ptr" example.com TXT "v=spf2 include:example.com/v=spf1" (ok from the above example the include itself is longer the original record, but for longer records, it makes more sense) > The issue of where the version number is located is independent of the > record type. Not quite, if we go with pure TXT-like record for new MARID dns type, then versioning is expected to be done same as with SPF TXT record (i.e. its part of the data text portion), But when doing new dns record type we do have an option of having some required parts of the data put into their own specified binary locations in record separate from main text portion. In case of version number this saves a little (2 bytes taken by "v=") on the size of typical record. So for example record would look like: example.com SPF 1 "a mx ptr" rather then pure text representation like example.com SPF "v=1 a mx ptr" But doing it with one byte (or two bytes just in case) for version number does mean we're adding something new for IANA to keep track off and adding new version type can not be done by "name" (i.e. "spf1" or "marid1") and it we're expecting for all clients to know version number or be able to look it up by name in IANA records. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 07: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 HAA23361 for ; Wed, 11 Aug 2004 07: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 i7BBTWrh002526; Wed, 11 Aug 2004 04: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 i7BBTWPr002525; Wed, 11 Aug 2004 04:29:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from Mail-Out.Odessa.Net (Mail-OUT.Odessa.Net [195.66.204.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBTSap002491 for ; Wed, 11 Aug 2004 04:29:30 -0700 (PDT) (envelope-from ietf-mxcomp@spam.24.odessa.ua) Message-Id: <200408111129.i7BBTSap002491@above.proper.com> Received: (qmail 60996 invoked by uid 1166); 11 Aug 2004 14:36:01 +0300 Received: from ietf-mxcomp@spam.24.odessa.ua by mail.odessa.net by uid 89 with qmail-scanner-1.20 (f-prot: 4.3.3/3.14.8. Clear:RC:1(62.16.6.18):. Processed in 0.542583 secs); 11 Aug 2004 11:36:01 -0000 Received: from unknown (HELO tag) (62.16.6.18) by mail.odessa.net with SMTP; 11 Aug 2004 14:36:00 +0300 From: "Andriy G. Tereshchenko" To: "'Gordon Fecyk'" Cc: Subject: RE: you must fill your zones with TXT records Date: Wed, 11 Aug 2004 14:29:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1218 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553CB@srv1.pan-am.ca> Thread-Index: AcR/eOX/bMbCEKrORgGHLVX68SGOdwADYLPwAAOKFyA= X-Qmail-Scanner-Message-ID: <109222416165260984@mail.odessa.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > From: Behalf Of Gordon Fecyk > Sent: Wednesday, August 11, 2004 12:50 PM > [...] > Now, last I checked, nothing stops a DNS implementation from > returning a "default" record. That's not the same as a > wildcard record as wildcard semantics are clearly defined in > RFC 1034 4.3.2. What I'm talking about could be > implementation-specific, for example in BIND 9-speak: > > zone "example.com." { > type master; > file "forward/example.com.dns"; > if (query == TXT && record == FALSE) > record = (whatever a "deny" is); > }; > Sure. This is one of reasons subdomains must be used. if (query == TXT && record == FALSE) { if(request.startWith("spfv1.")) record = (whatever a "SPF1 deny" is); if(request.startWith("_ep.")) record = (whatever a "Sender-ID deny" is); if(request.startWith("_VOUCH._SMTP.")) record = (whatever a "DNA deny" is); } or for example using DNS proxy then new record type adopted: if(request.startWith("spfv1.")) { query = RMX; retry(); } -- Andriy G. Tereshchenko Odessa, Ukraine From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 07: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 HAA23646 for ; Wed, 11 Aug 2004 07: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 i7BBYtET004398; Wed, 11 Aug 2004 04:34:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BBYtkW004397; Wed, 11 Aug 2004 04:34:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBYrbY004336 for ; Wed, 11 Aug 2004 04:34:54 -0700 (PDT) (envelope-from pk@TechFak.Uni-Bielefeld.DE) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i7BBYlOV022691 for ; Wed, 11 Aug 2004 13:34:48 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i7BBYlO22161 for ; Wed, 11 Aug 2004 13:34:47 +0200 (MEST) Message-Id: <200408111134.i7BBYlO22161@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: ietf-mxcomp@imc.org Subject: Re: record size and wild cards, was change of version string In-reply-to: Your message of "11 Aug 2004 00:56:33 -0000." <20040811005633.23052.qmail@xuxa.iecc.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22156.1092224085.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 11 Aug 2004 13:34:47 +0200 From: Peter Koch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Levine wrote: > Yes. I was surprised to learn that there is a bug in widely used > resolver libraries so that if it makes a TCP request, and the response > isn't entirely contained in the first packet, the resolver gives up and could we please have a bit more facts on the table? Which implementation is that and up to which version? > Believe it. I think it's due to bugs in the code that waits for a > response or a timeout and doesn't go back to look for more data after > getting the first data chunk back. Given how few DNS queries have So that would be a resolver that implements at least part of TCP on its own? Again, names please. There have been far too many rumors and hearsay wrt DNS on this list. > needed TCP, and how few of the responses have been too big to fit in a > 1500 MTU, it's not surprising nobody's noticed before. 1500 is not a critical number here, 512 is. An there are lots of answers that do need >512 octets, especially in the IN-ADDR tree. -Peter From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 08:02: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 IAA25245 for ; Wed, 11 Aug 2004 08:02: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 i7BBfMrL006760; Wed, 11 Aug 2004 04:41: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 i7BBfMSH006759; Wed, 11 Aug 2004 04:41: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 i7BBfLQa006748 for ; Wed, 11 Aug 2004 04:41: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 i7BBoSpE020926; Wed, 11 Aug 2004 04:50:28 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7BBoPTn020921; Wed, 11 Aug 2004 04:50:28 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 11 Aug 2004 04:50:25 -0700 (PDT) From: "william(at)elan.net" To: Rand Wacker cc: John Levine , Subject: Re: record size and wild cards, was change of version string In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 10 Aug 2004, Rand Wacker wrote: > I seem to recall at the WG meeting that people *did not object* to > breaking wildcards. Perhaps we were at different meetings, for I do not remember this. Wildcards were not in fact discussed at WG meeting in any serious manner as it was understood that SPF TXT records were easy with wildcards as they go directly under the domain and so will future dns specific record type. As such people were not objecting because wildcards were in fact already part of the design and fully supported. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 08:17:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26951 for ; Wed, 11 Aug 2004 08:17: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 i7BBsBnx010932; Wed, 11 Aug 2004 04:54: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 i7BBsBPO010931; Wed, 11 Aug 2004 04:54:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7BBs7VP010883 for ; Wed, 11 Aug 2004 04:54:10 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id D6BD61A6BF; Wed, 11 Aug 2004 13:54:03 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id A229F1A6BD for ; Wed, 11 Aug 2004 13:54:01 +0200 (CEST) Message-Id: <8upOaLp9dykgJ7yQ2jr8Hw.md5@prosecco.oryx.com> Date: Wed, 11 Aug 2004 13:54:20 +0200 From: Arnt Gulbrandsen To: Peter Koch Subject: Re: record size and wild cards, was change of version string Cc: ietf-mxcomp@imc.org References: <200408111134.i7BBYlO22161@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200408111134.i7BBYlO22161@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter Koch writes: > So that would be a resolver that implements at least part of TCP on its own? No, anything that uses nonblocking I/O would be vulnerable to this programming error. It's not unusual. To name one well-known product: the Cisco PIX had a similar error in its SMTP implementation a year or three ago. It could be that on some platforms, code using blocking I/O could be vulnerable too. It's been a few years since I looked into this in detail. Suffice to say: It's an easy mistake to make. Arnt From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 09:41: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 JAA04226 for ; Wed, 11 Aug 2004 09:41: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 i7BDQM0X041710; Wed, 11 Aug 2004 06:26: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 i7BDQMi7041709; Wed, 11 Aug 2004 06:26:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BDQLDt041697 for ; Wed, 11 Aug 2004 06:26:22 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 13:26:16 +0000 From: "Michael R. Brumm" To: Subject: SUBMITTER/PRA Allows Spread of Viruses, Too (was: Will Accepting SUBMITTER Get You Blacklisted?) Date: Wed, 11 Aug 2004 07:26:23 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 11 Aug 2004 13:26:16.0997 (UTC) FILETIME=[C8002D50:01C47FA6] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Michael R. Brumm wrote: > SUBMITTER allows forged bounces to be injected onto > forwarders (even with PRA checks). The bounces go to a third party > (the MAIL FROM), which may see the forged bounces as spam/viruses from > the forwarder (not the injector). This could cause the forwarder > (which is only following the SUBMITTER protocol) to be blacklisted. Graham Murray wrote: >Which can be avoided by the forwarder doing SPF classic (or >equivalent) checks to validate the MAIL FROM, and rejecting the mail >if this fails, as well as performing SUBMITTER checks. Which is why I >think that it is important that whatever may be decided about PRA, >SUBMITTER and RCF2822 checks, that it is still important to do perform >MAIL FROM checks to prevent such injections. I agree. Validating the MAIL FROM should be a requirement, and the SUBMITTER/PRA evaluation should never allow a MAIL FROM failure to be bypassed. Otherwise, the attack scenario leaves a gaping security hole which spammers, viruses, and DOS attackers will use. If however, the MAIL FROM evaluation is a MUST, then I'm not sure how the PRA is relevant at all... If MAIL FROM is the primary (and non-overridable) evaluation scheme, then all forwarded mail will use rewriting. So, the PRA will not match the sending MTA. Wouldn't that just break forwarding? Graham Murray wrote: >Your scenario also shows that it is unwise to include the message body >in bounces. Forwarder is less likely to be blacklisted if the bounces >do not contain the spam/virus payload (but that is not the province of >this list) While it is true that *not* including the message body in bounces would prevent the spread of many viruses, it would not mitigate this attack by much. 1) Volume could be the deciding factor: If I get 1,000 fake bounces to my postmaster account from the same domain, I'm probably going to blacklist no matter what is contained in the bounce payload. 2) If you include the Subject of the message in the bounce, it can include the spammer's/virus' payload. For example: Subject: Hungry? Visit http://www.get.your.freefood.com/ or Subject: Why Are You Getting This? Read: http://www.stop-these-messages.com/ The page could then contain the real spam, or a browser buffer-overrun exploit which propagates the virus. So, are the current MARID proposals going to allow this? If so, is this going to be mentioned in the "Security Considerations"? Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 10:22: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 KAA07931 for ; Wed, 11 Aug 2004 10:22: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 i7BE5YKH046262; Wed, 11 Aug 2004 07:05: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 i7BE5YoI046261; Wed, 11 Aug 2004 07:05: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 i7BE5YqQ046253 for ; Wed, 11 Aug 2004 07:05:34 -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, 11 Aug 2004 10:05:34 -0400 id 00197693.411A27AE.00006EB9 In-Reply-To: References: <20040810231838.21729.qmail@xuxa.iecc.com> <200408102008.57168.davidb@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <82C068E3-EB9F-11D8-97B2-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org, Rand Wacker From: Andrew Newton Subject: Re: record size and wild cards, was change of version string Date: Wed, 11 Aug 2004 10:05:33 -0400 To: David Blacka 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 Aug 11, 2004, at 12:19 AM, David Blacka wrote: > I am still trying to imagine *how* this bug could have been written, > but I suppose that is really just a lack of imagination on my part. Me too, as in I'm trying to imagine which API they used and why? -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 10:35: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 KAA09036 for ; Wed, 11 Aug 2004 10:35: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 i7BEKAwY047651; Wed, 11 Aug 2004 07:20:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BEKALs047650; Wed, 11 Aug 2004 07:20:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEKAnB047644 for ; Wed, 11 Aug 2004 07:20:10 -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, 11 Aug 2004 10:20:12 -0400 id 00197693.411A2B1C.0000702F Mime-Version: 1.0 (Apple Message framework v618) Message-Id: <8E065FFE-EBA1-11D8-97B2-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed To: "ietf mxcomp \"(e-mail)" From: Andrew Newton Subject: draft minutes of the San Diego meeting Date: Wed, 11 Aug 2004 10:20:11 -0400 X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BEKAnB047645 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The following are draft minutes of the MARID session at the IETF 60 meeting in San Diego. Please have comments and/or corrections to me no later than 18 August 2004. -andy Minutes of the MARID Working Group Sessions at the 60th IETF Meeting Sessions: 04 August 2004 09:00 – 11:30 US-PDT 04 August 2004 15:30 – 17:30 US-PDT Chairs: Marshall T. Rose mrose+mtr.mxcomp@dbc.mtview.ca.us Andrew Newton andy@hxr.us Scribes: George Michaelson Peter Saint-Andre Jabber Logs: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html Consensus Positions: - From topic 3, change of the version identifier in the Sender ID record to indicate check of PRA instead of MAIL FROM. - From topic 5, PRA to be placed into a draft separate from draft-ietf-marid-core-02. - From topic 5, working group last call for draft- ietf-marid-protocol, draft-ietf-marid-submitter, and draft-ietf-marid-core will be held August 23. - From topic 5, alternate proposals for PRA will not be discussed until after working group last call. - From topic 6, accreditation proposals for Sender ID would be accepted but it had to meet the same timeline (wglc on August 23). - From topic 6, working group last call for CSV will being October 11. 1) Agenda Bashing Andy Newton presented the agenda for both sessions and asked for any suggested modifications. None were offered. 2) draft-ietf-marid-submitter-02 Harry Katz gave a brief overview of Sender ID and how this draft fits into the three documents, an explanation of how SUBMITTER is to work, some example SMTP transaction using SUBMITTER, and a description of the changes in from –02 to –01. Harry then accepted questions from the floor. Much of the discussion about SUBMITTER centered on the possible policy of receivers to require this extension. Some participants questioned the utility of this extension because they felt spammers would obviously not implement it. Others suggested that once enough "good guys" started using SUBMITTER, spammers would be forced into using in order to get their mail delivered. There was some discussion over signaling the intent of the receiving MTA vs. having the receiving MTA clearly state rejection policy. It was pointed out that many of the participants were getting confused over the mandatory use of SUBMITTER when it differed from MAIL FROM. It was suggested that the word "submitter" had the wrong meaning for the purpose of the extension. Harry expressed indifference and welcomed suggestions for change. The room also discussed the bandwidth savings potential of SUBMITTER. Some participants claimed that small spam messages were delivered in stateless transactions that fit inside the TCP queue therefore eliminating any bandwidth savings. Others noted that spammers generally are not concerned about bandwidth when using zombies. This argument was countered with the observation that mail infrastructure for many institutions was a complex process and therefore SUBMITTER could be used to reject mail before entering a long pipeline. 3) draft-ietf-marid-protocol-00 Mark Lentczner presented this draft and stated there are a number of items that needed to be addressed for the next revision but claimed most were minor in nature. He started with a discussion of the ABNF had a parsing error with CIDR notation. Mark explained the current concern with the EXP modifier and that some people have stated that it does not adequately support internationalization. There was short discussion about URI’s being the appropriate mechanism to point to internationalized messages. The possibility of a URI being a security concern was mentioned, but Mark explained that the URI would be displayed to the users of the sending domain and therefore this was a trust issue between an ISP and their customers. There was some disagreement regarding the nature of these URI’s in phishing attacks. Mark pointed out that URI’s in bounces occur today and therefore this would be nothing new. The room discussed the version identifier in the TXT record. Mark introduced the subject by explaining that most people today publish "v=SPF1" with the intention that receivers will be checking MAIL FROM and not PRA. Many participants expressed concern over the semantic meaning and suggested the version number would change. Marshall asked if anybody in the room had any serious objections to changing the version identifier; none were given. Andy directed Mark to send suggestions for the new version identifier to the list where this would be discussed. A long discussion on DNS issues was then undertaken by the room. Participants discussed the issues of using new DNS record types instead of TXT record types, the usage of prefixes to avoid conflicts, and the utility of wildcards. Many participants expressed concern with codifying the use of TXT records. Mark noted the definition of a new DNS record type and the eventual transition to it. Other participants related their experiences with SRV records and the inability to use them. Many in the room asked that deployment considerations be given equal consideration to architectural considerations and suggested that few were truly happy with the use of TXT records but many understood the importance of the compromise. After much discussion about wildcards, the sense of the room was that they are not as practical as they appear to be. 4) Intellectual Property Discussion Andy introduced the IPR discussion with a slide asking three questions: what parts of Sender ID are covered by IPR claims, are the terms for licensing the IPR acceptable, and are there any trademark issues? Harry Katz was then invited to speak. In answering the questions, he stated that Microsoft claims IPR covered in draft-ietf-marid-core-02. He stated the current IPR claim with the IETF will be updated to speak of Sender ID instead of Caller ID. Regarding the licensing, he will gather feedback from the meeting to be given to Microsoft lawyers. And for the trademark, it is the opinion of Microsoft that "Sender ID" is too generic to be a valid trademark. He then solicited questions from the floor. During the questioning and discussion, two vendors stated that they were working with Microsoft and it was their intent that IPR for Sender ID be compatible with free software. One participant even stated that his company had found a backdoor to make defensive patents work with the GPL. This discussion concluded with a note from the co-chairs about how the working group would resolve this matter. Issues regarding licensing will be resolved at working group last call, but that the date set for working group last call will be final. 5) draft-ietf-marid-core-02 Jim Lyons presented on the changes to this draft since last revision. He then accepted questions from the floor. The room discussed the PRA algorithm’s assumptions regarding the ordering of headers. Some participants pointed out that header ordering was already specified but not in one place. Some participants suggested moving the PRA algorithm out of draft-ietf-marid-core-02 and into a separate draft because they believe it is more useful. The co-chairs asked for a hum on this issue and found that there was no objection to splitting them out into two separate drafts. Marshall then led a discussion about the timeline for these documents. The room agreed that revisions to the documents would be published August 13 and a two-week working group last call would then start on August 23. The room also discussed the need to have draft-ietf-marid-submitter-02 go to working group last call at the same time, and it was agreed that it would. Some participants asked if alternative proposals or previously discussed proposals would be considered if the working group rejects the IPR license for draft-ietf-marid- core-02. It was the decision of the co-chairs that such drafts should be immediately submitted to the drafts repository but that working group discussion should only focus on the current set of drafts until it was known that draft-ietf-marid-core-02 would not go forward. 6) CSV and Milestones Dave Crocker gave a short presentation on the CSV drafts and then answered a few clarifying questions. A short discussion was had regarding accreditation. It was asked if an accreditation draft would be accepted for the Sender ID proposals similar in nature to the DNA draft in the CSV proposals. It was the decision of the co-chairs that such a draft would be accepted if it met the same deadlines as the other Sender ID drafts: to be submitted by August 13 and to be working group last called by August 23. The room then discussed timelines for the CSV proposal. It was agreed upon that a working group last call for them would begin October 11. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 10:50:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09876 for ; Wed, 11 Aug 2004 10:50:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEaL8i048713; Wed, 11 Aug 2004 07:36: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 i7BEaLKi048712; Wed, 11 Aug 2004 07:36: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 i7BEaKF0048706 for ; Wed, 11 Aug 2004 07:36:20 -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 CDB2F16E1F for ; Wed, 11 Aug 2004 10:44:36 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? In-Reply-To: Your message of "Tue, 10 Aug 2004 19:45:02 EDT." Date: Wed, 11 Aug 2004 10:44:36 -0400 Message-Id: <20040811144436.CDB2F16E1F@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > And no, I'm not referring to the fact that forwarded mail can only > authenticate to the last sender. I'm refering to the fact that anyone at > AOL.com can pretend to be anyone else at AOL.com. That's AOL's problem. If you can prove you got "bad" email from AOL, it's their responsibility to track down the cause & fix it. How is the scenario you quote any different from a user at AOL sending bad mail, "from" himself? Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 10:51:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09979 for ; Wed, 11 Aug 2004 10:51: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 i7BEXdVf048568; Wed, 11 Aug 2004 07:33: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 i7BEXdGv048567; Wed, 11 Aug 2004 07:33:39 -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 i7BEXYDR048557 for ; Wed, 11 Aug 2004 07:33:39 -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 448A217120 for ; Wed, 11 Aug 2004 10:41:43 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: How is SPF different from RMX? In-Reply-To: Your message of "Tue, 10 Aug 2004 19:28:34 EDT." Date: Wed, 11 Aug 2004 10:41:43 -0400 Message-Id: <20040811144143.448A217120@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > I don't see how reputation has anything to do with SPF. The domain owner > simply puts in an SPF txt record. Entities of bad reputation can easily > create SPF records. When MTA authentication is used *correctly* in conjunction with anti-spam systems, publishing those records doesn't help "entitites of bad reputation". Publishing the records allows any recipient to know when originators are non-authentic. So if spammer A decides to forge the domain of spammer B, and spammer B publishes authentication records, you can catch that forgery. But it doesn't, and shouldn't, help a spammer send messages from their own domain. > The authentication and accountability aspects of SPF are illusory and are > not achievable in the SPF proposal as it stands, nor can DNS be used to > achieve these goals. This subject has been discussed at length on the > DNSOP and DNSEXT lists, and it is generally agreed that DNS cannot be the > basis of authentication. MX records say "this is the authentic place to send mail for the domain". RMX records say "this is the authentic place mail comes from for the domain". I don't see why the records are drastically different in scope. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 11:04:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11095 for ; Wed, 11 Aug 2004 11:04:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEkIvo049666; Wed, 11 Aug 2004 07:46:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BEkICj049665; Wed, 11 Aug 2004 07:46:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEkHsq049654 for ; Wed, 11 Aug 2004 07:46:17 -0700 (PDT) (envelope-from mike@mtcc.com) Received: (from mike@localhost) by mtcc.com (8.12.10/8.12.10) id i7BEkFUm020871; Wed, 11 Aug 2004 07:46:15 -0700 To: John Levine Cc: ietf-mxcomp@imc.org, rand@sendmail.com Subject: Re: record size and wild cards, was change of version string References: <20040810231838.21729.qmail@xuxa.iecc.com> X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! From: Michael Thomas Date: 11 Aug 2004 07:46:15 -0700 In-Reply-To: <20040810231838.21729.qmail@xuxa.iecc.com> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Levine writes: > The problem with _marid subdomains is that they break wildcards, since > DNS wildcards don't permit _marid.*.foo.com. Some of us have per-user > subdomains implemented with wildcards, and there's no good workaround. > We could publish the TXT records for *.foo.com and let the clients > throw out the ones they don't understand, but then we're back to > stuffing all the TXT records into the same packet. Forgive me since this is undoubtedly in the copious archives, but what is the scenario here that breaks? If I had a user subdomain off of the main domain like: user1.example.com couldn't I just publish a record like: _marid.user1.example.com ? Or is the problem that you'd need to enumerate each of your users? Or am I completely in the weeds here? And do you have any sense of how many sites would be impacted (ie, are we in 80/20 rule territory here)? -- Michael Thomas (mike@mtcc.com http://www.mtcc.com/~mike/) From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 11:07: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 LAA11367 for ; Wed, 11 Aug 2004 11:07: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 i7BErMA1050185; Wed, 11 Aug 2004 07:53: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 i7BErMoD050184; Wed, 11 Aug 2004 07:53:22 -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 i7BErLUk050176 for ; Wed, 11 Aug 2004 07:53:22 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040811145322.NGIN4758.tomts13-srv.bellnexxia.net@ibmrkydk2ufvdd>; Wed, 11 Aug 2004 10:53:22 -0400 From: "John Glube" To: "'Dean Anderson'" Cc: "'Michel Bouissou'" , "'IETF MARID WG'" Subject: RE: How is SPF different from RMX? Date: Wed, 11 Aug 2004 10:53:03 -0400 Message-ID: <002b01c47fb2$e8f7b2b0$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 i7BErMUk050179 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dean - >The main issue John is disputing above seems to be whether >junk mail mostly comes from virus infected machines (as I >suspect) or whether it comes from commercial emailers >breaking the law (as I think John thinks). This is >basically a quibble. Actually, the underlying issue from my perspective was your reliance on a report which you claim was published by the Federal Trade Commission containing a set of statistics which you claim supports your conclusion as to UBE sources. My problem? I can not find this report to verify your conclusions and you have not provided a working link to the Commission report you claim supports your position. Having said this, as noted previously, this is not directly relevant to the issue at hand. Why? It is my understanding the purpose of this discussion list is to provide constructive comment on the design proposals presently before the WG. As to the remainder of your comments, I fully respect your right to express your views in counter to mine. Let me explain why I do not propose to go further with the debate. The time and place for this debate was when the IETF decided to form this working group. To go further would be to wander far from the purpose of this list given the working group's charter. Finally, you go on to write: >The authentication and accountability aspects of SPF are >illusory and are not achievable in the SPF proposal as it >stands, nor can DNS be used to achieve these goals. This >subject has been discussed at length on the DNSOP and >DNSEXT lists, and it is generally agreed that DNS cannot be >the basis of authentication. Dean, this is a most serious charge. However, it is made without specific proof or example. At the behest of myself and others, the WG chairs are soliciting operational and security reviews of the marid draft proposals (with a focus on the PRA algorithm) from the graybeards, based on the various specific concerns raised on this list and during the formal meetings of the MARID WG. Also, the WG chairs have arranged for tests to be conducted of Sender-ID and CSV (not Sender-ID versus CSV) by a large American ISP with the results to be reported back to this WG. In my view, this is the appropriate course for this WG to take to assess the design benefits of Sender-ID. I write Sender-ID, because the concepts behind SPF and Caller-ID have been merged and a new design was brought forward in mid-July, to be titled Sender-ID. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 11: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 LAA11956 for ; Wed, 11 Aug 2004 11:17:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BExCZx050683; Wed, 11 Aug 2004 07: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 i7BExCZX050676; Wed, 11 Aug 2004 07:59:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BExBcR050651 for ; Wed, 11 Aug 2004 07:59:11 -0700 (PDT) (envelope-from mike@mtcc.com) Received: (from mike@localhost) by mtcc.com (8.12.10/8.12.10) id i7BExDmF022775; Wed, 11 Aug 2004 07:59:13 -0700 To: Rand Wacker Cc: David Blacka , ietf-mxcomp@imc.org Subject: Re: record size and wild cards, was change of version string References: <20040810231838.21729.qmail@xuxa.iecc.com> <200408102008.57168.davidb@verisignlabs.com> X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! From: Michael Thomas Date: 11 Aug 2004 07:59:13 -0700 In-Reply-To: Message-ID: Lines: 31 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Rand Wacker writes: > On Tue, 10 Aug 2004, David Blacka wrote: > > > It is more credible for me to believe that there is DNS software that won't > > fall back to TCP, or that there are some that don't actually allocate 64k > > (the actual maximum) of space for receiving a message. > > The issue is more operational, there will be quite a bit of resistance by > site security admins to open up TCP port 53 for queries of that size, and > even more resitance by sites that receive A LOT of mail to accept the > possibility of making outbound TCP queries for large number of incoming > messages. More importantly, it calls into question why you'd want to use DNS in the first place. The nice aspect of DNS is that you have exactly one round trip with UDP. At the point that you have to truncate a response and refetch the entire RR set using TCP (assuming that you don't tickle the TCP bug John refers to), you might as well have used DNS to do an A or SRV lookup and used some _other_ tcp service that's assumedly more appropriate and/or purpose built for this application. So keeping the likelihood of < MTU size on the RR set seems like it out to be a _requirement_ since this wg is chartered to use DNS, and thus be DNS friendly. If it comes down to a tradeoff with wildcards, we'll just have to decide which is friendlier... but transport unfriendly DNS seems like a pretty bad option. -- Michael Thomas (mike@mtcc.com http://www.mtcc.com/~mike/) From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 11:27: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 LAA12544 for ; Wed, 11 Aug 2004 11:27: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 i7BFEJhg052005; Wed, 11 Aug 2004 08:14: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 i7BFEJIc052004; Wed, 11 Aug 2004 08:14:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFEITL051998 for ; Wed, 11 Aug 2004 08:14:18 -0700 (PDT) (envelope-from mike@mtcc.com) Received: (from mike@localhost) by mtcc.com (8.12.10/8.12.10) id i7BFE748025025; Wed, 11 Aug 2004 08:14:07 -0700 To: "Harry Katz" Cc: , "Shevek" , Subject: Re: Does marid-submitter-02 really make sense? References: X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! From: Michael Thomas Date: 11 Aug 2004 08:14:07 -0700 In-Reply-To: Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: "Harry Katz" writes: > On Monday, August 09, 2004 10:24 AM ned.freed@mrochek.com wrote: > > > First, I am not proposing anything here. Not only is > > SUBMITTER not my idea, I have been quite clear that I am > > ambivalent about its inclusion in MARID. > > > > Second, the optimization in case 1 isn't a failure case but a > > success case. > > There may be a throughput improvement in some MTAs if the > > check can be done sooner. Mind you, I'm not saying there is > > guaranteed to be such an improvement > > - just that it is a possibility. Actual implementation > > experience would be needed to tell for sure. > > > > Ned is exactly correct here. The purpose of SUBMITTER is to allow early > (i.e. at 2821-time) verification of the sender's identity, namely the > PRA. At the IETF meetings last week there was some discussion of > whether this would result in bandwidth saving, throughput improvement, > or no benefit at all. I tend to think there will be modest throughput > improvement, but agree with Ned that we need to verify through testing. The issue that I have here is that the optimization is misplaced engineering at best, and possibly the victim of unintended consequences at worst. The ultimate optimization is for spammers to not send _any_ packets at all. One thing that we know is that if we close off one avenue, spammers will shift their attention to other lines of attack. Thus if the base level check prevents forgery, they'll switch to a line of attack that doesn't use forgery. Creating a lot of infrastructure to optimize for a likely deprecated behavior doesn't strike me as an especially worthwhile use of engineering resources. On the harmful front, I have lingering doubts and worry a lot about what the consequences for mischief of introducing yet another identity -- and what exactly it means. I don't think we should take that lightly; if it has utility on its *own* merits, fine, but as currently instantiated as an optimization for MARID, it seems rather useless since spammers will simply never use this extension. -- Michael Thomas (mike@mtcc.com http://www.mtcc.com/~mike/) From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 11:58:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14696 for ; Wed, 11 Aug 2004 11:58:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFgnHm054897; Wed, 11 Aug 2004 08:42:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BFgnOQ054896; Wed, 11 Aug 2004 08:42:49 -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 i7BFgmSv054866 for ; Wed, 11 Aug 2004 08:42:48 -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 i7BFgeAJ017237 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 Aug 2004 08:42:41 -0700 Date: Wed, 11 Aug 2004 08:42:40 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: "william(at)elan.net" cc: John Levine , ietf-mxcomp@imc.org Subject: Re: record size and wild cards, was change of version string 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, 11 Aug 2004, william(at)elan.net wrote: > On Tue, 10 Aug 2004, Rand Wacker wrote: > > > I seem to recall at the WG meeting that people *did not object* to > > breaking wildcards. > > Perhaps we were at different meetings, for I do not remember this. > > Wildcards were not in fact discussed at WG meeting in any serious manner > as it was understood that SPF TXT records were easy with wildcards as they > go directly under the domain and so will future dns specific record type. This was during the -protocol discussion when Mark was up on the blocks. Excerpt from the meeting minutes that Andrew just posted: --- A long discussion on DNS issues was then undertaken by the room. Participants discussed the issues of using new DNS record types instead of TXT record types, the usage of prefixes to avoid conflicts, and the utility of wildcards. Many participants expressed concern with codifying the use of TXT records. Mark noted the definition of a new DNS record type and the eventual transition to it. Other participants related their experiences with SRV records and the inability to use them. Many in the room asked that deployment considerations be given equal consideration to architectural considerations and suggested that few were truly happy with the use of TXT records but many understood the importance of the compromise. After much discussion about wildcards, the sense of the room was that they are not as practical as they appear to be. --- -Rand From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 12:12:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16009 for ; Wed, 11 Aug 2004 12:12: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 i7BFwL0j056990; Wed, 11 Aug 2004 08:58:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BFwL2w056989; Wed, 11 Aug 2004 08:58: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 i7BFwL63056983 for ; Wed, 11 Aug 2004 08:58:21 -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, 11 Aug 2004 11:58:22 -0400 id 00197693.411A421E.00007E6A Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <44AA2DCF-EBAF-11D8-97B2-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: Does marid-submitter-02 really make sense? Date: Wed, 11 Aug 2004 11:58:21 -0400 To: "ietf mxcomp \"(e-mail)" 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 Aug 11, 2004, at 11:14 AM, Michael Thomas wrote: > Thus if the base level check prevents forgery, > they'll switch to a line of attack that doesn't use > forgery. At that point, our job is done. Not meaning to single out Michael, but a lot of the traffic on this list lately has been arguments about stopping spam. This working group is not chartered to stop spam. -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 12:17: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 MAA16414 for ; Wed, 11 Aug 2004 12:17: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 i7BG7Ud6058447; Wed, 11 Aug 2004 09:07: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 i7BG7U4v058446; Wed, 11 Aug 2004 09:07: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 i7BG7UHX058440 for ; Wed, 11 Aug 2004 09:07:30 -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, 11 Aug 2004 12:07:33 -0400 id 0019769A.411A4445.0000015F Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "ietf mxcomp \"(e-mail)" From: Andrew Newton Subject: What Meng said Date: Wed, 11 Aug 2004 12:07:32 -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 In rereading the Jabber logs and reading the recent threads on SUBMITTER, I'd like to point everyone to a simple sentence Meng wrote in the Jabber session: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html > [11:05:42] if submitter is not present, we fall back to > mail-from. people are missing this. In defense of "people", I reread marid-submitter and marid-core this morning and could not find the place where this was stated. However, this statement is significant. I'm not saying it is a good or bad idea, but it profoundly changes how SUBMITTER is used, the nexus of SUBMITTER and PRA, and even the semantics of the RR version identifier. -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 12:48: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 MAA18217 for ; Wed, 11 Aug 2004 12: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 i7BGRYmc060599; Wed, 11 Aug 2004 09: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 i7BGRXkV060591; Wed, 11 Aug 2004 09:27:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7BGRVdi060561 for ; Wed, 11 Aug 2004 09:27:32 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id F25F51A6C3; Wed, 11 Aug 2004 18:27:33 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id CCBF71A6B1; Wed, 11 Aug 2004 18:27:29 +0200 (CEST) Message-Id: <2STYG8VcPEKXSEByYiFrEA.md5@prosecco.oryx.com> Date: Wed, 11 Aug 2004 18:27:46 +0200 From: Arnt Gulbrandsen To: Andrew Newton Subject: Re: record size and wild cards, was change of version string Cc: Rand Wacker , David Blacka , ietf-mxcomp@imc.org References: <20040810231838.21729.qmail@xuxa.iecc.com> <200408102008.57168.davidb@verisignlabs.com> <82C068E3-EB9F-11D8-97B2-000A95B3BA44@hxr.us> In-Reply-To: <82C068E3-EB9F-11D8-97B2-000A95B3BA44@hxr.us> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > On Aug 11, 2004, at 12:19 AM, David Blacka wrote: > >> I am still trying to imagine *how* this bug could have been written, >> but I suppose that is really just a lack of imagination on my part. > > Me too, as in I'm trying to imagine which API they used and why? The berkeley APIs permit this bug easily. This is very off-charter, but if the chair asks I suppose it's okay ;) Suppose you're reading a packet-based format. Usually the packets are something like (type, length, content). (DNS Is slightly different, but that doesn't matter right now.) The protocol parser is supposed to first read the type and length, and then 'length' bytes of content. With the berkeley API, that involves two read() calls. Or maybe just one, if you optimize a little. So, first you call select() or poll() to be told about the arrival of the data, then read() twice to read them. If the read() that reads the content returns a short read (that is, the program asks for 'length' bytes, the OS returns something less, such as 1500), then the program _should_ not parse yet, but instead call select()/poll() and read() again. The bug happens when the developers never see a short read and forget to handle that case. Short reads don't happen very often often on the 100Mbps LANs used by most developers. (I've seen this bug in three products in the past ten years.) Arnt From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 12:48: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 MAA18235 for ; Wed, 11 Aug 2004 12:48: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 i7BGaE52062594; Wed, 11 Aug 2004 09:36: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 i7BGaEef062593; Wed, 11 Aug 2004 09:36:14 -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 i7BGaE7h062587 for ; Wed, 11 Aug 2004 09:36:14 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:37159) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1Buw5F-0001XV-49 (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 11 Aug 2004 17:36:13 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Buw5C-0007k5-Mo; Wed, 11 Aug 2004 17:36:10 +0100 Date: Wed, 11 Aug 2004 17:36:10 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Andrew Newton cc: "ietf mxcomp \"(e-mail)" Subject: Re: What Meng said In-Reply-To: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> Message-ID: References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 11 Aug 2004, Andrew Newton wrote: > > In rereading the Jabber logs and reading the recent threads on SUBMITTER, I'd > like to point everyone to a simple sentence Meng wrote in the Jabber session: > http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html > > > [11:05:42] if submitter is not present, we fall back to > > mail-from. people are missing this. > > In defense of "people", I reread marid-submitter and marid-core this morning > and could not find the place where this was stated. However, this statement > is significant. I'm not saying it is a good or bad idea, but it profoundly > changes how SUBMITTER is used, the nexus of SUBMITTER and PRA, and even the > semantics of the RR version identifier. The reason Sender-ID falls back to checking MAIL FROM is because SUBMITTER may be omitted if it is the same as MAIL FROM. If a Sender-ID implementation is checking the MAIL FROM in the absence of SUBMITTER, should it use the v=spf1 record or the v=marid1 record? Sites must be able to write a sender-ID record that is aware of which identity is being checked (header sender or bounce address) since these have different semantics and distinct sets of addresses may be valid in each context, e.g. if the site uses BATV. This might be acheived through different record version numbers, or by extending the macro language. 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 Wed Aug 11 12:49:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18294 for ; Wed, 11 Aug 2004 12:49: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 i7BGYF24061786; Wed, 11 Aug 2004 09:34: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 i7BGYFxU061784; Wed, 11 Aug 2004 09:34: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 i7BGYDVB061754 for ; Wed, 11 Aug 2004 09:34:13 -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 i7BGYGj23239; Wed, 11 Aug 2004 09:34:16 -0700 Date: Wed, 11 Aug 2004 09:34:08 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1535446182.20040811093408@brandenburg.com> To: Andrew Newton CC: "ietf mxcomp \"(e-mail)" Subject: Re: What Meng said In-Reply-To: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> References: <8D4A745B-EBB0-11D8-97B2-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> In defense of "people", I reread marid-submitter and marid-core this AN> morning and could not find the place where this was stated. However, AN> this statement is significant. I'm not saying it is a good or bad AN> idea, but it profoundly changes how SUBMITTER is used, the nexus of AN> SUBMITTER and PRA, and even the semantics of the RR version identifier. indeed. submitter has been offered as an efficiency hack on the rfc2822-based checking of sender-id. there has been no rfc2821.mailfrom in it. so meng's statement would seem to change the basic semantics of sender-id, depending upon whether submitter is present. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 13:04:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19246 for ; Wed, 11 Aug 2004 13:04: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 i7BGhVLl063156; Wed, 11 Aug 2004 09:43: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 i7BGhUki063155; Wed, 11 Aug 2004 09:43:30 -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 i7BGhUOv063143 for ; Wed, 11 Aug 2004 09:43:30 -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 i7BGhUns000631 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 Aug 2004 09:43:30 -0700 Date: Wed, 11 Aug 2004 09:43:30 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Andrew Newton cc: "ietf mxcomp \"(e-mail)" Subject: Re: What Meng said In-Reply-To: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> Message-ID: References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 11 Aug 2004, Andrew Newton wrote: > > [11:05:42] if submitter is not present, we fall back to > > mail-from. people are missing this. > > In defense of "people", I reread marid-submitter and marid-core this > morning and could not find the place where this was stated. However, > this statement is significant. I'm not saying it is a good or bad > idea, but it profoundly changes how SUBMITTER is used, the nexus of > SUBMITTER and PRA, and even the semantics of the RR version identifier. I'm of the same opinion as Andy upon re-reading the documents, if submitter is not present then you *have* to grovel through the headers (this is necessary to support Sender ID filters plugged in to or behind MTAs that may not yet support SUBMITTER). There is a minor optimization noted that in the future, if SUBMITTER would exactly match MAIL FROM, then SUBMITTER could be omitted. I thought this paragraph had the possibility for confusion written all over it, but others wanted to leave it in. So maybe "people" are reading the specs differently than Meng? ;) -Rand From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 13:11: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 NAA19635 for ; Wed, 11 Aug 2004 13:11: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 i7BGvW39064384; Wed, 11 Aug 2004 09:57: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 i7BGvWdN064383; Wed, 11 Aug 2004 09:57:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGvVZU064377 for ; Wed, 11 Aug 2004 09:57:32 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LDIB9Q1F3K00005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Wed, 11 Aug 2004 09:57:34 -0700 (PDT) Date: Wed, 11 Aug 2004 09:53:17 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: What Meng said In-reply-to: "Your message dated Wed, 11 Aug 2004 09:34:08 -0700" <1535446182.20040811093408@brandenburg.com> To: Dave Crocker Cc: Andrew Newton , ietf mxcomp e-mail Message-id: <01LDJ8IIVQO000005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <1535446182.20040811093408@brandenburg.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > AN> In defense of "people", I reread marid-submitter and marid-core this > AN> morning and could not find the place where this was stated. However, > AN> this statement is significant. I'm not saying it is a good or bad > AN> idea, but it profoundly changes how SUBMITTER is used, the nexus of > AN> SUBMITTER and PRA, and even the semantics of the RR version identifier. > indeed. > submitter has been offered as an efficiency hack on the rfc2822-based > checking of sender-id. there has been no rfc2821.mailfrom in it. That has been my reading as well. Indeed, the text of the submitter document is quite clear that the identity involved is the PRA identity. It would also be rather strange for the SUBMITTER SMTP extension to change the semantics of SMTP when the extension _isn't_ used. > so meng's statement would seem to change the basic semantics of > sender-id, depending upon whether submitter is present. The rationale document is also pretty clear that RFC 2821 MAIL FROM isn't used, and why. Ned From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 13:15: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 NAA19846 for ; Wed, 11 Aug 2004 13: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 i7BGnUSA063716; Wed, 11 Aug 2004 09:49:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGnUnb063715; Wed, 11 Aug 2004 09:49:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGnTqp063709 for ; Wed, 11 Aug 2004 09:49:30 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 09:49:32 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 09:49:32 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 09:49:32 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 09:47:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7379.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: What Meng said Date: Wed, 11 Aug 2004 09:49:30 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF80C564@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: What Meng said Thread-Index: AcR/vmijYvqD94WCQIeybX1jVhlF4AAA/Pag From: "Jim Lyon" To: "Andrew Newton" , "ietf mxcomp \"\(e-mail\)" X-OriginalArrivalTime: 11 Aug 2004 16:47:49.0034 (UTC) FILETIME=[EF6A98A0:01C47FC2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BGnUqp063710 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Andy said, quoting Meng: > [11:05:42] if submitter is not present, we fall back to > mail-from. people are missing this. From both my reading of the docs, and what I believe was the intent of the docs, this is wrong. If submitter is missing, one needs to get the PRA from the data of the message. (Of course, with submitter one must still verify that submitter == PRA and reject the message otherwise.) I think that Meng may be referring to the text that states that at some date in the future (which hasn't been specified yet), one may treat the absence of submitter as submitter == mail-from. However, this can only occur after very wide-spread adoption of submitter-aware MTAs, and after another standards action. -- jimbo Internet commerce will never really take off until you can buy something online without getting spammed by the vendor. -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Andrew Newton Sent: Wednesday, August 11, 2004 9:08 AM To: ietf mxcomp "(e-mail) Subject: What Meng said In rereading the Jabber logs and reading the recent threads on SUBMITTER, I'd like to point everyone to a simple sentence Meng wrote in the Jabber session: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html In defense of "people", I reread marid-submitter and marid-core this morning and could not find the place where this was stated. However, this statement is significant. I'm not saying it is a good or bad idea, but it profoundly changes how SUBMITTER is used, the nexus of SUBMITTER and PRA, and even the semantics of the RR version identifier. -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 13:18: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 NAA20162 for ; Wed, 11 Aug 2004 13:18: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 i7BH2iTC064742; Wed, 11 Aug 2004 10:02:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BH2iQx064741; Wed, 11 Aug 2004 10:02:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BH2i3f064728 for ; Wed, 11 Aug 2004 10:02:44 -0700 (PDT) (envelope-from george@m5p.com) Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by mailhost.m5p.com (8.12.11/8.12.11) with ESMTP id i7BH2eZJ027988 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Aug 2004 10:02:41 -0700 (PDT) Received: (from defang@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7BH1a6N027983 for ; Wed, 11 Aug 2004 10:01:36 -0700 (PDT) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (MIMEDefang) with ESMTP id i7BH1aVc027982; Wed, 11 Aug 2004 10:01:36 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7BH1Z2w044355; Wed, 11 Aug 2004 10:01:35 -0700 (PDT) Date: Wed, 11 Aug 2004 10:01:35 -0700 (PDT) From: George Mitchell Message-Id: <200408111701.i7BH1Z2w044355@m5p.com> To: hardie@qualcomm.com, ietf-mxcomp@imc.org, mengwong@dumbo.pobox.com Subject: Re: change of version string In-Reply-To: X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At Tue, 10 Aug 2004 10:40:19 -0700, Ted Hardie wrote: > > At 7:14 PM -0400 8/9/04, Meng Weng Wong wrote: > > > >While such a change is, from the standpoint of architectural > >purity, absolutely the correct thing to do, I fear that in > >practice it may lead to confusion, needless duplication of > >records, and a failure to achieve the intended objective. > >In other words, it is my opinion that engineering > >considerations do not weigh in favour of changing the string. > > > >I particularly do not want to see a world where the norm is: > > > > example.com TXT "v=spf1 a mx ptr" > > example.com TXT "v=spf2 a mx ptr" > > > >Both records would contain the same content, yet senders > >might feel the need to publish both "just to be on the safe side". > > Both records do _not_ contain the same information. The first > record has a target of MAIL_FROM; the second has a target > of PRA. The fact that the strings "a mx ptr" happen to be > the same in both records does not change that fundamental > fact. [...] Surely this is a distinction without a difference. If you ask me, "What checks do you want me to make on email which arrives with MAIL FROM: george@m5p.com?", and then you ask me "What checks do you want me to make on email which arrives with a PRA of george@m5p.com?", would you be surprised if I answered "... a mx -all" in both cases? Perhaps there are cases in which people want the checks to be different, but this will be the exception (and I think a rare one) rather than the rule. I strongly agree with Meng that the problems associated with changing the version string outweigh the possible theoretical advantage. -- George Mitchell From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 13: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 NAA20317 for ; Wed, 11 Aug 2004 13: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 i7BH3cHe064811; Wed, 11 Aug 2004 10:03: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 i7BH3cDD064810; Wed, 11 Aug 2004 10:03:38 -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 i7BH3cuQ064804 for ; Wed, 11 Aug 2004 10:03:38 -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 E9B524149B; Wed, 11 Aug 2004 10:03:41 -0700 (PDT) Subject: RE: Does marid-submitter-02 really make sense? From: Douglas Otis To: Mark Shewmaker Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092204280.19686.954.camel@localhost.localdomain> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1092243820.5943.180.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 10:03: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 Tue, 2004-08-10 at 23:04, Mark Shewmaker wrote: > On Tue, 2004-08-10 at 14:34, Douglas Otis wrote: > > On Tue, 2004-08-10 at 05:42, Mark Shewmaker wrote: > > > On Tue, 2004-08-10 at 06:02, Shevek wrote: > > > > > > 3. Any other not-directly-SenderID test based on SUBMITTER could > > > be substituted in (1) or (2) above, such as domain-based reputation > > > tests. > > > > > > (Or full-email-address (!!!) based reputation tests.) > > > > The Mailbox Domain identified by Submitter can not be used for > > reputation checks! > > Sure you can--you can see if you have white-listed that PRA yourself, or > if your trusted friends have--thus giving you reason to believe claims > made by this PRA, A public list assessing these identities used to block mail would be doomed. Abuse *beyond* the domain holder's control would elicit a legal challenge to any assertion of their reputation that stops their mail. There would be no other recourse. There may be hundreds of such domains sharing a transparent MTA imposed by their ISP. This convergence may not be apparent to the recipient, but would allow any of these hundreds of domains to assert any of these Mailbox Domains. Also, how would you rate Mailbox Domains that resolve to being valid, but are outside their prescribed Mail Channel? And of course, the Mail Channel is not secure, so any conclusions based upon this indirect assertion of content *must* be dismissed. This would be trusting a third-party MTA without an opportunity to examine the related integrity of the Mail Channel. > Or you could filter out PRAs with bad reputations--those appearing on > domain-based block lists. A provider of these services would need to obtain a contract that stipulates PRA identities will NOT be used in conjunction with their listing services. > This isn't as useful as a sender_agents based end-to-end trust chain, > but then again, I did put this "optimization" under the "boring, minor" > heading. I would put it under wishful. > > Neither Sender-ID nor Submitter stop bounces as there are no checks > > against the MAIL FROM. As mail, at many nodes, operates using a store > > and forward mechanism, there will always be ample opportunity to create > > a bounce. This example is applying a per recipient white-list at the > > initial MTA receiver. This assumes all MTAs have been provided these > > per-recipient white-lists. This assumption is flawed as there will be > > configurations where this does not apply and spammers are expert at > > finding them. > > The problem comes with configurations with per-recipient controls. > > That's the case I'm worried about. > > If you're doing per-recipient white-lists, and you don't have SUBMITTER > but you want to do SenderID PRA checks anyway, you have to check after > DATA. > > But since you can't reject per-recipient after data, you have to bounce > after data instead. > > But you can't safely bounce after data unless you've had an classic SPF > PASS result. > > And that's a opportunity for spammers to have you send out forged > bounces, if you've put yourself into a position to have to send out > potentially forged bounces or throw away accepted mail. If using a per recipient white-list, if accepting multiple recipients in one mode but not the other, if subsequent recipients fail to white-list this sender, if this has not been internally forwarded, then there will be a bounce. As one of your users have vouched for this sender, a bounce should not be a problem, as this is not a bad actor. Merging all recipient white-lists would allow logical treatment without Submitter and would avoid the onerous single recipient mode. > > > So, here SUBMITTER is a *serious* optimization! > > > > This is ignoring the likely outcome of this mechanism and the defensive > > strategy likely to result. > > I meant it a bit tongue-in-cheek. > > If you do get SUBMITTER, then you don't have to worry about being used > to generate bounce spam, since you can do per-recipient rejects. > (Obviously, there's a problem if another machine of yours has just > relayed the message to you--so your rejecting the message would cause it > to bounce the message--but that's a separate vulnerability in your > setup.) Merge your white-lists. If any use vouch for the sender, then they are not likely a spammer. This avoids the one recipient mode. Hence, "optimization" without Submitter. > And so you don't have to do all this extra work to counter possible > bounce forgery attempts directed at you. Hence, "optimization." > > > > 2. Run SPF Classic tests on MAIL FROM, and *bounce* messages failing > > > SenderID tests. > > > > I assume you mean Reject messages failing Sender-ID checks. > > No, I actually mean "bounce." > > If you are sent a message without SUBMITTER, you have to do SenderID > tests after data. > > But if one recipient's policies has you accepting that message and the > other has you not accepting it--after DATA you can't reject per-user, so > you have to bounce instead. You did not qualify this. But again, I think this can be easily avoided by consolidating white-lists in a first pass check. > But you're stuck if you can't safely bounce if you don't have a full SPF > PASS. That may flag a problem with one of your users white-lists. > > > Either way, your bandwidth is sucked away like crazy. > > > > This ignores the required 10 host_checks() functions calls. Assume each > > TXT record references 8 MX records which then requires 5 A record > > lookups, as in the example by John Levine. That would be 400 DNS > > lookups resulting in about 1.3 queries per lookup (520) to arrive at the > > 400 answers. If each query resulted in a normal mean of about 100 ms, > > that would be 52 seconds, well within the 200 seconds alloted by the > > draft. If at about 400 bytes per record (counting both directions), the > > resulting traffic could be over 200 kbytes of UDP traffic, for about 8 > > kbytes of an average message. > > But at worst all these queries should be locally cached by the time you > get to the first RCPT TO: value. After 52 seconds? Roughly 5% of these will likely be lost and I stated that 80% were cache hits (assuming normal mail). That could mean out of the 104 queries, about 5 will time-out. So 52 seconds goes to 77 seconds with nothing unusual or out of the ordinary. Of course, if this were a spammer, then don't except a high cache hit rate as they tend to use random sub-domains with wildcard records. Sorry, but this information in either case is not cached so quickly. > So if your test code doesn't cache data itself, you're just querying dns > records cached on your own machine, or on a machine very close to you. At some point, these queries will become present on the WAN. DNS caching is not 100%. There are things like TTL and I would expect overflow conditions being dealt with due to the abhorrently high traffic generated by the Sender-ID bloat. Should the records indicate ?all, and using an access point outside of the prescribed Mail Channel, then each an every record must be checked. : ( > And two of the spf test libraries actually do caching internal to the > libraries. > > I'm not very worried about DNS bandwidth. Obviously. > > It seems refusing to accept multiple recipients, as you indicated, on a > > normal basis would arrive at the same result. This would work with or > > without Submitter, when applying per recipient white-lists at the MTA. > > This could be seen as a means to avoid bounces at all costs, to bolster > > Sender-ID that does not check MAIL FROM. > > Yeah. I'm wondering if, were any RFC to come out for an smtp extension > allowing per-recipient after-data rejects, if it would soon become > acceptable to give "too many recipient" errors on second and subsequent > recipients when the sending MTA (!) doesn't support such an extension. Would the sender enumerate each recipient in some fashion to then allow selective rejections? > > > If you're given SUBMITTER, you can do per-recipient rejects safely, of > > > course. But folks who want to trick you into sending their bounce spam > > > won't be all nice and give you a cool SUBMITTER to play with--and > > > without SUBMITTER you have this yucky issue. > > > > It seems you have concluded Submitter is not an optimization after all. > > This problem of multiple recipients is only when they share the same > > receiving MX server as well. > > It is a meager optimization for the single-recipient case, but in the > multiple-recipient case, it's an "optimization" in that it allows you to > avoid wasting bandwidth that's necessary to waste if you want to avoid > the security issues inherent in doing per-recipient after-data checks. This assumes a list of other conditions that go with this rather limited case. Again, merge the white-lists to create a general case. This should lessen much of your concerns. > > > (Side note: If you do get SUBMITTER and SUBMITTER!=PRA, then it's safe > > > to reject after DATA for *all* recipients, because this is clearly > > > either a corrupt or forged mail transmission.) > > > > That assumes there is a check made at this point. This is the great > > downside when allowing Submitter. This check becomes optional and the > > modicum of security goes out the window. > > Without sender_agents, which has end-to-end tests, I don't see why it's > so bad if some implementations skip the required SUBMITTER==PRA test, > because if you got a message with SUBMITTER!=PRA where the SUBMITTER > value would have caused you to accept it if it were equal to the PRA, > then the sending machine could have just added a "Resent-From:" at the > top of the body headers to have had it pass that SUBMITTER==PRA check. > > I don't see how the fact that it didn't bother to fill in some paperwork > mean that there's a security check. > > (Now, if Resent-From: included some cryptographic checksum of the rest > of the message, that would be a different story--but it doesn't.) The problem you seem to overlook is that the MUA does not see Submitter. If this goes unchecked, then what is the user seeing and has Submitter helped? In this case, Submitter defeats the intended value and only adds complexity. As submitter is not seen in the message, it would also create problems trying to resolve different PRA resolutions. This seems to be an expensive feature with respect to support centers and it lowers security. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 13:53:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22387 for ; Wed, 11 Aug 2004 13: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 i7BHaFYV068708; Wed, 11 Aug 2004 10:36:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BHaF5S068707; Wed, 11 Aug 2004 10:36:15 -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 i7BHaEic068700 for ; Wed, 11 Aug 2004 10:36:15 -0700 (PDT) (envelope-from sb0-0641cb1178-johnl@iecc.com) Received: (qmail 2582 invoked by uid 100); 11 Aug 2004 17:36:17 -0000 Date: 11 Aug 2004 17:36:17 -0000 Message-ID: <20040811173617.2581.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: missing submitter, was What Meng said In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: rand@sendmail.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >There is a minor optimization noted that in the future, if SUBMITTER would >exactly match MAIL FROM, then SUBMITTER could be omitted. I thought this >paragraph had the possibility for confusion written all over it, but >others wanted to leave it in. I don't understand how an SMTP server is supposed to tell the difference between a MAIL FROM that doesn't have SUBMITTER because it's the same as the bounce address and a MAIL FROM that doesn't have SUBMITTER because it doesn't implement SUBMITTER. The EHLO response lets the server tell the client what extensions it offers, but there's no way for the client to tell the server what extensions it uses other than by using them. I've never thought that SUBMITTER was useful, but this makes it both useless and meaningless. If it's going to be defined, at least define it so it means something. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 14:04:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23025 for ; Wed, 11 Aug 2004 14:04:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHkKeo069636; Wed, 11 Aug 2004 10:46: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 i7BHkKeM069635; Wed, 11 Aug 2004 10:46:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHkJHt069628 for ; Wed, 11 Aug 2004 10:46:19 -0700 (PDT) (envelope-from mike@mtcc.com) Received: (from mike@localhost) by mtcc.com (8.12.10/8.12.10) id i7BHkMoW013860; Wed, 11 Aug 2004 10:46:22 -0700 To: Andrew Newton Cc: "ietf mxcomp \"(e-mail)" Subject: Re: Does marid-submitter-02 really make sense? References: <44AA2DCF-EBAF-11D8-97B2-000A95B3BA44@hxr.us> X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! From: Michael Thomas Date: 11 Aug 2004 10:46:22 -0700 In-Reply-To: <44AA2DCF-EBAF-11D8-97B2-000A95B3BA44@hxr.us> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > On Aug 11, 2004, at 11:14 AM, Michael Thomas wrote: > > > Thus if the base level check prevents forgery, > > they'll switch to a line of attack that doesn't use > > forgery. > > At that point, our job is done. Then what is the point of putting through an optimization like SUBMITTER? Especially since it seems to not optimize the cases that you'd hope it would optimize? > Not meaning to single out Michael, but a lot of the traffic on this > list lately has been arguments about stopping spam. This working > group is not chartered to stop spam. _I_ haven't said anything about stopping spam. But surely it's not off limits to talk about how the people who use forgery as an attack vector will react in the face better forgery protection. -- Michael Thomas (mike@mtcc.com http://www.mtcc.com/~mike/) Fell to the Fog/Oak to Oakland Pine to the Pacific/Bush in the Bay From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 14:30: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 OAA24569 for ; Wed, 11 Aug 2004 14:30: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 i7BIC3xZ072312; Wed, 11 Aug 2004 11:12:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BIC3eo072311; Wed, 11 Aug 2004 11:12:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIC3eg072305 for ; Wed, 11 Aug 2004 11:12:03 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 11:12:06 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 11:12:03 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 11:12:06 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 11:11:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7379.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: missing submitter, was What Meng said Date: Wed, 11 Aug 2004 11:12:04 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF80C5D3@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: missing submitter, was What Meng said Thread-Index: AcR/yzzQTOLbvTCmQwSIfeaEZMfQoAAAihEw From: "Jim Lyon" To: "John Levine" , Cc: X-OriginalArrivalTime: 11 Aug 2004 18:11:44.0858 (UTC) FILETIME=[A9005BA0:01C47FCE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BIC3eg072306 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit John Levine said: > I don't understand how an SMTP server is supposed to tell the > difference between a MAIL FROM that doesn't have SUBMITTER > because it's the same as the bounce address and a MAIL FROM > that doesn't have SUBMITTER because it doesn't implement > SUBMITTER. Today, an SMTP server who receives a MAIL command without SUBMITTER must get the PRA in order to perform Sender ID checks. The documents contemplate a future standards action that says that: 1. An SMTP client MUST use SUBMITTER whenever it differs from MAIL-FROM. 2. After some date, an SMTP server MAY assume that SUBMITTER == MAIL-FROM whenever SUBMITTER is omitted. Clearly, step 2 will not fly until step 1 has been widely deployed. Regardless of the hypothetical future, the documents for today state that: 1. An SMTP client MAY use SUBMITTER. 2. If an SMTP client does use SUBMITTER, the value MUST equal the PRA from the message headers. 3. If an SMTP server receives SUBMITTER, it MUST reject the message is SUBMITTER != PRA from headers. 4. If an SMTP server receives SUBMITTER, it MAY use that value to perform Sender ID checks at MAIL command time. There were some in the room at the WG meeting who thought that elevating the PRA to the 2821 protocol would be useful for reasons unrelated to MARID -- I believe Pete Resnick was the prime proponent of this position. -- jimbo Internet commerce will never really take off until you can buy something online without getting spammed by the vendor. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 14:53:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27022 for ; Wed, 11 Aug 2004 14:53:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIYQLm074565; Wed, 11 Aug 2004 11:34: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 i7BIYQME074564; Wed, 11 Aug 2004 11:34:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIYQEc074557 for ; Wed, 11 Aug 2004 11:34:26 -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 589E4414C2; Wed, 11 Aug 2004 11:34:27 -0700 (PDT) Subject: Re: change of version string From: Douglas Otis To: George Mitchell Cc: hardie@qualcomm.com, MARID , mengwong@dumbo.pobox.com In-Reply-To: <200408111701.i7BH1Z2w044355@m5p.com> References: <200408111701.i7BH1Z2w044355@m5p.com> Content-Type: text/plain Message-Id: <1092249266.6453.49.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 11:34:26 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-11 at 10:01, George Mitchell wrote: > At Tue, 10 Aug 2004 10:40:19 -0700, Ted Hardie wrote: > > At 7:14 PM -0400 8/9/04, Meng Weng Wong wrote: > > > > > > While such a change is, from the standpoint of architectural > > > purity, absolutely the correct thing to do, I fear that in > > > practice it may lead to confusion, needless duplication of > > > records, and a failure to achieve the intended objective. > > > In other words, it is my opinion that engineering > > > considerations do not weigh in favour of changing the string. > > > > > > I particularly do not want to see a world where the norm is: > > > > > > example.com TXT "v=spf1 a mx ptr" > > > example.com TXT "v=spf2 a mx ptr" > > > > > > Both records would contain the same content, yet senders > > > might feel the need to publish both "just to be on the safe side". > > > > Both records do _not_ contain the same information. The first > > record has a target of MAIL_FROM; the second has a target > > of PRA. The fact that the strings "a mx ptr" happen to be > > the same in both records does not change that fundamental > > fact. [...] > > Surely this is a distinction without a difference. If you ask me, > "What checks do you want me to make on email which arrives with > MAIL FROM: george@m5p.com?", and then you ask me "What checks do > you want me to make on email which arrives with a PRA of > george@m5p.com?", would you be surprised if I answered > "... a mx -all" in both cases? Perhaps there are cases in which > people want the checks to be different, but this will be the > exception (and I think a rare one) rather than the rule. I > strongly agree with Meng that the problems associated with > changing the version string outweigh the possible theoretical > advantage. The difference and advantage of one scheme over the other is not theoretical. SPF allows the RFC 2822 From to differ from the RFC 2821 MAIL FROM. This allowance enables provider customers to continue using recognized return addresses seen within their messages. SPF also checks the MAIL FROM validity to help prevent a spoof bounce technique often used by spammers to dodge repudiation checks. Sender-ID places an onerous restriction on the mail sender with respect to the use of their well-known mailbox address and Sender-ID does not prevent the spoof bounce technique. Nor does Sender-ID conserve network bandwidth with rejected mail, as does SPF. It would be irresponsible to conclude acceptance of this restriction by those that have published SPF records. I suspect the principle motivation to publish SPF records was to find relief from the spoof bounce techniques. There have already been some on this list indicating a series of checks be made, one for SPF (to enable the bounce protections) and then Sender-ID to impose limits upon the RFC 2822 From address. The logical outcome will be inclusion of a Resent-From header by ISPs when forced into using Sender-ID as a means to negate this expensive restriction. A CSV check of the HELO/EHLO domain would provide a mail identifier enhancement that can be used with an accreditation service and assist enforcement policies. Sender-ID can not be safely used with accreditation checks nor does it identify how mail was introduced. If there are already wildcard SPF records, and then adding wildcard Sender-ID records will collide and may cause a response problem. Wildcard records granting "open" lists would likely be used as a spammer exploit adding random sub-domains forcing a huge load on the DNS server. I recall other issues raised in opposition to the use of wildcards. It seems highly inappropriate for Microsoft to demand a signed contract, and to usurp the function and meaning of SPF records. This all seems to come under the topic why TXT records should not be overloaded. To be fair, this was a warning ignored by the WG at the interim meeting. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 15:09: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 PAA28937 for ; Wed, 11 Aug 2004 15:09: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 i7BItBaT077006; Wed, 11 Aug 2004 11:55:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BItBLn077005; Wed, 11 Aug 2004 11:55:11 -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 i7BItAn6076994 for ; Wed, 11 Aug 2004 11:55: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 CD2AD132DA0; Wed, 11 Aug 2004 14:58:42 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 650F16FF; Wed, 11 Aug 2004 14:55:08 -0400 (EDT) Date: Wed, 11 Aug 2004 14:55:08 -0400 From: Meng Weng Wong To: Andrew Newton Cc: "ietf mxcomp (e-mail)" Subject: Re: What Meng said Message-ID: <20040811185508.GH28401@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 11, 2004 at 12:07:32PM -0400, Andrew Newton wrote: | | In rereading the Jabber logs and reading the recent threads on | SUBMITTER, I'd like to point everyone to a simple sentence Meng wrote | in the Jabber session: | http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html | | > [11:05:42] if submitter is not present, we fall back to | >mail-from. people are missing this. | | In defense of "people", I reread marid-submitter and marid-core this | morning and could not find the place where this was stated. However, | this statement is significant. I'm not saying it is a good or bad | idea, but it profoundly changes how SUBMITTER is used, the nexus of | SUBMITTER and PRA, and even the semantics of the RR version identifier. | I should explain the thinking behind that statement. It is not my intention to open a can of worms, but since I'm likely to get yelled at either way I might as well err on the side of openness. Sender ID is complicated by the fact that it has "before" and "after" aspects. In May, in my meeting with Microsoft when Submitter was first proposed, we tossed around a few ideas for how it could be used. The vision we arrived at (and Harry, Jim, please correct me) looks something like this: The core identity in Sender ID is the PRA. To make the PRA available without the bandwidth and processing burden of DATA, Submitter is used to provide a sneak preview of the PRA at MAIL time. Since the goal is a preview, if Mail-From and Submitter are identical, there is strictly speaking no need to display Submitter. In the early days of Sender ID, you have to check the PRA, because you can't assume the typical sender is Submitter aware. This is the "before" aspect. But after Submitter has become more widely supported, a receiver may be able to assume that Submitter was omitted because the PRA and the Mail-From match. This is the "after" aspect, the long-term endgame scenario. I would like to get there sooner rather than later. The language in 4.1 alludes to this assumption. 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 MUST 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. This includes messages where the MAIL FROM address is empty or "<>". SMTP clients SHOULD include the SUBMITTER parameter on messages where the purported responsible address is the same as the MAIL FROM address. I take this to mean that an SMTP client that supports the Responsible Submitter extension MAY omit the parameter on messages where the Mail From is the same as the PRA. And an SMTP receiver that supports the Responsible Submitter extension MAY assume that the Mail From is a good predictor of the PRA. I think that this line of thinking is useful. If, however, we don't want to make the assumption that a missing Submitter means we use the Mail-From, we would require a Submitter aware sender to always pass Submitter, even when PRA == Mail-From. Then the language could be changed to read: SMTP clients that support the Responsible Submitter extension MUST always include a SUBMITTER parameter on all messages. This includes messages where the MAIL FROM address is empty or "<>". This may also be useful, but we should consider the tradeoffs. First, this would remove a receiver's ability to assume that Mail-From == PRA when Submitter is absent. Second, this would also require PRA checks on all mail where Submitter is not provided, and therefore make it impossible to detect and reject envelope spoofs before DATA. I believe that such a change would have serious implications for the acceptance of the proposed standard in the marketplace. I will go into more detail below, but first, I want to take a look at Submitter. I like the idea of Submitter. Because it is a new construct, we can load it up with powerful semantics right out of the gate. I believe it was Bob Atkinson who pointed out that if a sender was aware of Submitter, that sender should also be aware of Sender ID. This meant that anytime a receiver sees a Submitter, the SPF check on Submitter should return a PASS result. Obviously if it returns a FAIL result you reject. But if the spf/Submitter test returns an UNKNOWN, you can also reject! Why? Because no legitimate, Submitter-aware MTA should ever send a Submitter field that doesn't result in a PASS. If the purported responsible address doesn't resolve in a PASS, why bother If we can say that for Submitter, UNKNOWN isn't good enough, then we have a stronger level of assurance than the spf/Mail-From test, and we make it harder for spammers to spoof domains in SUBMITTER. This statement of applicability may not be in the specification; if it is not too late, perhaps it could be added. I would be happy if that happened. If it did not happen, I expect spammers would forge non-SPF-publishing domains in the SUBMITTER field. We're getting close to last call. Now that code has been written, conformant products are shipping, specifications have been drafted, and the design has been documented, perhaps it's time to talk about requirements. The anti-false-positive community wants to easily whitelist known good senders without hurting deliverability. This includes the ESP industry and receiving ISPs. Because this is the most modest requirement, spf/Mail-From, spf/Submitter, spf/PRA, CSV, and DK are all good enough for this community. They just want us to pick one and get on with it. Apparently S/MIME is not good enough because people using mail clients from 1995 are an important demographic who must not be confused by new technology. The anti-phishing community wants to make it possible for MUAs to validate what the end-users see, to easily detect obvious forgeries, to easily detect obvious good mail, and allow room for accreditation. If we could construct an email analogue of the https padlock icon, that would be a step in the right direction. Any one of DK, SMG, PGP, or Sender ID can provide that padlock, at varying levels of assurance. Sender ID tries to help by offering the designated sender approach. I expect the MASS WG to complement our work with good cryptographic solutions. But technical solutions can never perfectly solve the phishing problem. The genie is out of the bottle: we can't keep arbitrary graphical content from being displayed to end-users. What we can do is flip toward an AGUPI paradigm. Once enough reputable senders authenticate themselves, we can relegate all unauthenticated or unreputable senders to a second class folder, and create new user expectations for the differences between first class and second class folder. Getting out of that folder should be easy for good guys and hard for bad guys. We can do this using accreditation and reputation. The SPF Classic community wants some level of protection from blowback; the ability to reject before DATA; and a strong proposal which can be quickly rolled out at the MTA level independent of the MUA. While we appreciate that BATV/SES are the final word in blowback prevention, because many spams are overwhelmingly directed at large ISPs, if we can get those large ISPs to reject at SMTP time instead of generating bounces or silently swallowing suspected spam, then we already have a significant benefit. Sender ID is a compromise between SPF Classic and Caller ID. The opensource community has been very vocal in its defense of its requirements. So has the anti-phishing community. My goal in exploring the affordances of Submitter is to build a bridge between the two sets of requirements, which are, to some degree, in conflict. I would like to offer the opensource and SPF Classic communities a strong argument that their objectives will be met by Sender ID. I fear that if we do not, Sender ID will lose their support. With this in mind, we can come back to the question: In the absence of Submitter, should a receiver assume that the Mail From is a good predictor of the PRA? I would like to live in a world where the answer is yes. Because of the "before/after" issue we may have to wait a while before we can safely make that assumption. This is not the place to discuss how long, but I would like it to be sooner rather than later. (I happen to feel that the spam problem is pretty urgent. The baby is drowning in the bathwater.) I believe that if we choose a world where the answer is no, then the SPF Classic community will continue to pursue Mail-From solutions independent of Sender ID. SPF code has been written and has been packaged into the majority of opensource MTAs. If I cannot offer a compelling argument that their requirements are respected in Sender ID, I may not be able to convince them to move toward SUBMITTER and PRA. Of course, I may not need to do anything; when the RFCs are out, there is a certain expectation that they will be followed. I understand that many participants in this working group have, during the course of the standards process, accumulated a fair amount of frustration. I am not bringing up these issues because to be contrarian. I am not bringing up these issues to further some secret agenda. I believe that Sender ID is very close to being good enough for nearly everyone. I'm just not sure that it's there yet, and I want to help it go the rest of the way. If we leave these issues unaddressed, I fear that an important constituency will simply respond by declining to adopt our standard. I fear that if we are not explicit about exactly what the value proposition is, people who buy into the system expecting a silver bullet will accuse us of false advertising. I fear that if we do not think through the full range of WWSD scenarios and answer each one convincingly, the solution will not last. I am bringing up these issues because I hope that they can be avoided. I recognize that perhaps this input is too late, not appropriate to this forum, or places too high a value on cooperation between different communities. If you feel that this message has not been constructive, I apologize in advance; please understand that I am doing what I think is right. I will not raise these issues again; all you have to do is not reply, and it will go away. On a separate note, I have heard that EzMLM and YahooGroups lists do not pass the PRA test. The new core draft may benefit from an applicability statement that waives the PRA test for recognized mailing lists. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 16:25: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 QAA10044 for ; Wed, 11 Aug 2004 16:25:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BKAL9h084878; Wed, 11 Aug 2004 13:10: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 i7BKALgb084877; Wed, 11 Aug 2004 13:10: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 i7BKAL7B084871 for ; Wed, 11 Aug 2004 13:10: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 i7BKAJj08967; Wed, 11 Aug 2004 13:10:19 -0700 Date: Wed, 11 Aug 2004 13:10:02 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1424261665.20040811131002@brandenburg.com> To: Tony Finch CC: Andrew Newton , "ietf mxcomp \"(e-mail)" Subject: Re: What Meng said In-Reply-To: References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tony, TF> The reason Sender-ID falls back to checking MAIL FROM is because SUBMITTER TF> may be omitted if it is the same as MAIL FROM. If a Sender-ID TF> implementation is checking the MAIL FROM in the absence of SUBMITTER, TF> should it use the v=spf1 record or the v=marid1 record? One of the more interesting errors that we all have made in designing protocols is the pseudo-efficiency hack of using defaults. With unfortunate frequency, I keep seeing this "assumption" about values come back to bite us. From/Sender is merely one example. (Another is "default" character set for MIME, but that's another diatribe.) Might be nice for a new protocol to reflect something from the learning curve, and avoid this mistake. No Submitter field should mean no submitter value in rfc2821 headers, rather than 'look at mailfrom'. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 16:25:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10065 for ; Wed, 11 Aug 2004 16:25: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 i7BKBXxv084973; Wed, 11 Aug 2004 13: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 i7BKBXAV084972; Wed, 11 Aug 2004 13: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 i7BKBXbH084966 for ; Wed, 11 Aug 2004 13:11:33 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7BKBZj09367; Wed, 11 Aug 2004 13:11:35 -0700 Date: Wed, 11 Aug 2004 13:11:25 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1907230478.20040811131125@brandenburg.com> To: "Jim Lyon" CC: "Andrew Newton" , "ietf mxcomp \"(e-mail)" Subject: Re: What Meng said In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF80C564@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF80C564@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> I think that Meng may be referring to the text that states that at some JL> date in the future (which hasn't been specified yet), one may treat the JL> absence of submitter as submitter == mail-from. However, this can only this is a good example of the reason that specifications should not make promises or predictions of the future. that's a social process, not an engineering process. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 16:56: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 QAA15110 for ; Wed, 11 Aug 2004 16:56: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 i7BKbULN086830; Wed, 11 Aug 2004 13:37:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BKbUFY086829; Wed, 11 Aug 2004 13:37:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BKbUb1086822 for ; Wed, 11 Aug 2004 13:37:30 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 13:37:34 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 13:37:34 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 13:37:34 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 13:37:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7379.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: What Meng said Date: Wed, 11 Aug 2004 13:37:33 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF80C660@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: What Meng said Thread-Index: AcR/32qoTQRfQnPsRs+un2H+SRq6OQAAyuyA From: "Jim Lyon" To: "Dave Crocker" Cc: "Andrew Newton" , "ietf mxcomp \"\(e-mail\)" X-OriginalArrivalTime: 11 Aug 2004 20:37:36.0877 (UTC) FILETIME=[099C79D0:01C47FE3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BKbUb1086823 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dave Crocker, in response to my explanation about the SUBMITTER confusion, said: > This is a good example of the reason that specifications should > not make promises or predictions of the future. That's a social > process, not an engineering process. I tend to agree. Should we remove the language about the future from the SUBMITTER spec? -- jimbo Internet commerce will never really take off until you can buy something online without getting spammed by the vendor. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 17:05: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 RAA16918 for ; Wed, 11 Aug 2004 17:05: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 i7BKoUhE087933; Wed, 11 Aug 2004 13:50: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 i7BKoUZ3087932; Wed, 11 Aug 2004 13:50:30 -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 i7BKoTF6087926 for ; Wed, 11 Aug 2004 13:50:29 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040811205027.UHIP14082.tomts16-srv.bellnexxia.net@ibmrkydk2ufvdd>; Wed, 11 Aug 2004 16:50:27 -0400 From: "John Glube" To: "'Jim Lyon'" , "'Andrew Newton'" , "'ietf mxcomp \"\(e-mail\)'" , "'Meng Weng Wong'" Subject: RE: What Meng said Date: Wed, 11 Aug 2004 16:50:08 -0400 Message-ID: <003901c47fe4$ca8dfaf0$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: <81AC085044D04B429F5FB883D94FA1AF80C564@df-fido-msg.exchange.corp.microsoft.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 i7BKoUF6087927 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Jim wrote - >Andy said, quoting Meng: >>11:05:42] if submitter is not present, we fall >>back to mail-from. people are missing this. >From both my reading of the docs, and what I believe was >the intent of the docs, this is wrong. If submitter is >missing, one needs to get the PRA from the data of the >message. (Of course, with submitter one must still verify >that submitter == PRA and reject the message otherwise.) >I think that Meng may be referring to the text that states >that at some date in the future (which hasn't been >specified yet), one may treat the absence of submitter as >submitter == mail-from. However, this can only occur after >very wide-spread adoption of submitter-aware MTAs, and >after another standards action. I am grateful for this clarification. However, it raises the following questions: * Does PRA check for a malformed SMTP mail from? * Does PRA check for a spoofed SMTP mail from? * Does PRA check EHELO? The answer is it does not. PRA ignores any data which may be derived from this information at the data transmission stage. In the absence of Submitter: * An MTA which is running a PRA check must swallow the message to extract the PRA from the headers and carry out the appropriate checks using the sender policy record found in the domain's DNS TXT file. However, some ISPs are going to want to run a full battery of tests (see the earlier comments by Carl Hultzer of AOL) at the data transmission stage. Also we have the apparent decision to have a new version string for sender policy records to allow for PRA checks. What does this mean? Prudent Senders will now have to publish two records, one to allow an MTA to do a SMTP mail from check (and any other checks which may be carried out using this data - based on the unified SPF approach which is not before the IETF but exists in the wild) and one to allow an MTA to do a PRA check, since the proponents are insisting receivers can't rely on any other record set, except that which is specifically designated for use with a PRA check. However, this raises the next series of questions: * When an MTA extracts this data from the DNS TXT file, can the software distinguish between the two records? * Will the need for two records places some Senders in the position of having TXT files which are to large? * Will all this transmission of data cause unforeseen problems during the data transfer stage introducing unforeseen instability into the mail system? I don't know the answer to these questions, but three comments: * Responding to these concerns should be part of the mandate given to the graybeards who are conducting the operation and security review of Sender-ID. * All this discussion points to a solution which allows the sender to publish one sender policy record which can be used by a receiver to carry out any one or more checks the receiver wishes to carry out in accordance with specified protocols as long as the receiver clearly identifies to the sender in the event of failure the specific cause so a solution can be properly diagnosed. * If the underlying objective of sender authentication is to thwart spoofing and other technical means used to hide identity, and since we do not whether the PRA check will in fact achieve this objective in the wild, from a design perspective, this approach allows the receiving MTA to utilize built in redundancy checks. In light of these comments, my ultimate questions are: * Will the chairs now allow the WG to discuss unified SPF as a solution at least as to writing a sender policy record for use by PRA and include the relevant portions allowing receiving MTAs to carry out malformed SMTP mail from, SMTP mail from, EHELO and PTR checks in marid core at the data stage in addition to a PRA check, providing the receiving MTA specifically indicates the reason for rejection, or is this request simply out of order? * If that request is out of order, I would ask for guidance from the chairs to the WG to deal with the issues I have raised. I should add that in raising the noted issues I am not wishing to make life any more difficult for people than it already is. But, I am concerned if we don't address these concerns as Meng has pointed out, we may well end up in the wrong place at the end of the day. I am asking for a solution which reasonably meets the underlying objective, while facilitating a common goal which all parties can reasonably support. 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.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 17:06:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17044 for ; Wed, 11 Aug 2004 17:06: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 i7BKuYxk089416; Wed, 11 Aug 2004 13:56: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 i7BKuYhL089415; Wed, 11 Aug 2004 13:56: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 i7BKuXtf089409 for ; Wed, 11 Aug 2004 13:56:33 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7BKubj13138; Wed, 11 Aug 2004 13:56:37 -0700 Date: Wed, 11 Aug 2004 13:56:32 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <279935932.20040811135633@brandenburg.com> To: "Jim Lyon" CC: "Andrew Newton" , "ietf mxcomp \"(e-mail)" Subject: Re: What Meng said In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF80C660@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF80C660@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> I tend to agree. Should we remove the language about the future from JL> the SUBMITTER spec? my very strong, personal preference is to have a specification make no statements about the future, and particularly not about plans. the one exception, of course, is to show technical possibilities. examples of how a spec is capable of being enhanced. not will be, not planned to be, but what technical flexibilities are present. and of course it's always good to show examples of how the spec might be used NOW (or, rather, after it is published...) sorry for being so pedantic, but i want to be clear about what i do mean by the suggestion. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 17:28: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 RAA19423 for ; Wed, 11 Aug 2004 17:28: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 i7BLB73V091332; Wed, 11 Aug 2004 14: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 i7BLB7UX091331; Wed, 11 Aug 2004 14:11: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 i7BLB7IQ091325 for ; Wed, 11 Aug 2004 14:11:07 -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, 11 Aug 2004 17:11:09 -0400 id 00197696.411A8B6D.00002272 In-Reply-To: <003901c47fe4$ca8dfaf0$6c62fea9@ibmrkydk2ufvdd> References: <003901c47fe4$ca8dfaf0$6c62fea9@ibmrkydk2ufvdd> 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 \"(e-mail)" From: Andrew Newton Subject: Re: What Meng said Date: Wed, 11 Aug 2004 17:11:08 -0400 To: "John Glube" 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 Aug 11, 2004, at 4:50 PM, John Glube wrote: > * Will the chairs now allow the WG to discuss unified SPF > as a solution at least as to writing a sender policy record > for use by PRA and include the relevant portions allowing > receiving MTAs to carry out malformed SMTP mail from, SMTP > mail from, EHELO and PTR checks in marid core at the data > stage in addition to a PRA check, providing the receiving > MTA specifically indicates the reason for rejection, or is > this request simply out of order? The reason I asked that alternate proposals not be discussed is that we have already had people complain about the confusion. So please, lets hold back the flood gates just a little while longer. > * If that request is out of order, I would ask for guidance > from the chairs to the WG to deal with the issues I have > raised. Discussion of the problem is certainly relevant. Its the proposing of the solutions that seems to be confusing people. -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 17:34: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 RAA20261 for ; Wed, 11 Aug 2004 17:34: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 i7BLNLRH092109; Wed, 11 Aug 2004 14:23: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 i7BLNLdu092108; Wed, 11 Aug 2004 14:23:21 -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 i7BLNKdd092101 for ; Wed, 11 Aug 2004 14:23:21 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040811212325.UILW19123.tomts20-srv.bellnexxia.net@ibmrkydk2ufvdd>; Wed, 11 Aug 2004 17:23:25 -0400 From: "John Glube" To: "'Andrew Newton'" Cc: "'ietf mxcomp \"\(e-mail\)'" Subject: RE: What Meng said Date: Wed, 11 Aug 2004 17:23:06 -0400 Message-ID: <003c01c47fe9$64be30f0$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 i7BLNLdd092102 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Andy wrote, >>On Aug 11, 2004, at 4:50 PM, John Glube wrote: >>* Will the chairs now allow the WG to discuss unified SPF >>as a solution at least as to writing a sender policy record >>for use by PRA and include the relevant portions allowing >>receiving MTAs to carry out malformed SMTP mail from, SMTP >>mail from, EHELO and PTR checks in marid core at the data >>stage in addition to a PRA check, providing the receiving >>MTA specifically indicates the reason for rejection, or is >>this request simply out of order? >The reason I asked that alternate proposals not be >discussed is that we have already had people complain about >the confusion. So please, lets hold back the flood gates >just a little while longer. >>* If that request is out of order, I would ask for guidance >>from the chairs to the WG to deal with the issues I have >>raised. >Discussion of the problem is certainly relevant. Its the >proposing of the solutions that seems to be confusing >people. I thank you for taking the time to respond and will follow the WG chairs guidance as to when it is appropriate to put forward alternate solutions to deal with the problems raised, if they are not resolved in the interim. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 17:54:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22467 for ; Wed, 11 Aug 2004 17:54:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLcd6r093242; Wed, 11 Aug 2004 14:38: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 i7BLcdte093241; Wed, 11 Aug 2004 14:38:39 -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 i7BLcdn4093235 for ; Wed, 11 Aug 2004 14:38:39 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.153] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id D941340E3 for ; Wed, 11 Aug 2004 14:38:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: What Meng said Date: Wed, 11 Aug 2004 14:38:38 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit First, some comments: Alas, due to the way ESMTP extensions work, there is no way to know if the client supports the extension unless it uses it. For one reasons I'm not aware of, the current state of the draft allows four states: The client doesn't understand SUBMITTER 1) there is no SUBMITTER= The client does understand SUBMITTER and: PRA == MAIL FROM and 2) the client leaves SUBMITTER= off or 3) the client includes SUBMITTER= anyway PRA != MAIL FROM 4) the client includes SUBMITTER= Alas, there is no way to distinguish state 1 from 2. Sure, things would be tighter if we disallow state 2. I'm not sure this is a big deal. If you leave state 2 in, then many environments where PRA always equals MAIL FROM needn't change any software and can claim compliance. Of course, I'm not sure there are really any such domains. I also tend to agree that any language about what might happen if we require SUBMITTER in the future should be left out of the draft unless we actually agree on what will happen, and when we will do it. Second, In the language of pseudo-code, Here are is what I think combined Sender-ID and SUBMITTER requires an MTA to do: accept body of message extract PRA from headers if the client supplied SUBMITTER= { if SUBMITTER != PRA { exit with fail } } r0 = check PRA against the Sender-ID record exit with r0 Of course, this doesn't gain any possible advantage from SUBMITTER. This is what an aggressive MTA can do: if client supplies SUBMITTER= { r1 = check SUBMITTER against its Sender-ID record if r1 is pass { if SUBMITTER is on your white-list, or has a high enough reputation score { accept body of message exit with pass, no further checks needed } } else if r1 is fail { reject mail (still prior to DATA) exit with fail } -- r1 is either unknown or error at this point -- accept body of message extract PRA from headers if PRA != SUBMITTER { exit with fail } if PRA == SUBMITTER { exit with r1 } } else client supplies just Mail From { r2 = check MAIL FROM against its Sender-ID record (hoping it will be same as PRA) accept body of message extract PRA from headers if PRA == MAIL FROM { exit with r2 } r3 = check PRA against its Sender-ID record exit with r3 } This is more convoluted than the draft requires because it is trying to stave off as much work as possible. Specifically, if the reputation is high, or is on a white-list, then the PRA extraction from the headers can be skipped (as your local mail policy essentially trusts that domain's machines (as authorized via Sender-ID) to do the right thing.) This code also tries to get as much going in parallel as possible. Not only is it getting the SUBMITTER (if present) check going quickly; a site can speculatively try MAIL FROM (in the absence of SUBMITTER), in hopes that by the time it gets the headers, the result will be back, and MAIL FROM will match PRA. If we change the spec to eliminate state 2 above (where a client that understands SUBMITTER omits it if PRA == MAIL FROM), then really, NOTHING in the above code changes. An MTA can't be any more aggressive. In summary (did you ever think I'd get to one?): - I think Meng's interpretation is wrong. - Removing the ability to omit SUBMITTER if PRA equals MAIL FROM doesn't really matter - As defined, this all works to save processing time for a receiver if it a) the MTA can take advantage of starting Sender-ID checks in parallel with receiving the DATA, and/or b) the receiving domain has a white-list or a reputation system it trusts. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 18: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 SAA27795 for ; Wed, 11 Aug 2004 18: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 i7BMOFvN096584; Wed, 11 Aug 2004 15: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 i7BMOFPe096583; Wed, 11 Aug 2004 15:24: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 i7BMOCJQ096553 for ; Wed, 11 Aug 2004 15:24:14 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 132FA28558 for ; Thu, 12 Aug 2004 00:24:12 +0200 (CEST) Received: from totor.bouissou.net ([127.0.0.1]) by localhost (totor.bouissou.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14934-05 for ; Thu, 12 Aug 2004 00:24:08 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 79F372851E; Thu, 12 Aug 2004 00:24:08 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Thu, 12 Aug 2004 00:24:08 +0200 (CEST) Message-ID: <43763.127.0.0.1.1092263048.squirrel@127.0.0.1> In-Reply-To: <20040811185508.GH28401@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040811185508.GH28401@dumbo.pobox.com> Date: Thu, 12 Aug 2004 00:24:08 +0200 (CEST) Subject: Re: What Meng said From: "Michel Bouissou" To: "ietf mxcomp (e-mail)" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Meng Weng Wong a écrit : > > On a separate note, I have heard that EzMLM and YahooGroups > lists do not pass the PRA test. I believe the Sympa MLM (http://www.sympa.org) doesn't pass it either, because it doesn't add any "Sender:" nor "Resent-From:" nor whatever header that PRA uses. Although this can probably be easily "fixed in a future version", this would be "one more thing that will need and upgrade" to be PRA compliant. > The new core draft may benefit from an applicability statement that > waives the PRA test for recognized mailing lists. Then you have to define "recognized mailing lists", which might be a matter for yet another draft. If a candidate standard has to start its life by making exceptions for a number of situations, I believe it shows that it is basically flawed. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 18:59: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 SAA28800 for ; Wed, 11 Aug 2004 18:59: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 i7BMibXe097799; Wed, 11 Aug 2004 15:44:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BMib5o097798; Wed, 11 Aug 2004 15:44:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BMibKD097792 for ; Wed, 11 Aug 2004 15:44:37 -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 i7BMicfk029354 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 Aug 2004 18:44:39 -0400 Date: Wed, 11 Aug 2004 18:44:38 -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: <20040811144436.CDB2F16E1F@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 Wed, 11 Aug 2004, Alan DeKok wrote: > > Dean Anderson wrote: > > And no, I'm not referring to the fact that forwarded mail can only > > authenticate to the last sender. I'm refering to the fact that anyone at > > AOL.com can pretend to be anyone else at AOL.com. > > That's AOL's problem. As it has been all this while. AOL still has spammers signing up. > If you can prove you got "bad" email from AOL, it's their > responsibility to track down the cause & fix it. We already do this now. AOL generally boots abusers. This doesn't happen instantaneously, however. > How is the scenario you quote any different from a user at AOL > sending bad mail, "from" himself? It's not any different. That is my point: This will have no effect on spam: Spam comes from disposable accounts now. It comes from Virus infected machines now. Abusers simply adapt, and keep on what they were doing before. Abusers cost to adapt: practically $0.00. Our cost: Very expensive. --Dean From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 19:13: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 TAA29529 for ; Wed, 11 Aug 2004 19:13: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 i7BMrWo5098340; Wed, 11 Aug 2004 15: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 i7BMrWwM098339; Wed, 11 Aug 2004 15:53:32 -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 i7BMrVqw098331 for ; Wed, 11 Aug 2004 15:53:31 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: "Recognized" mailing lists, RE: What Meng said X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 11 Aug 2004 17:53:30 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D0553D0@srv1.pan-am.ca> Thread-Topic: What Meng said Thread-Index: AcR/9PlSag8z37VjSZWqhGkNUhM9YQAAKa9w 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 i7BMrVqw098334 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > On a separate note, I have heard that EzMLM and YahooGroups > > lists do not pass the PRA test. > > I believe the Sympa MLM (http://www.sympa.org) doesn't pass it either, > > The new core draft may benefit from an applicability statement that > > waives the PRA test for recognized mailing lists. > > Then you have to define "recognized mailing lists", which might be a > matter for yet another draft. Wouldn't it be simpler to ask these guys to perform minor changes to their mailing list software, rather than have to introduce design kluges to work around them just because they're Yahoo and (whatever)MLM? /me resisting urge to make snide comments... -- 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 Aug 11 19:44: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 TAA00913 for ; Wed, 11 Aug 2004 19:44:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNTfWI000698; Wed, 11 Aug 2004 16:29:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BNTf6n000697; Wed, 11 Aug 2004 16:29:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNTfcT000691 for ; Wed, 11 Aug 2004 16:29:41 -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, 11 Aug 2004 16:29:46 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 16:29:46 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 16:29:46 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 16:29:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: What Meng said Date: Wed, 11 Aug 2004 16:29:38 -0700 Message-ID: Thread-Topic: What Meng said Thread-Index: AcR/5skFynM9qsGWQLOWFemCe3/FIAAE8p1Q From: "Harry Katz" To: "Dave Crocker" , "Jim Lyon" Cc: "Andrew Newton" , "ietf mxcomp \"\(e-mail\)" X-OriginalArrivalTime: 11 Aug 2004 23:29:16.0870 (UTC) FILETIME=[04E2AE60:01C47FFB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BNTfcT000692 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, August 11, 2004 1:57 PM, Dave Crocker wrote: > Jim, > > JL> I tend to agree. Should we remove the language about the future > JL> from the SUBMITTER spec? > > > my very strong, personal preference is to have a > specification make no statements about the future, and > particularly not about plans. > > the one exception, of course, is to show technical possibilities. > examples of how a spec is capable of being enhanced. not > will be, not planned to be, but what technical flexibilities > are present. > > and of course it's always good to show examples of how the > spec might be used NOW (or, rather, after it is published...) > > sorry for being so pedantic, but i want to be clear about > what i do mean by the suggestion. > I did remove references to future behavior from the -02 version of the Submitter spec. Please see the change notes at the end of that doc. If I missed any occurrences, please let me know and I'll remove them for -03. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 19:46: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 TAA00981 for ; Wed, 11 Aug 2004 19:46: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 i7BNX42b000944; Wed, 11 Aug 2004 16:33: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 i7BNX4eW000943; Wed, 11 Aug 2004 16:33:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNX3ag000927 for ; Wed, 11 Aug 2004 16:33:03 -0700 (PDT) (envelope-from msk@sendmail.com) Received: from protagonist.smi.sendmail.com ([10.210.202.26]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7BNX7v8007229 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 11 Aug 2004 16:33:07 -0700 Received: from protagonist.smi.sendmail.com (localhost [127.0.0.1]) by protagonist.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i7BNX6sP072060 for ; Wed, 11 Aug 2004 16:33:06 -0700 (PDT) (envelope-from msk@sendmail.com) Received: from localhost (msk@localhost) by protagonist.smi.sendmail.com (8.12.9/8.12.9/Submit) with ESMTP id i7BNX6eE072057 for ; Wed, 11 Aug 2004 16:33:06 -0700 (PDT) (envelope-from msk@sendmail.com) X-Authentication-Warning: protagonist.smi.sendmail.com: msk owned process doing -bs Date: Wed, 11 Aug 2004 16:33:05 -0700 (PDT) From: "Murray S. Kucherawy" X-X-Sender: msk@protagonist.smi.sendmail.com To: "ietf mxcomp \"(e-mail)" Subject: Re: What Meng said In-Reply-To: Message-ID: <20040811163103.G72048@protagonist.smi.sendmail.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 11 Aug 2004, Rand Wacker wrote: > So maybe "people" are reading the specs differently than Meng? ;) Then the intent and the letter of the spec differ. This has to be fixed, or this will fall flat. Your average implementor is not a mind-reader and is probably lazy enough that she/he would not go through the list archive, and thus may (read: likely would) miss such a subtlety. Please revise the spec. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 19: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 TAA01055 for ; Wed, 11 Aug 2004 19: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 i7BNZgHw001052; Wed, 11 Aug 2004 16:35: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 i7BNZghF001051; Wed, 11 Aug 2004 16:35:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNZfCR001042 for ; Wed, 11 Aug 2004 16:35:42 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LDIB9Q1F3K00005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Wed, 11 Aug 2004 16:35:44 -0700 (PDT) Date: Wed, 11 Aug 2004 16:22:57 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: What Meng said In-reply-to: "Your message dated Wed, 11 Aug 2004 14:38:38 -0700" To: Mark Lentczner Cc: IETF MARID WG Message-id: <01LDJMF6N2JC00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > First, some comments: > Alas, due to the way ESMTP extensions work, there is no way to know if > the client supports the extension unless it uses it. For one reasons > I'm not aware of, the current state of the draft allows four states: > The client doesn't understand SUBMITTER > 1) there is no SUBMITTER= > The client does understand SUBMITTER and: > PRA == MAIL FROM and > 2) the client leaves SUBMITTER= off > or 3) the client includes SUBMITTER= anyway > PRA != MAIL FROM > 4) the client includes SUBMITTER= > Alas, there is no way to distinguish state 1 from 2. I was about to point this out... Thanks for doing the analysis. > Sure, things > would be tighter if we disallow state 2. I'm not sure this is a big > deal. If you leave state 2 in, then many environments where PRA always > equals MAIL FROM needn't change any software and can claim compliance. > Of course, I'm not sure there are really any such domains. Mailings lists are pretty common. > I also tend to agree that any language about what might happen if we > require SUBMITTER in the future should be left out of the draft unless > we actually agree on what will happen, and when we will do it. > Second, In the language of pseudo-code, Here are is what I think > combined Sender-ID and SUBMITTER requires an MTA to do: > accept body of message > extract PRA from headers > if the client supplied SUBMITTER= { > if SUBMITTER != PRA { exit with fail } > } > r0 = check PRA against the Sender-ID record > exit with r0 > Of course, this doesn't gain any possible advantage from SUBMITTER. > This is what an aggressive MTA can do: > if client supplies SUBMITTER= { > r1 = check SUBMITTER against its Sender-ID record > if r1 is pass { > if SUBMITTER is on your white-list, or has a high enough reputation score { > accept body of message > exit with pass, no further checks needed > } > } > else if r1 is fail { > reject mail (still prior to DATA) > exit with fail > } > -- r1 is either unknown or error at this point -- Nit: r1 can also be pass at this point. > accept body of message > extract PRA from headers > if PRA != SUBMITTER { exit with fail } > if PRA == SUBMITTER { exit with r1 } > } > else client supplies just Mail From { > r2 = check MAIL FROM against its Sender-ID record (hoping it will be same as PRA) As you note below, this part isn't exactly required, but it does offer the highest degree of operational overlap. > accept body of message > extract PRA from headers > if PRA == MAIL FROM { exit with r2 } > r3 = check PRA against its Sender-ID record > exit with r3 > } > This is more convoluted than the draft requires because it is trying to > stave off as much work as possible. Specifically, if the reputation is > high, or is on a white-list, then the PRA extraction from the headers > can be skipped (as your local mail policy essentially trusts that > domain's machines (as authorized via Sender-ID) to do the right thing.) > This code also tries to get as much going in parallel as possible. Not > only is it getting the SUBMITTER (if present) check going quickly; a > site can speculatively try MAIL FROM (in the absence of SUBMITTER), in > hopes that by the time it gets the headers, the result will be back, > and MAIL FROM will match PRA. > If we change the spec to eliminate state 2 above (where a client that > understands SUBMITTER omits it if PRA == MAIL FROM), then really, > NOTHING in the above code changes. An MTA can't be any more > aggressive. > In summary (did you ever think I'd get to one?): > - I think Meng's interpretation is wrong. Agreed. > - Removing the ability to omit SUBMITTER if PRA equals MAIL FROM > doesn't really matter Agreed. > - As defined, this all works to save processing time for a receiver if > it a) the MTA can take advantage of starting Sender-ID checks in > parallel with receiving the DATA, and/or b) the receiving domain has a > white-list or a reputation system it trusts. Yep. Ned From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 19:56: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 TAA01342 for ; Wed, 11 Aug 2004 19:56: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 i7BNhm10001586; Wed, 11 Aug 2004 16:43: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 i7BNhmKL001585; Wed, 11 Aug 2004 16:43:48 -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 i7BNhlhj001578 for ; Wed, 11 Aug 2004 16:43:47 -0700 (PDT) (envelope-from shevek@astray.com) Received: from shevek (helo=localhost) by kanga.astray.com with local-esmtp (Exim 4.12) id 1Bv2l3-0003jh-00 for ietf-mxcomp@imc.org; Thu, 12 Aug 2004 00:43:49 +0100 Date: Thu, 12 Aug 2004 00:43:49 +0100 (BST) From: Shevek X-X-Sender: shevek@astray.com To: "ietf mxcomp (e-mail)" Subject: Re: "Recognized" mailing lists, RE: What Meng said In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553D0@srv1.pan-am.ca> Message-ID: References: <700EEF5641B7E247AC1C9B82C05D125D0553D0@srv1.pan-am.ca> 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, 11 Aug 2004, Gordon Fecyk wrote: > > > > On a separate note, I have heard that EzMLM and YahooGroups > > > lists do not pass the PRA test. > > > > I believe the Sympa MLM (http://www.sympa.org) doesn't pass it either, > > > > The new core draft may benefit from an applicability statement that > > > waives the PRA test for recognized mailing lists. > > > > Then you have to define "recognized mailing lists", which might be a > > matter for yet another draft. > > Wouldn't it be simpler to ask these guys to perform minor changes to their > mailing list software, rather than have to introduce design kluges to work > around them just because they're Yahoo and (whatever)MLM? So now we're going to ask everyone to rev their DNS servers, their SMTP servers, their MUAs and their MLMs, in the middle of which everyone is incompatible with everyone else. I can really see this working. S. -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 20:01: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 UAA01541 for ; Wed, 11 Aug 2004 20: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 i7BNmagd001854; Wed, 11 Aug 2004 16:48:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BNmafC001853; Wed, 11 Aug 2004 16:48:36 -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 i7BNmZGR001846 for ; Wed, 11 Aug 2004 16:48:36 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7BNmWs8030528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 Aug 2004 19:48:33 -0400 Date: Wed, 11 Aug 2004 19:48:32 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: John Glube cc: "'Michel Bouissou'" , "'IETF MARID WG'" Subject: RE: How is SPF different from RMX? In-Reply-To: <002b01c47fb2$e8f7b2b0$6c62fea9@ibmrkydk2ufvdd> 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, 11 Aug 2004, John Glube wrote: > Dean - > > >The main issue John is disputing above seems to be whether > >junk mail mostly comes from virus infected machines (as I > >suspect) or whether it comes from commercial emailers > >breaking the law (as I think John thinks). This is > >basically a quibble. > > Actually, the underlying issue from my perspective was your > reliance on a report which you claim was published by the > Federal Trade Commission containing a set of statistics > which you claim supports your conclusion as to UBE sources. > > My problem? I can not find this report to verify your > conclusions and you have not provided a working link to > the Commission report you claim supports your position. Ahh. I looked for my reference; my bad; it was Email Labs, not FTC: http://www.emaillabs.com/article_CANSPAMAudit.html The Email Labs study was in January 2004. Searching just now, I didn't find anything by the FTC on CAN-SPAM compliance, which I thought strange. The Act requires the FTC to report on its effectiveness... > Let me explain why I do not propose to go further with the > debate. > > The time and place for this debate was when the IETF > decided to form this working group. I was not invited to discuss this when the IETF formed the working group. Further, the purpose of a working group is to research the questions put to it, and the answers to questions such as feasibility can't be answered ordinarilly at the outset. Though, in this case, information theory does indicate that it is impossible to create a protocol that can't be abused, so the notion of MARID is a priori infeasible, in the same way that perpetual motion machines are infeasible. Physics departments are thus able to avoid researching schemes that amount to perpetual motion machines. Similarly, we _ought_ to be able to avoid researching schemes that require violations of information theory. > To go further would be to wander far from the purpose of > this list given the working group's charter. Feasibility, impact on other protocols, impact on business activities are always relevant issues to any working group's task. > Finally, you go on to write: > > >The authentication and accountability aspects of SPF are > >illusory and are not achievable in the SPF proposal as it > >stands, nor can DNS be used to achieve these goals. This > >subject has been discussed at length on the DNSOP and > >DNSEXT lists, and it is generally agreed that DNS cannot be > >the basis of authentication. > > Dean, this is a most serious charge. However, it is made > without specific proof or example. Without specific proof? That is a pretty credulous claim on the subject on DNS authentication. It is very well known and generally agreed by the experts in these DNS working groups that DNS is itself insecure and can't form the basis of an authentication mechanism. There are well known DNS security exploits such as the BSD R-command exploits that improperly relied on DNS for authentication. Further, there is a specific project called DNSSEC to address these problems. It has unsuccessfully worked on the problem for many years (about 10 years I think). Indeed, the DNS authentication issue is so obvious that I did not list it in my list of 9 serious problems. I was genuinely surprised by your mention of it. There is clearly a serious disconnect if people in this working group think that DNS can be used for authentication and accountability. > At the behest of myself and others, the WG chairs are > soliciting operational and security reviews of the marid > draft proposals (with a focus on the PRA algorithm) from > the graybeards, based on the various specific concerns > raised on this list and during the formal meetings of the > MARID WG. I don't know who, specifically, you are referring to by "graybeards", but it clearly should be reviewed by responsible persons who are impartial to its approval/disapproval. > Also, the WG chairs have arranged for tests to be conducted > of Sender-ID and CSV (not Sender-ID versus CSV) by a large > American ISP with the results to be reported back to this > WG. I think this is rather insufficient, in just the same way as the diebold voting machine tests were insufficient. Diebold ran its own tests saying the voting machines counted correctly---well, __of course__ they count correctly when no one is trying to hack them. We __expect__ them to work properly under __ideal__ conditions. It is real world conditions that we are interested in testing, and where we expect them to fail. "A large American ISP" might have an ulterior interest in SPF, because of the previously described harms to email outsourcing. Even if SPF has no effect on spam, but harms outsourcing, it might still be in the interest of "a large American ISP" to promote SPF. So there is a conflict of interest that is unacceptable. A proper test requires a hostile environment, such as likely to be encountered in the real world. A proper test also needs to be carried out by someone without a conflict of interest in the outcome of the test. > I write Sender-ID, because the concepts behind SPF and > Caller-ID have been merged and a new design was brought > forward in mid-July, to be titled Sender-ID. Ok, I'll have to review that. Might I propose S-ID as a suitable abbreviation for Sender-ID? --Dean From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 20:13: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 UAA02187 for ; Wed, 11 Aug 2004 20: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 i7C003b9002604; Wed, 11 Aug 2004 17:00: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 i7C003Oh002603; Wed, 11 Aug 2004 17:00:03 -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.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C003i0002597 for ; Wed, 11 Aug 2004 17:00:03 -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, 11 Aug 2004 17:00:07 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 17:00:06 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 17:00:07 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 16:59:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Changes in the queue for marid-submitter-03 Date: Wed, 11 Aug 2004 16:59:59 -0700 Message-ID: Thread-Topic: Changes in the queue for marid-submitter-03 Thread-Index: AcR//08yV26r/PjORRuDK5uZ3XSJfw== From: "Harry Katz" To: "IETF MARID List" Cc: X-OriginalArrivalTime: 11 Aug 2004 23:59:52.0311 (UTC) FILETIME=[4AE4C070:01C47FFF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7C003i0002598 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit With a working group deadline of 8/13 for revised drafts rapidly approaching, I'm preparing the -03 version of the submitter specification. While there's been a lot of discussion on this list about whether there's value at all in the submitter extension, I haven't received much feedback about specific changes to the draft itself. Here's what I have so far. Please let me know ASAP (like within the next 24 hours) if there are other amendments or corrections required. Please do not respond on this thread to the question of whether submitter itself is useful - I expect that discussion to continue for some time. :-) Section 1: Reword the advantage of deriving the PRA from RFC 2822 headers to be that of basing the validation on the identity that is most commonly displayed to recipients by existing MUAs as the sender's identity. Section 4.1 : clean up terminolgy referring to an "emtpy" MAIL FROM to use the RFC 2821 term "null reverse-path" Section 4.1: typo SUMBITTER --> SUBMITTER Section 4.2: Add note that presence of the SUBMITTER parameter 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. From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 20:19: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 UAA02453 for ; Wed, 11 Aug 2004 20:19: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 i7C08sOT003400; Wed, 11 Aug 2004 17:08: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 i7C08sOe003399; Wed, 11 Aug 2004 17:08:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C08spC003383 for ; Wed, 11 Aug 2004 17:08:54 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2004 17:11:16 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7C07cCL027493; Wed, 11 Aug 2004 17:07:41 -0700 (PDT) Received: from fenton-w2k01.cisco.com (dhcp-128-107-163-140.cisco.com [128.107.163.140]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7C0fJkZ015398; Wed, 11 Aug 2004 17:41:21 -0700 Message-Id: <4.3.2.7.2.20040811170247.04125090@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Aug 2004 17:10:05 -0700 To: Mark Lentczner , IETF MARID WG From: Jim Fenton Subject: Re: What Meng said In-Reply-To: References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> 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:"1092271281.524284"; x:"432000"; a:"rsa-sha1"; b:"0:970"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"P/4EpUZtYJONsFKXYlRL+G4ys8QIC8KpCn7Ain8I5G+YVEW0huav98G2tAVzN" "3U6zfsuFKOub13D9ck/pQEhbYgSbYmmWkUgq6mb7VerarfZ+Sr3BLuI+H30gg" "Yh7VGew5TXQjlxNYrA7g6V3OXv9kw1b3ncvH2tMPe98iN2fDE="; c:"Date: Wed, 11 Aug 2004 17:10:05 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: What Meng said" 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: Mark, thanks; great analysis of how this works. At 02:38 PM 8/11/2004 -0700, Mark Lentczner wrote: >This is more convoluted than the draft requires because it is trying to stave off as much work as possible. Specifically, if the reputation is high, or is on a white-list, then the PRA extraction from the headers can be skipped (as your local mail policy essentially trusts that domain's machines (as authorized via Sender-ID) to do the right thing.) Just to emphasize the converse, PRA extraction from the headers will still be required unless the reputation is high or on a white-list. Some of the comments I have seen on this list would lead one to believe that extracting the PRA and checking Submitter against it is optional. In fact, not to do so with a sender you don't know well would greatly decrease the effectiveness of Sender ID by spoofing the PRA while using Sender with an authorized domain for the source address of the SMTP client. -Jim From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 20:34:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03177 for ; Wed, 11 Aug 2004 20:34: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 i7C0MGBv004233; Wed, 11 Aug 2004 17:22: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 i7C0MGeL004232; Wed, 11 Aug 2004 17:22:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C0MFZ0004225 for ; Wed, 11 Aug 2004 17:22:15 -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 i7C0MKmN031165 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 Aug 2004 20:22:21 -0400 Date: Wed, 11 Aug 2004 20:22:20 -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: 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 should add that I don't mean to unduly pick on AOL. Their spam problem is not any worse or any better than anyone elses. Other ISPs have the same problem. At most, I would say only that residential ISPs as a category seem to have a worse problem than do ISPs catering purely to business. And that residential customers and by extension residential ISPs have a worse virus-infection problem than do business customers. I think this is not a coincidence. Anyway, AOL is used just the concrete example. My only gripe about AOL (as some may know) is that AOL is not against spam, but only against spam that doesn't pay it advertising fees to communicate to its users. --Dean On Wed, 11 Aug 2004, Dean Anderson wrote: > > On Wed, 11 Aug 2004, Alan DeKok wrote: > > > > > Dean Anderson wrote: > > > And no, I'm not referring to the fact that forwarded mail can only > > > authenticate to the last sender. I'm refering to the fact that anyone at > > > AOL.com can pretend to be anyone else at AOL.com. > > > > That's AOL's problem. > > As it has been all this while. AOL still has spammers signing up. > > > If you can prove you got "bad" email from AOL, it's their > > responsibility to track down the cause & fix it. > > We already do this now. AOL generally boots abusers. This doesn't happen > instantaneously, however. > > > How is the scenario you quote any different from a user at AOL > > sending bad mail, "from" himself? > > It's not any different. That is my point: This will have no effect on > spam: Spam comes from disposable accounts now. It comes from Virus > infected machines now. Abusers simply adapt, and keep on what they were > doing before. > > Abusers cost to adapt: practically $0.00. > > Our cost: Very expensive. > > --Dean > > From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 20:43: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 UAA03622 for ; Wed, 11 Aug 2004 20:43: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 i7C0SYlo005359; Wed, 11 Aug 2004 17:28: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 i7C0SYJF005358; Wed, 11 Aug 2004 17:28: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 (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C0SXMX005352 for ; Wed, 11 Aug 2004 17:28:33 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: "Recognized" mailing lists, RE: What Meng said X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 11 Aug 2004 19:28:38 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D0553D2@srv1.pan-am.ca> Thread-Topic: "Recognized" mailing lists, RE: What Meng said Thread-Index: AcR//xOQLCRwd1mxTSqA2v4fOl6+3wAA9MZg 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 i7C0SXMX005353 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > So now we're going to ask everyone to rev their DNS servers, > their SMTP > servers, their MUAs and their MLMs, in the middle of which > everyone is incompatible with everyone else. Didn't we have this argument already? We're already asking everyone to rev their SMTP servers, and their mailing list servers, IF they want to use these things. -- 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 Aug 11 20:53: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 UAA04169 for ; Wed, 11 Aug 2004 20:53: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 i7C0XisY005919; Wed, 11 Aug 2004 17:33:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C0XiK3005918; Wed, 11 Aug 2004 17:33:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C0XhOL005911 for ; Wed, 11 Aug 2004 17:33:43 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7C0XT77002889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 11 Aug 2004 20:33:43 -0400 Subject: Re: "Recognized" mailing lists, RE: What Meng said From: Mark Shewmaker To: Shevek Cc: "ietf mxcomp (e-mail)" In-Reply-To: References: <700EEF5641B7E247AC1C9B82C05D125D0553D0@srv1.pan-am.ca> Content-Type: text/plain Message-Id: <1092271010.18780.979.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 20:36:53 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Wed, 11 Aug 2004 20:33:44 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-11 at 19:43, Shevek wrote: > On Wed, 11 Aug 2004, Gordon Fecyk wrote: > > > > The new core draft may benefit from an applicability statement that > > > > waives the PRA test for recognized mailing lists. > > > > > > Then you have to define "recognized mailing lists", which might be a > > > matter for yet another draft. > > > > Wouldn't it be simpler to ask these guys to perform minor changes to their > > mailing list software, rather than have to introduce design kluges to work > > around them just because they're Yahoo and (whatever)MLM? > > So now we're going to ask everyone to rev their DNS servers, their SMTP > servers, their MUAs and their MLMs, in the middle of which everyone is > incompatible with everyone else. > > I can really see this working. There are two possible changes: 1. Yahoo uses a "Mailing List:" header instead of an RFC 2919 "List-ID:" Header. If the PRA algorithm had "List-ID:" between Sender: and From:, then we could ask mailing lists to use RFC 2919 headers. It's still asking "nonconforming" mailing lists to conform to something we want, but at least it's asking them to conform to an existing standard instead of something we seemingly just made up on the spot (PRA). In addition, it will make things easier for their users anyway to have a List-ID header that more and more MUA's recognize for mail sorting. So that requires us to change something, (PRA), and them to change something (use List-ID). (It also means sender_agents would work better. :-) ) 2. Why is asking mailing lists to use Sender:, (compatible to existing PRA) in bad form or unlikely to be effective? From RFC 2822: |The originator fields indicate the mailbox(es) of the source of the |message. The "From:" field specifies the author(s) of the message, |that is, the mailbox(es) of the person(s) or system(s) responsible |for the writing of the message. The "Sender:" field specifies the |mailbox of the agent responsible for the actual transmission of the |message. For example, if a secretary were to send a message for |another person, the mailbox of the secretary would appear in the |"Sender:" field and the mailbox of the actual author would appear in |the "From:" field. If the originator of the message can be indicated |by a single mailbox and the author and transmitter are identical, the |"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD |appear. We'd just be asking mailing lists to do what 2822 says they SHOULD be doing anyway.. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 21:02:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04669 for ; Wed, 11 Aug 2004 21:02: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 i7C0nBlu006957; Wed, 11 Aug 2004 17: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 i7C0nBuS006956; Wed, 11 Aug 2004 17:49:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from totor.bouissou.net (totor.bouissou.net [82.67.27.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C0n9to006945 for ; Wed, 11 Aug 2004 17:49:10 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id D2D9C2852C for ; Thu, 12 Aug 2004 02:49:14 +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 19045-03 for ; Thu, 12 Aug 2004 02:49:11 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 372972851F; Thu, 12 Aug 2004 02:49:11 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Thu, 12 Aug 2004 02:49:11 +0200 (CEST) Message-ID: <45279.127.0.0.1.1092271751.squirrel@127.0.0.1> In-Reply-To: <1092271010.18780.979.camel@localhost.localdomain> References: <700EEF5641B7E247AC1C9B82C05D125D0553D0@srv1.pan-am.ca> <1092271010.18780.979.camel@localhost.localdomain> Date: Thu, 12 Aug 2004 02:49:11 +0200 (CEST) Subject: Re: 'Recognized' mailing lists, RE: What Meng said From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Mark Shewmaker a écrit : > > There are two possible changes: > > 1. Yahoo uses a "Mailing List:" header instead of an RFC 2919 > "List-ID:" Header. If the PRA algorithm had "List-ID:" between > Sender: and From:, then we could ask mailing lists to use RFC 2919 > headers. It would be nice as many MLMs that maybe don't use "Sender:" nor "Resent-From:", do insert a "List-ID:" header. That would just be a minor addition ;-) to the yet very simple and straightforward PRA algorithm... But er... taken from headers of actual mailing-lists that I receive from different kinds of MLMs... Some put: List-ID: ...but some put: List-ID: Ohoho... And some even put: List-ID: Long description without quotes or anything Uh... Too bad. The PRA algorithm will really need to be smart ;-) -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 21:19:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06239 for ; Wed, 11 Aug 2004 21:19: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 i7C13KTq007867; Wed, 11 Aug 2004 18:03: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 i7C13K3r007866; Wed, 11 Aug 2004 18:03:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C13Kfv007859 for ; Wed, 11 Aug 2004 18:03:20 -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 i7C13PLP031892 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 Aug 2004 21:03:25 -0400 Date: Wed, 11 Aug 2004 21:03:25 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Rand Wacker cc: "'IETF MARID WG'" Subject: Re: Analysis of SPF benefits for reduced filtering In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 10 Aug 2004, Rand Wacker wrote: > On Tue, 10 Aug 2004, Dean Anderson wrote: > > > It has been reported that AOL is already using SPF to give reduced > > filtering to SPF-using domains. Is this a good idea? > > Incorrect, see http://postmaster.aol.com/spf/: > > --- > AOL will begin using SPF records to maintain our whitelist in the near > future. If you want to remain on AOL's whitelist, you will need to > establish an SPF record for your domain as AOL will begin to query > whitelisted IP addresses from a domain's SPF record shortly. Without an > SPF record, your whitelist entries may expire. > --- What do you mean by "establish an SPF record"? This just means putting an SPF record in for your domain right? Is there something AOL-specific that must go in this record? > And you are right, giving *preferred* treatment for successful > authentication (without other tools like a whitelist) is a bad thing to > do. Ok, but if you already have a whitelist, what's the point of having SPF? One can easily use DJB's rbldns for a DNS whitelist, with practically the same Sendmail/etc rule as a DNS blacklist. There's only a trivial config difference between DNS whitelisting and DNS blacklisting. If you use SPF to maintain your whitelist, then anyone who creates an SPF record will get whitelisted. Do you mean that only certain domains will be whitelisted? If so, then it seems to me that SPF is just a proprietary protocol for AOL to maintain its whitelist, and a way for AOL to discourage outsourcing. Neither of these things seem to be in the interests of the IETF or the internet community. That said, you need more than just a whitelist. If you subject any email to less filtering, and it is known from which domains you do that with, you will encourage abusers to conduct abuse from those domains, and your users will get more junk. Whitelisting has to be done carefully, and its more of a response to abusive blacklists by selectively rejecting the blacklist than a rational response to spam. We also whitelists, but only around particular filter flaws: One of things we do is count each occurance of an IP address in headers. Too bulky, and messages with that IP address get queued instead of delivered. This test has to be disabled for common addresses (192.168/16, 172.16/14, and 10/8) as well as our own mailservers and those of large ISPs. This only modifies _this_ particular test, and only because _this_ test is invalid if there is genuinely a lot of email from a particular IP address. But I would not want to whitelist just any domain that has an SPF record. That would be bad. But I have some doubts about the overall validity of that bulkiness test. If the test were valid, it might in fact be helpful if Large ISPs did identify their outbound servers. However, finding out this information is not hard, if only you monitor your mail queues. It hardly seems worth the trouble of an IETF protocol. > Subjecting /un-authenticated/ messages to increased scrutiny might be > justified to do though (as Microsoft has announced they will start > doing). I'd like to draw your attention to relativity: Subjecting /un-authenticated/ messages to _more_scrutiny_ is the same as subjecting authenticated messages to _less_scrutiny_ -- From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 21:27: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 VAA06489 for ; Wed, 11 Aug 2004 21:27: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 i7C1F3Rf008965; Wed, 11 Aug 2004 18:15: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 i7C1F3PN008964; Wed, 11 Aug 2004 18:15:03 -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 i7C1F2r1008958 for ; Wed, 11 Aug 2004 18:15:02 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 'Recognized' mailing lists, RE: What Meng said X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 11 Aug 2004 20:15:08 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D0553D4@srv1.pan-am.ca> Thread-Topic: 'Recognized' mailing lists, RE: What Meng said Thread-Index: AcSACM75H3CCY/DtSvatQSc/A4/b2wAAFrCw From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7C1F3r1008959 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Some put: > List-ID: > ...but some put: > List-ID: > Ohoho... And some even put: > List-ID: Long description without quotes or anything > > > Uh... Too bad. The PRA algorithm will really need to be smart ;-) Sounds like certain mailing list software needs to be fixed. I suppose I shouldn't talk, what with certain server applications inserting nonstandard headers into list posts and throwing off threading displays in standardized mail applications. Right, Harry? Bob? Though I'm sure fixes will be available eventually, for a cost of whatever. Maybe you're right. "That's the good thing about standards. There are so many to choose 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 Wed Aug 11 21:30: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 VAA06696 for ; Wed, 11 Aug 2004 21:30: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 i7C1KRJZ009400; Wed, 11 Aug 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 i7C1KRIf009399; Wed, 11 Aug 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 mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C1KRVI009388 for ; Wed, 11 Aug 2004 18:20:27 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LDIB9Q1F3K00005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Wed, 11 Aug 2004 18:20:31 -0700 (PDT) Date: Wed, 11 Aug 2004 18:14:06 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Changes in the queue for marid-submitter-03 In-reply-to: "Your message dated Wed, 11 Aug 2004 16:59:59 -0700" To: Harry Katz Cc: IETF MARID List , eric@sendmail.com Message-id: <01LDJQ33K4PS00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > While there's been a lot of discussion on this list about whether > there's value at all in the submitter extension, I haven't received much > feedback about specific changes to the draft itself. Here's what I have > so far. Please let me know ASAP (like within the next 24 hours) if > there are other amendments or corrections required. Please do not > respond on this thread to the question of whether submitter itself is > useful - I expect that discussion to continue for some time. :-) > Section 1: Reword the advantage of deriving the PRA from RFC 2822 > headers to be that of basing the validation on the identity that is most > commonly displayed to recipients by existing MUAs as the sender's > identity. Sounds like a good idea. > Section 4.1 : clean up terminolgy referring to an "emtpy" MAIL FROM to > use the RFC 2821 term "null reverse-path" I'd be tempted to go even further and make it mandatory for SUBMITTER= to be used regardless of whether or not it matches the MAIL FROM. I'm also not comfortable with the bit about modifying the RFC 2822 header to match the SUBMITTER field. I understand the rationale for having this, but I think giving license to piddle with the headers to an SMTP client goes a bit too far. How about saying that the SMTP client can only do this sort of thing if the SUBMITTER value on hand is found not to match the header and the SUBMITTER value is known to be more "accurate" than what's in the header. If the header is more definitive, the right thing to do is set the SUBMITTER to match it, not the other way around. > Section 4.1: typo SUMBITTER --> SUBMITTER > Section 4.2: Add note that presence of the SUBMITTER parameter 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. This also sounds like a good idea. Ned From owner-ietf-mxcomp@mail.imc.org Wed Aug 11 21:52: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 VAA07731 for ; Wed, 11 Aug 2004 21:52: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 i7C1e2Xu011488; Wed, 11 Aug 2004 18:40: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 i7C1e21L011487; Wed, 11 Aug 2004 18:40:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C1e15t011481 for ; Wed, 11 Aug 2004 18:40:02 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: How is SPF different from RMX? X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 11 Aug 2004 20:40:07 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D0553D6@srv1.pan-am.ca> Thread-Topic: How is SPF different from RMX? Thread-Index: AcSABNJ6FZ2ElykbQVaN/44zPgWhHAAADEig From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7C1e25t011482 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > My only > gripe about AOL (as some may know) is that AOL is not against > spam, but only against spam that doesn't pay it advertising fees to > communicate to its users. I understand that a lot of us have short term memories[1], so this may come as a shock. The only other person I have ever heard this type of comment from was Sanford Wallace back in his Cyberpromo days. "He accused America Online of getting Sprint to act, because Cyber Promotion was AOL's competitor for advertising dollars." http://www.computerbits.com/archive/1997/0100/surf9701.html A comment like this doesn't sound much different from old "spamford." [1] Yet another parallel with the anti-virus industry. -- 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 Aug 11 22:39: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 WAA09855 for ; Wed, 11 Aug 2004 22:39: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 i7C2RkSQ016340; Wed, 11 Aug 2004 19:27: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 i7C2Rkf0016339; Wed, 11 Aug 2004 19:27:46 -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 i7C2RiPv016331 for ; Wed, 11 Aug 2004 19:27:45 -0700 (PDT) (envelope-from sb0-0642d469d6-johnl@iecc.com) Received: (qmail 23309 invoked by uid 100); 12 Aug 2004 02:27:50 -0000 Date: 12 Aug 2004 02:27:50 -0000 Message-ID: <20040812022750.23308.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: record size and wild cards In-Reply-To: <4119C69E.5C1A@xyzzy.claranet.de> Organization: I.E.C.C., Trumansburg NY USA Cc: nobody@xyzzy.claranet.de Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >So if you have a sender policy for *.example.org now and it >covers foo.example.org, then it would automatically cover >_marid.foo.example.org That's quite true, but that loses the benefit of segregating the MARID records in _marid. Say you have three services, _marid, _able, and _baker, each of which has its own TXT record. In the absence of wildcards, you'd put one record each under _marid.foo.example.com, _able.foo,example.com, and _baker.foo.example.com. If you have wildcard subdomains, you'd like to put one record each at _marid.*.example.com, _able.*,example.com, and _baker.*.example.com, but you can't, since DNS wildcards don't work that way. So what you have to do is to put all three records at *.example.com so that applications using any of the services get all three records and throw away the ones they don't want. The problem is that the DNS packet includes all three records so its size is the sum of all the records. If the records get big, blammo. This is specifically an issue if there are two versions of SPF records. -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711 johnl@iecc.com, Mayor, http://johnlevine.com, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 01:02: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 BAA17145 for ; Thu, 12 Aug 2004 01:02:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C4mdwV029188; Wed, 11 Aug 2004 21:48:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C4md3C029187; Wed, 11 Aug 2004 21:48:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C4mZLx029178 for ; Wed, 11 Aug 2004 21:48:36 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bv7W1-0006OE-00 for ; Thu, 12 Aug 2004 06:48:39 +0200 Received: from 62.80.58.61 ([62.80.58.61]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Aug 2004 06:48:37 +0200 Received: from nobody by 62.80.58.61 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Aug 2004 06:48:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: record size and wild cards Date: Thu, 12 Aug 2004 06:47:49 +0200 Organization: Lines: 19 Message-ID: <411AF675.7FE7@xyzzy.claranet.de> References: <4119C69E.5C1A@xyzzy.claranet.de> <20040812022750.23308.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.61 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 John Levine wrote: > Say you have three services, _marid, _able, and _baker, each > of which has its own TXT record. Tnx, now I got, *.example.com would be ambiguous. But maybe we could get around this problem with an additional "_below": _marid.www.example.com exists => ready, use it for _marid _baker.www.example.com exists => ready, use it for _baker No _marid.foo.example.com => try _marid._below.example.com No _baker.bar.example.com => try _baker._below.example.com Quite expensive, but no more conflicts for different services. Could that be a solution for the "don't abuse TXT fraction" ? Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 01:16: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 BAA18252 for ; Thu, 12 Aug 2004 01:16:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C55eKJ032022; Wed, 11 Aug 2004 22:05:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C55e16032021; Wed, 11 Aug 2004 22:05:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C55d7v032011 for ; Wed, 11 Aug 2004 22:05: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 i7C5BK8B019752; Wed, 11 Aug 2004 22:11:20 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7C5BKjc019749; Wed, 11 Aug 2004 22:11:20 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 11 Aug 2004 22:11:20 -0700 (PDT) From: "william(at)elan.net" To: Frank Ellermann cc: ietf-mxcomp@imc.org Subject: Re: record size and wild cards In-Reply-To: <411AF675.7FE7@xyzzy.claranet.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT Am I the only one experiencing déjà vu? Haven't we been through all these discussions before, like right before and during interim WG meeting.... On Thu, 12 Aug 2004, Frank Ellermann wrote: > > John Levine wrote: > > > Say you have three services, _marid, _able, and _baker, each > > of which has its own TXT record. > > Tnx, now I got, *.example.com would be ambiguous. But maybe > we could get around this problem with an additional "_below": > > _marid.www.example.com exists => ready, use it for _marid > _baker.www.example.com exists => ready, use it for _baker > > No _marid.foo.example.com => try _marid._below.example.com > No _baker.bar.example.com => try _baker._below.example.com > > Quite expensive, but no more conflicts for different services. > Could that be a solution for the "don't abuse TXT fraction" ? > > Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 01:45: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 BAA20238 for ; Thu, 12 Aug 2004 01:45: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 i7C5YexY043947; Wed, 11 Aug 2004 22:34: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 i7C5YeiN043946; Wed, 11 Aug 2004 22:34:40 -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 i7C5Yde4043880 for ; Wed, 11 Aug 2004 22:34:39 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2004 22:38:43 +0000 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7C5Yexs006524 for ; Wed, 11 Aug 2004 22:34:40 -0700 (PDT) Received: from fenton-w2k01.cisco.com (sjc-vpn3-1106.cisco.com [10.21.68.82]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7C66tkZ017645 for ; Wed, 11 Aug 2004 23:07:00 -0700 Message-Id: <4.3.2.7.2.20040811172206.03014dd0@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Aug 2004 22:35:47 -0700 To: ietf-mxcomp@imc.org From: Jim Fenton Subject: Additional security consideration for marid-core 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:"1092290820.946011"; x:"432000"; a:"rsa-sha1"; b:"0:1297"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"iuT3H/x01LiPRkcgEir7P+tCEQH7ICFHPongeQMhzC+U5Jzn1KqtyJPI14fQ/" "aZ50AE88IB36yeIjilvXiC/jjVvgMsj0Xi0iqZcB7LtOd0VNnvBsWBETwgwZI" "H0qmHzHQVfIeNza0IMJ7uRjP/ANeIDvEfwe6jfB6NBiEqrMn8="; c:"Date: Wed, 11 Aug 2004 22:35:47 -0700"; c:"From: Jim Fenton "; c:"Subject: Additional security consideration for marid-core" X-IMAIL-VERIFY: s:"y"; v:"y"; r:"3"; h:"imail.cisco.com" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As promised at last week's meeting, I'd like to propose description of an additional attack for the Security Considerations section of marid-core: ----- 6.4 Address Space Hijacking This mechanism assumes the integrity of IP address space for determining whether a given client is authorized to send messages from a given PRA. In addition to the TCP attack given in section 6.2, a sufficiently resourceful attacker might be able to alter the IP routing structure to permit two-way communication using a specified IP address. It would then be possible to execute an SMTP session that appears to come from an authorized address, without the need to guess TCP sequence numbers or transmit in the blind. Such an attack might occur if the attacker obtained access to a router which participates in external BGP routing. Such a router could advertise a more specific route to a rogue SMTP client, temporarily overriding the legitimate owner of the address. ----- Attackers (typically spammers and phishers) are very good at adapting to countermeasures we put in place. I have been rather concerned that authorization based on IP address will push them in the direction of these sorts of attacks on IP address space, which is a place where none of us would like to see them go. -Jim From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 03:01: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 DAA07777 for ; Thu, 12 Aug 2004 03:01: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 i7C6jfvt076357; Wed, 11 Aug 2004 23:45: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 i7C6jfMJ076356; Wed, 11 Aug 2004 23:45: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 i7C6jem2076348 for ; Wed, 11 Aug 2004 23:45: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 i7C6occt024554; Wed, 11 Aug 2004 23:50:38 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7C6ocpb024551; Wed, 11 Aug 2004 23:50:38 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 11 Aug 2004 23:50:38 -0700 (PDT) From: "william(at)elan.net" To: Jim Fenton cc: ietf-mxcomp@imc.org Subject: Re: Additional security consideration for marid-core In-Reply-To: <4.3.2.7.2.20040811172206.03014dd0@mira-sjc5-1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 11 Aug 2004, Jim Fenton wrote: > As promised at last week's meeting, I'd like to propose description of > an additional attack for the Security Considerations section of marid-core: > ----- > 6.4 Address Space Hijacking > > This mechanism assumes the integrity of IP address space for > determining whether a given client is authorized to send messages from a > given PRA. In addition to the TCP attack given in section 6.2, a > sufficiently resourceful attacker might be able to alter the IP routing > structure to permit two-way communication using a specified IP address. > It would then be possible to execute an SMTP session that appears to > come from an authorized address, without the need to guess TCP sequence > numbers or transmit in the blind. > > Such an attack might occur if the attacker obtained access to a router > which participates in external BGP routing. Such a router could > advertise a more specific route to a rogue SMTP client, temporarily > overriding the legitimate owner of the address. > ----- Considering that I know quite a bit about ip hijacking (as maintainer of http://completewhois.com/hijacked), I don't particularly see it as big threat just because of MARID. First of MARID is not a strong identity by any means and should not be relied on 100% guarantee that client is who he says he is - we're trying to build system that "in mass" is capable of answering this question with fairly good statistical accuracy, but this does not mean perfect accuracy for each individual case. In such a view, there should be no easy way for somebody to crack the system and ip hijacking requires quite a bit of effort and carries strong consequences. It not an easy thing to achieve for somebody to try to use somebody elses (otherwise already actively used) ip space, this will be quickly discovered and tracked to the source ASN doing the announcement. Just having hacked access to bgp router is also not enough, you need to actually have prior authorization with upstream, which it itself will usually require access to email account of isp or organization attacker is trying to appear as. And if somebody does have hacked access to large enough bgp router they could actualy do a lot lot worth things then just spam or phishing (routers are worth quite a bit on the black market, on the order of 1:10,000 or more what zombie is worth). Now it is not exactly that I'm saying its not a threat or that it can not happen (it probably will), but there are a easier means to achieve similar result, like using zombies or if access to particular net is desired hacking computer on that net. But if others do really feel like this should be included as possible threat, my opinion is that first paragraph is all that should be included and is enough (lets not give a spammer who have read the document any ideas about hacking bgp routers, as you so allegantly put at the end it this "is a place where none of us would like to see them go"). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 05: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 FAA16459 for ; Thu, 12 Aug 2004 05:41: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 i7C9NBb8010458; Thu, 12 Aug 2004 02:23: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 i7C9NBc8010457; Thu, 12 Aug 2004 02:23:11 -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 i7C9NADv010449 for ; Thu, 12 Aug 2004 02:23:10 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Additional security consideration for marid-core X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 12 Aug 2004 04:23:10 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D0553DE@srv1.pan-am.ca> Thread-Topic: Additional security consideration for marid-core Thread-Index: AcSAMCapC2xE0zOiRH2GAIisKOPASQAHRv8w From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7C9NADv010452 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I have been > rather concerned that authorization based on IP address will > push them in the direction of these sorts of attacks on IP > address space, which is a place where none of us would like > to see them go. As if this hasn't been done before. ISPs have been authorizing mail relay based on IP for seven years now. And k1dd13z were supposedly attacking IRC and other TCP-based networks for at least as long. I'm not convinced there are attacks they already haven't tried. -- 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 Aug 12 07:00: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 HAA22134 for ; Thu, 12 Aug 2004 07:00: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 i7CAhkeg030935; Thu, 12 Aug 2004 03:43: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 i7CAhkxn030934; Thu, 12 Aug 2004 03:43:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CAhipH030925 for ; Thu, 12 Aug 2004 03:43:45 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56780) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp (Exim 4.34) id 1BvD3c-0006pI-Bt (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Thu, 12 Aug 2004 11:43:40 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BvD3b-0001eG-To; Thu, 12 Aug 2004 11:43:39 +0100 Date: Thu, 12 Aug 2004 11:43:39 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Lentczner cc: IETF MARID WG Subject: Re: What Meng said In-Reply-To: Message-ID: References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 11 Aug 2004, Mark Lentczner wrote: > > The client doesn't understand SUBMITTER > 1) there is no SUBMITTER= > The client does understand SUBMITTER and: > PRA == MAIL FROM and > 2) the client leaves SUBMITTER= off > Alas, there is no way to distinguish state 1 from 2. Sure, things would be > tighter if we disallow state 2. I'm not sure this is a big deal. It makes it much more likely that there will be bugs and interop problems that prevent people from using Sender-ID in interesting ways. I'm working on techniques like BATV that rely on totally different verification rules for the PRA and the bounce address. A clever SPF record coupled with a custom DNS server allows SPF-aware servers (i.e. which check the bounce address as opposed to the PRA) to verify signed bounce addresses without an SMTP callback. If there is confusion in the protocol about whether the PRA or bounce address is being checked then this becomes hopelessly unreliable. > I also tend to agree that any language about what might happen if we require > SUBMITTER in the future should be left out of the draft unless we actually > agree on what will happen, and when we will do it. It's utterly foolish to expect that the Internet will follow your timetable. 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 Thu Aug 12 07:51:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25438 for ; Thu, 12 Aug 2004 07: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 i7CBaAlT042741; Thu, 12 Aug 2004 04:36: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 i7CBaAer042740; Thu, 12 Aug 2004 04:36:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CBa9tM042719 for ; Thu, 12 Aug 2004 04:36:10 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7CBZu77017375 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 Aug 2004 07:35:57 -0400 Subject: RE: Does marid-submitter-02 really make sense? From: Mark Shewmaker To: Douglas Otis Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092243820.5943.180.camel@ddev.mail-abuse.org> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1092310765.3295.1043.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 Aug 2004 07:39:25 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Thu, 12 Aug 2004 07:35:58 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-11 at 13:03, Douglas Otis wrote: > On Tue, 2004-08-10 at 23:04, Mark Shewmaker wrote: > > On Tue, 2004-08-10 at 14:34, Douglas Otis wrote: > > > On Tue, 2004-08-10 at 05:42, Mark Shewmaker wrote: > > Sure you can--you can see if you have white-listed that PRA yourself, or > > if your trusted friends have--thus giving you reason to believe claims > > made by this PRA, > > A public list assessing these identities used to block mail would be > doomed. Abuse *beyond* the domain holder's control would elicit a legal > challenge to any assertion of their reputation that stops their mail. Then people who live in jurisdictions where such is possible will suffer, but that's no reason to make those who live in more civilized parts of the world suffer along with them. > There would be no other recourse. There may be hundreds of such domains > sharing a transparent MTA imposed by their ISP. This convergence may > not be apparent to the recipient, but would allow any of these hundreds > of domains to assert any of these Mailbox Domains. Obviously, domains whose outgoing MTA service is an MTA that allows cross-customer forgeries will likely suffer in reputation. That's quite as it should be, IMHO. If honest-company.com authorizes incompetent-isp.com to send mail on their behalf, but incompetent-isp.com lets we-love-to-forge-emails.com use their servers to forge emails in honest-company's name, well of course honest-company's reputation will suffer. That will happen now, just more indirectly, via IP-based block lists. It can happen after SenderID becomes popular, (assuming people do classicSPF tests to of course), via domain-based (and email based?) block lists, for domains whose outgoing smtp services are hosted at ISPs allowing cross-customer forgeries. But it won't be such a concern for ISPs and other mail service providers that don't allow cross-customer forwarding. So things are only improving in that way. > Also, how would you > rate Mailbox Domains that resolve to being valid, but are outside their > prescribed Mail Channel? I don't understand what you're trying to ask. I don't quite understand the sentence. > > Or you could filter out PRAs with bad reputations--those appearing on > > domain-based block lists. > > A provider of these services would need to obtain a contract that > stipulates PRA identities will NOT be used in conjunction with their > listing services. Why? > As one of your users have vouched for this sender, a > bounce should not be a problem, as this is not a bad actor. I wouldn't assume the "not a bad actor" bit--we're talking about potential attack vectors, so by definition we have to assume that anyone could be a bad actor. Imagine I were an ISP and a forger wanted to use my machine as a source of bounce spams. He could sign up an account "forger" on my machine, then from elsewhere send the bounce spam to his new account and to another customer of mine. As he white-lists himself, his own mail won't bounce because it's sent to his account, (and he presumably forwards it somewhere else to be sent to /dev/null there), but it does bounce when sent to the innocent subscriber--and thus it gets bounced to the "victim" account. Now the "victim" could be one of a number of targeted accounts--or it could be one of a number of people known to immediately become incised at bounce forgeries, such that that they quickly get my IPs put onto blocklists before I realize what's going on. > > Yeah. I'm wondering if, were any RFC to come out for an smtp extension > > allowing per-recipient after-data rejects, if it would soon become > > acceptable to give "too many recipient" errors on second and subsequent > > recipients when the sending MTA (!) doesn't support such an extension. > > Would the sender enumerate each recipient in some fashion to then allow > selective rejections? "selective rejections"--I like that. Possibly--for such an extension to work, the SMTP client would have to let the server know that it understood the extension too, one way or another. Perhaps if, after the server said it supported selective rejectsions after data, say by putting "SRAD" in the EHLO response, the client could enable that behavior with a new "SRAD" command by itself, or perhaps putting "SRAD" as argument to each and every RCPT command. (Though the later seems wasteful to me.) I'm sure there's lots of ways this could be done--and it's by far a more straightforward problem that SenderID. Interestingly enough even if solving this problem were in-scope for this group, so that the same RFC that published SUBMITTER also publishes an after-data-selective-rejections extension, that's *almost* a no-op for SenderID purposes. (!) Clients and servers that supported SUBMITER would have no need for the other extensino because of SenderID purposes, (though it would be convenient for other types of recipient-settable after-data tests), because they'd be using SUBMITTER anyway and thus allowing for per-recipient *pre*-data rejects, which is what everyone wants in the first place. (Well, everyone but forgers and the like.) So, I'm guessing that if NO SUBMITTER == Pull-PRA-from-headers, that smtp servers will simply have to allow only one recipient per no-SUBMITTER message at some point. (Or perhaps more than one--up to the first recipient with a different white list.) Not fun. > > > That assumes there is a check made at this point. This is the great > > > downside when allowing Submitter. This check becomes optional and the > > > modicum of security goes out the window. > > I don't see how the fact that it didn't bother to fill in some paperwork > > mean that there's a security check. > The problem you seem to overlook is that the MUA does not see > Submitter. If the standard allowed the sending MTA to just make up a SUBMITTER without it being in the headers, the presumably it would also be changed to allow the receiving MTA to add non-PRA SUBMITTERS to the headers as a PRA. So IMHO, this specific security worry is more of a moot point--the standard could be worded either way really. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 11:14: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 LAA08331 for ; Thu, 12 Aug 2004 11:14:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEsLJu089442; Thu, 12 Aug 2004 07:54:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CEsLZO089441; Thu, 12 Aug 2004 07:54:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEsLHH089428 for ; Thu, 12 Aug 2004 07:54:21 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Does marid-submitter-02 really make sense? Date: Thu, 12 Aug 2004 09:54:14 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02B047B6@cliff.bai.org> Thread-Topic: Does marid-submitter-02 really make sense? thread-index: AcSAYQoF5a8eJgxIQPST5abc+3VH1gAGKP9w From: "Ryan Malayter" To: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7CEsLHH089436 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Mark Shewmaker] > That will happen now, just more indirectly, via IP-based block lists. Tell me about it. It's pretty much impossible to get de-listed from SPEWS if you're a Qwest DS1/DS3 customer, for instance. Whole class Bs of the Qwest IP space are blacklisted by SPEWS. This is one of the best things about SPF/MARID - it allows us to base reputation on the sending domain's behavior, rather than on the reputation of some large bureaucratic company that won't commit the resources to police the behavior of their thousands of clients in a timely fashion. However, the problem with blacklists getting stale or being incorrect still remains. Once I tried to do a False-Positive/False-Negative comparison of the popular IP blacklists, but was unable to get it working properly with my very rusty C skills. Has anyone ever seen an effective "reputation system for reputation systems"? I've seen a few statistical comparisons of DNSBLs, but they all seem to ignore the most significant item when it comes to spam filtering: the false-positive percentage. Of course, you have to have a person manually evaluating whether or not each message *is* spam to get this data, so perhaps that's why. Such "reputation system grading" is probably something that is going to be even more necessary as SPF/MARID grow in popularity. People will need to know which reputation systems they can trust, right? Regards, Ryan From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 11:49:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10152 for ; Thu, 12 Aug 2004 11:49: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 i7CFXJj7093074; Thu, 12 Aug 2004 08:33: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 i7CFXJJD093073; Thu, 12 Aug 2004 08:33:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CFXJIJ093067 for ; Thu, 12 Aug 2004 08:33:19 -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 i7CFXBj23245; Thu, 12 Aug 2004 08:33:11 -0700 Date: Thu, 12 Aug 2004 08:33:05 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <932553886.20040812083305@brandenburg.com> To: Mark Lentczner CC: IETF MARID WG Subject: Re: What Meng said In-Reply-To: References: <8D4A745B-EBB0-11D8-97B2-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 Mark, ML> I also tend to agree that any language about what might happen if we ML> require SUBMITTER in the future should be left out of the draft unless ML> we actually agree on what will happen, and when we will do it. just to flog this issue mercilessly: Since "we" (the IETF community) have no control over rates of adoption by the Internet product and services community, any attempt to write a schedule for adoption will be wrong. Certainly the IETF community's track record at predicting adoption rate has always been wrong. The one exception is the assumption that adoption will take much longer than we assume... d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 13:33:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17834 for ; Thu, 12 Aug 2004 13:33: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 i7CH9E9i003259; Thu, 12 Aug 2004 10:09: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 i7CH9Ebc003258; Thu, 12 Aug 2004 10:09: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 i7CH9Aju003241 for ; Thu, 12 Aug 2004 10:09:12 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id B53584149B; Thu, 12 Aug 2004 10:09:08 -0700 (PDT) Subject: RE: Does marid-submitter-02 really make sense? From: Douglas Otis To: Mark Shewmaker Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092310765.3295.1043.camel@localhost.localdomain> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1092330547.7445.101.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 Aug 2004 10:09:07 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-12 at 04:39, Mark Shewmaker wrote: > On Wed, 2004-08-11 at 13:03, Douglas Otis wrote: > > A public list assessing these identities used to block mail would be > > doomed. Abuse *beyond* the domain holder's control would elicit a legal > > challenge to any assertion of their reputation that stops their mail. > > Then people who live in jurisdictions where such is possible will > suffer, but that's no reason to make those who live in more civilized > parts of the world suffer along with them. This does not provided the domain holder any alternative! They have done nothing wrong, and yet a listing based upon Sender-ID claims they did. As a result, their mail is stopped. What is fair or civilized about that? These transparent interception techniques ARE civilized and DO provide significant relief from the amount of abuse suffered upon the world. Sender-ID does NOT offer even a modicum of relief from spam nor enable enforcement. The advocates of Sender-ID exclaim "It is not about spam!" (This is coming from a group tasked to carry forward work of the ASRG?) This is a puzzle. Sender-ID is not about accurately identifying the sender either. Sender-ID does not stop phishing, spoofing or curtailing spoof bounces. The discernible purpose is to disable outside mail services, or, as claimed by Microsoft at the Open Group Forum, Sender-ID is to increase the number of Outlook folders. : ( > > There would be no other recourse. There may be hundreds of such domains > > sharing a transparent MTA imposed by their ISP. This convergence may > > not be apparent to the recipient, but would allow any of these hundreds > > of domains to assert any of these Mailbox Domains. > > Obviously, domains whose outgoing MTA service is an MTA that allows > cross-customer forgeries will likely suffer in reputation. Reputations based upon Sender-ID would never point to their servers as being at fault. Here lies the rub. Sender-ID can not be trusted, and yet the party at fault can not be identified. > That's quite as it should be, IMHO. If you were not wishing to take any action against spam, perhaps. > If honest-company.com authorizes incompetent-isp.com to send mail on > their behalf, but incompetent-isp.com lets we-love-to-forge-emails.com > use their servers to forge emails in honest-company's name, well of > course honest-company's reputation will suffer. Based upon which reputation service? These providers will spend their scant time in court, if they were foolish enough to depend upon the ability of Sender-ID identify miscreants. > That will happen now, just more indirectly, via IP-based block lists. So you are advocating IP based blacklisting as the solution? > It can happen after SenderID becomes popular, (assuming people do > classicSPF tests to of course), via domain-based (and email based?) > block lists, for domains whose outgoing smtp services are hosted at ISPs > allowing cross-customer forgeries. This sounds like mumble, hand-wave. Are you advocating to block all ISP that take measures to control spam, in favor of this new goal of restricting the use of RFC2822 From Mailbox Domains? > But it won't be such a concern for ISPs and other mail service providers > that don't allow cross-customer forwarding. So things are only > improving in that way. You mean to enable spammers? > > Also, how would you rate Mailbox Domains that resolve to being > > valid, but are outside their prescribed Mail Channel? > > I don't understand what you're trying to ask. I don't quite understand > the sentence. Sender-ID allows 5 or 6 levels of acceptance. Sender-ID may validate mail as being fully rated without having emerged from a prescribed set of MTA clients. How does this mail get classified? Would you suggest anyone using one of the Sender-ID options should have their mail blocked? The contract provided by Microsoft specifically absolves them from this type of harm. Who will find themselves in court then? > > > Or you could filter out PRAs with bad reputations--those appearing on > > > domain-based block lists. > > > > A provider of these services would need to obtain a contract that > > stipulates PRA identities will NOT be used in conjunction with their > > listing services. > > Why? Sender-ID must not be trusted as explained. Expectations of a reputation service used against the PRA will not provide satisfactory results. In addition, complaints raised as a result must be ignored. If to provide a reputation service, it must be made clear PRA is not a valid basis for registering complaints nor blocking spam. Is there a better way to make that point clear? > > As one of your users have vouched for this sender, a > > bounce should not be a problem, as this is not a bad actor. > > I wouldn't assume the "not a bad actor" bit--we're talking about > potential attack vectors, so by definition we have to assume that anyone > could be a bad actor. You have allowed a user to create a white-list. If you discover they are white-listing an egregious spammer sending in bulk to non-existent users in your domain, you may reconsider allowing this specific white-listing or perhaps dropping this user. If these messages are to valid users, then it does not sound like a typical spoof bounce attack. It also appears they do not appear on an IP blacklist. > Imagine I were an ISP and a forger wanted to use my machine as a source > of bounce spams. > > He could sign up an account "forger" on my machine, then from elsewhere > send the bounce spam to his new account and to another customer of > mine. As he white-lists himself, his own mail won't bounce because it's > sent to his account, (and he presumably forwards it somewhere else to be > sent to /dev/null there), but it does bounce when sent to the innocent > subscriber--and thus it gets bounced to the "victim" account. I assume you are suggesting this spammer also knows valid accounts on your system, but also knows that these other users will be rejecting their message based upon a filtering result (not a blacklist). > Now the "victim" could be one of a number of targeted accounts--or it > could be one of a number of people known to immediately become incised > at bounce forgeries, such that that they quickly get my IPs put onto > blocklists before I realize what's going on. Hence the need for BATV? As you said, this spammer may not cooperate by using Submitter either. Submitter does not seem to offer any "optimizations" nor does Sender-ID even inspect MAIL FROM. > > > Yeah. I'm wondering if, were any RFC to come out for an smtp extension > > > allowing per-recipient after-data rejects, if it would soon become > > > acceptable to give "too many recipient" errors on second and subsequent > > > recipients when the sending MTA (!) doesn't support such an extension. > > > > Would the sender enumerate each recipient in some fashion to then allow > > selective rejections? > > "selective rejections"--I like that. > > Possibly--for such an extension to work, the SMTP client would have to > let the server know that it understood the extension too, one way or > another. > > Perhaps if, after the server said it supported selective rejectsions > after data, say by putting "SRAD" in the EHLO response, the client could > enable that behavior with a new "SRAD" command by itself, or perhaps > putting "SRAD" as argument to each and every RCPT command. (Though the > later seems wasteful to me.) Fine. > I'm sure there's lots of ways this could be done--and it's by far a more > straightforward problem that SenderID. > > Interestingly enough even if solving this problem were in-scope for this > group, so that the same RFC that published SUBMITTER also publishes an > after-data-selective-rejections extension, that's *almost* a no-op for > SenderID purposes. (!) > > Clients and servers that supported SUBMITER would have no need for the > other extensino because of SenderID purposes, (though it would be > convenient for other types of recipient-settable after-data tests), > because they'd be using SUBMITTER anyway and thus allowing for > per-recipient *pre*-data rejects, which is what everyone wants in the > first place. (Well, everyone but forgers and the like.) > > So, I'm guessing that if NO SUBMITTER == Pull-PRA-from-headers, that > smtp servers will simply have to allow only one recipient per > no-SUBMITTER message at some point. (Or perhaps more than one--up to > the first recipient with a different white list.) > > Not fun. Hence BATV? > > > > That assumes there is a check made at this point. This is the great > > > > downside when allowing Submitter. This check becomes optional and the > > > > modicum of security goes out the window. > > > > I don't see how the fact that it didn't bother to fill in some paperwork > > > mean that there's a security check. > > > The problem you seem to overlook is that the MUA does not see > > Submitter. > > If the standard allowed the sending MTA to just make up a SUBMITTER > without it being in the headers, the presumably it would also be changed > to allow the receiving MTA to add non-PRA SUBMITTERS to the headers as a > PRA. So IMHO, this specific security worry is more of a moot point--the > standard could be worded either way really. The standard can not enforce what a miscreant does. The danger, as stated, is that if only submitter were checked, it would not matter what was contained within these headers and the user would be under the false impression at least one of the headers had been checked. What had been checked will remain a mystery. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 16:12: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 QAA00806 for ; Thu, 12 Aug 2004 16:12: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 i7CJpRZV021236; Thu, 12 Aug 2004 12:51: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 i7CJpRrp021235; Thu, 12 Aug 2004 12:51:27 -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 i7CJpN7m021197 for ; Thu, 12 Aug 2004 12:51:24 -0700 (PDT) (envelope-from sb0-0642d469d6-johnl@iecc.com) Received: (qmail 25255 invoked by uid 100); 12 Aug 2004 19:51:25 -0000 Date: 12 Aug 2004 19:51:25 -0000 Message-ID: <20040812195125.25254.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: record size and wild cards In-Reply-To: <411AF675.7FE7@xyzzy.claranet.de> Organization: I.E.C.C., Trumansburg NY USA Cc: nobody@xyzzy.claranet.de Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> Say you have three services, _marid, _able, and _baker, each >> of which has its own TXT record. > >Tnx, now I got, *.example.com would be ambiguous. But maybe >we could get around this problem with an additional "_below": > >_marid.www.example.com exists => ready, use it for _marid >_baker.www.example.com exists => ready, use it for _baker > >No _marid.foo.example.com => try _marid._below.example.com >No _baker.bar.example.com => try _baker._below.example.com > >Quite expensive, but no more conflicts for different services. >Could that be a solution for the "don't abuse TXT fraction" ? You're basicallly proposing a new DNS wildcard system. That's not a terrible idea (there's certainly been enough criticism of the existing system), but it's a considerably larger scale change than any we've suggested so far and MARID isn't the right place to propose it. In the past, people have proposed using zone cuts as a kind of faux wildcards, which isn't a good idea either. Keep in mind that if marid, able, and baker are each assigned their own DNS record type, existing DNS wildcards work fine. There is a solution to this problem, just not one that overloads everything into TXT records. Too bad a large vendor that likes to make all of its protocols extensible didn't realize that DNS is also extensible when they wrote their DNS proxy code. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly. From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 18:49: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 SAA14874 for ; Thu, 12 Aug 2004 18:49: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 i7CMVhhs039350; Thu, 12 Aug 2004 15: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 i7CMVhkK039349; Thu, 12 Aug 2004 15:31: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 i7CMVgYB039341 for ; Thu, 12 Aug 2004 15:31:42 -0700 (PDT) (envelope-from roy+dated+1094941898.168422@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7CMYIw8068727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 Aug 2004 22:34:24 GMT (envelope-from roy+dated+1094941898.168422@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7CMVcFD036010 for ; Thu, 12 Aug 2004 23:31:38 +0100 (BST) (envelope-from roy+dated+1094941898.168422@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7CMVci0036009 for ietf-mxcomp@imc.org; Thu, 12 Aug 2004 23:31:38 +0100 (BST) (envelope-from roy+dated+1094941898.168422@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 12 Aug 2004 23:31:38 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16667.61385.861840.673819@giles.gnomon.org.uk> Date: Thu, 12 Aug 2004 23:31:37 +0100 To: ietf-mxcomp@imc.org Subject: On the name of the SUBMITTER= parameter X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit There've been a couple of suggestions that the name of the SUBMITTER parameter is confusing. It strikes me that when these drafts were being written, much of the terminology that the WG is now using was still in a state of flux. Indeed, the SUBMITTER parameter went through various different names prior to the ID being written. It srikes me that, where we are now, the obvious parameter is not SUBITTER= but PRA= The purpose of the parameter is to identify, during the SMTP transaction, an identity that we are now universally calling the PRA. The obvious intuitive name for an SMTP parameter that idenfities the PRA is 'PRA'. -roy From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 19:16: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 TAA16512 for ; Thu, 12 Aug 2004 19:16:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMwNh1041425; Thu, 12 Aug 2004 15:58: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 i7CMwNED041424; Thu, 12 Aug 2004 15:58: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 i7CMwN9j041415 for ; Thu, 12 Aug 2004 15:58: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 8958E414B5; Thu, 12 Aug 2004 15:58:25 -0700 (PDT) Subject: Re: On the name of the SUBMITTER= parameter From: Douglas Otis To: Roy Badami Cc: MARID In-Reply-To: <16667.61385.861840.673819@giles.gnomon.org.uk> References: <16667.61385.861840.673819@giles.gnomon.org.uk> Content-Type: text/plain Message-Id: <1092351504.7627.25.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 Aug 2004 15:58: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 Thu, 2004-08-12 at 15:31, Roy Badami wrote: > There've been a couple of suggestions that the name of the SUBMITTER > parameter is confusing. > > It strikes me that when these drafts were being written, much of the > terminology that the WG is now using was still in a state of flux. > Indeed, the SUBMITTER parameter went through various different names > prior to the ID being written. > > It srikes me that, where we are now, the obvious parameter is not > SUBITTER= but PRA= > > The purpose of the parameter is to identify, during the SMTP > transaction, an identity that we are now universally calling the PRA. > > The obvious intuitive name for an SMTP parameter that idenfities the > PRA is 'PRA'. But as Microsoft claims PRA to be their intellectual property and requires a nontransferable signed contract before this value can be ascertained, I think something more like EULA= makes more sense. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 19: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 TAA16683 for ; Thu, 12 Aug 2004 19: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 i7CMuHtj041191; Thu, 12 Aug 2004 15:56:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CMuHNg041190; Thu, 12 Aug 2004 15:56:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMuGo3041181 for ; Thu, 12 Aug 2004 15:56:16 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7CMu877031450 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 Aug 2004 18:56:09 -0400 Subject: RE: Does marid-submitter-02 really make sense? From: Mark Shewmaker To: Douglas Otis Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092330547.7445.101.camel@ddev.mail-abuse.org> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1092351580.19686.1199.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 Aug 2004 18:59:41 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Thu, 12 Aug 2004 18:56:11 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-12 at 13:09, Douglas Otis wrote: > On Thu, 2004-08-12 at 04:39, Mark Shewmaker wrote: > > On Wed, 2004-08-11 at 13:03, Douglas Otis wrote: > > > > A public list assessing these identities used to block mail would be > > > doomed. Abuse *beyond* the domain holder's control would elicit a legal > > > challenge to any assertion of their reputation that stops their mail. > > > > Then people who live in jurisdictions where such is possible will > > suffer, but that's no reason to make those who live in more civilized > > parts of the world suffer along with them. > > This does not provided the domain holder any alternative! Sure it does--use a competent mail service provider. > They have > done nothing wrong, and yet a listing based upon Sender-ID claims they > did. As a result, their mail is stopped. What is fair or civilized > about that? It's perfectly fair and civilized. If you purchase outbound SMTP service from an incompetent mail service provider, their incompetence will mean that you can appear to be engaging in activities that you're not intending to engage in, and recipients will not have any reliable way of telling the difference between your activities and your MSP's actions. That will affect your reputation, no question about it .(Think of the old AEGIS (sp?) IP-based blacklistings a few years ago.) You always have a recourse of going to a better mail service provider. > These transparent interception techniques ARE civilized and > DO provide significant relief from the amount of abuse suffered upon the > world. I don't know what "transparent interception techniques" you're talking about. > Sender-ID does not stop phishing, Well, sender_agents would help in the phishing area. :-) > > Obviously, domains whose outgoing MTA service is an MTA that allows > > cross-customer forgeries will likely suffer in reputation. > > Reputations based upon Sender-ID would never point to their servers as > being at fault. Here lies the rub. Sender-ID can not be trusted, and > yet the party at fault can not be identified. Why can Sender-ID not be trusted in this context? Yes, I agree that it "cannot be trusted" to solve the entire set of problems that it was purported to solve, as well as the problems point out that it won't solve, but it can still identify PRAs--and so if you have a reputation system that you can query about PRAs you've identified, that reputation system could tell you whether you can trust claims from those PRAs. In the case of an untrustworthy PRA, I wouldn't care very much which particular server that message came from, if claims purportedly made from that PRA were said to be untrustable. > > That's quite as it should be, IMHO. > > If you were not wishing to take any action against spam, perhaps. I don't care to take any direct action against spam, no. (Direct action being things like initiating lawsuits, or even spending hours on the phone trying to get network providers to cut off accounts.) I just want systems that authenticates senders in multiple ways, and other systems that provide various measures of reputation against senders, with an end result that recipients by and large aren't affected by the onslaught of spam attempting to reach them. Taking direct actions against spam is a lot more work, and I'm lazy. I'd rather everyone be able to avoid the problem, let forgers and spammers slowly find it harder and harder to acquire new victims, and let them move to more lucrative (and hopefully more honest) pursuits. > > If honest-company.com authorizes incompetent-isp.com to send mail on > > their behalf, but incompetent-isp.com lets we-love-to-forge-emails.com > > use their servers to forge emails in honest-company's name, well of > > course honest-company's reputation will suffer. > > Based upon which reputation service? These providers will spend their ^^^^^^^^^^^^^^^ Who do you refer to here? > scant time in court, if they were foolish enough to depend upon the > ability of Sender-ID identify miscreants. Spending their scant time in court? Talk about unfair and uncivilized! :-) There are multiple measures of reputation involved here--the one I thought we were talking about here is whether you could trust claims purportedly made by a given PRA. That's quite a different thing from whether they're a "miscreant" by any other measure. One can only hope for the development of a distributed reputation system into which reporting participants could securely anonymously/pseudonymously enter information. I only hope it's mathematically possible to do some sort of (buzzword alert) combination of zero-knowledge proof and automatically-maintained webs of trust between pseudonyms, (separate writing-versus-reading webs too hopefully.) > > That will happen now, just more indirectly, via IP-based block lists. > > So you are advocating IP based blacklisting as the solution? It's the substandard solution available now. > > It can happen after SenderID becomes popular, (assuming people do > > classicSPF tests to of course), via domain-based (and email based?) > > block lists, for domains whose outgoing smtp services are hosted at ISPs > > allowing cross-customer forgeries. > > This sounds like mumble, hand-wave. Are you advocating to block all ISP > that take measures to control spam, in favor of this new goal of > restricting the use of RFC2822 From Mailbox Domains? You're not making sense. Where do you get this "block all ISP" bit? I just expect that people who use ISP/MSP's that allow cross-customer forgeries will end up with worse reputations than if they went to more competent ISP/MSPs. > Sender-ID must not be trusted as explained. Expectations of a > reputation service used against the PRA will not provide satisfactory > results. In addition, complaints raised as a result must be ignored. > If to provide a reputation service, it must be made clear PRA is not a > valid basis for registering complaints nor blocking spam. Is there a > better way to make that point clear? I don't know, but it still doesn't make sense to me. Let's say that you use a reputation system says that the PRA "trustable-person@untrustable-msp.com is not trustable. Then even if you get a SenderID PASS on that PRA, unless you've overridden things with a white list on your end, why should you trust claims seemingly coming from trustable-person@untrustable-msp.com? (Claims being "I got this message from someone@example.com" headers in the message body.) > > > As one of your users have vouched for this sender, a > > > bounce should not be a problem, as this is not a bad actor. > > > > I wouldn't assume the "not a bad actor" bit--we're talking about > > potential attack vectors, so by definition we have to assume that anyone > > could be a bad actor. > > You have allowed a user to create a white-list. If you discover they > are white-listing an egregious spammer sending in bulk to non-existent > users in your domain, you may reconsider allowing this specific > white-listing or perhaps dropping this user. If these messages are to > valid users, then it does not sound like a typical spoof bounce attack. Of course it's not a typical attack nowadays. We're talking a weakness in a system that's not yet in place, and how folks can exploit that weakness. No one's going to be attacking the weaknesses of a system before the system is widely implemented, hence those attacks won't be they typical ones right now. > It also appears they do not appear on an IP blacklist. True. > I assume you are suggesting this spammer also knows valid accounts on > your system, but also knows that these other users will be rejecting > their message based upon a filtering result (not a blacklist). That's one way, yes. (I don't see a real difference between the results of "a filtering result" and "a blacklist" btw.) > Hence the need for BATV? SES/BATV is a protection a *sender* can put up to prevent bounces to their own domain--and it's fantastic for that! But as a recipient, you can't use SES to solve a problem, because you are powerless to tell the sender to re-send with an SES-signed return path. (Well, you could refuse all mail that doesn't have either Classic-SPF PASS results or validated SES-or-BATV return paths.) > The danger, as > stated, is that if only submitter were checked, it would not matter what > was contained within these headers and the user would be under the false > impression at least one of the headers had been checked. What had been > checked will remain a mystery. A receiving MTA that didn't want to check could always just prepend the SUBMITTER in a Resent-From body header, and then MUAs would be able to see what was verified. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 22:01: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 WAA24072 for ; Thu, 12 Aug 2004 22:01: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 i7D1cfEs057969; Thu, 12 Aug 2004 18:38: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 i7D1cfg5057968; Thu, 12 Aug 2004 18:38:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1cedo057957 for ; Thu, 12 Aug 2004 18:38:40 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 0B96E4149B; Thu, 12 Aug 2004 18:38:47 -0700 (PDT) Subject: RE: Does marid-submitter-02 really make sense? From: Douglas Otis To: Mark Shewmaker Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092351580.19686.1199.camel@localhost.localdomain> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1092361125.7627.196.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 Aug 2004 18:38:46 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-12 at 15:59, Mark Shewmaker wrote: > On Thu, 2004-08-12 at 13:09, Douglas Otis wrote: > > On Thu, 2004-08-12 at 04:39, Mark Shewmaker wrote: > > > On Wed, 2004-08-11 at 13:03, Douglas Otis wrote: > > > > > > A public list assessing these identities used to block mail would be > > > > doomed. Abuse *beyond* the domain holder's control would elicit a legal > > > > challenge to any assertion of their reputation that stops their mail. > > > > > > Then people who live in jurisdictions where such is possible will > > > suffer, but that's no reason to make those who live in more civilized > > > parts of the world suffer along with them. > > > > This does not provided the domain holder any alternative! > > Sure it does--use a competent mail service provider. I do not understand why you see a network service provider monitoring outbound mail as being incompetent. > > They have done nothing wrong, and yet a listing based upon Sender-ID > > claims they did. As a result, their mail is stopped. What is fair > > or civilized about that? > > It's perfectly fair and civilized. So is a judge. > If you purchase outbound SMTP service from an incompetent mail service > provider, their incompetence will mean that you can appear to be > engaging in activities that you're not intending to engage in, and > recipients will not have any reliable way of telling the difference > between your activities and your MSP's actions. > > That will affect your reputation, no question about it .(Think of the > old AEGIS (sp?) IP-based blacklistings a few years ago.) > > You always have a recourse of going to a better mail service provider. By isolating to the Sender-ID, which may be a small percentage of the traffic traveling through a shared MTA, even should the provider be extremely diligent, this domain may become exploited. It is not the same problem as checking the host by IP. The IP properly identifies the mail stream. If there is an error that blocks such a shared MTA by IP, the problem will be corrected quickly. Sender-ID allows the domain to be exploited, isolated, blocked, and ignored. Ouch. > > These transparent interception techniques ARE civilized and > > DO provide significant relief from the amount of abuse suffered upon the > > world. > > I don't know what "transparent interception techniques" you're talking > about. Some network providers have their routers redirect the destination address for port 25 connections to their SMTP server to monitor the traffic. This is a competent and effective means to quickly identify and remove egregious abuse by checking SMTP error logs. Sender-ID could fully validate for the wrong party however. > > Sender-ID does not stop phishing, > > Well, sender_agents would help in the phishing area. :-) Something like Identified Internet Mail would help. I don't know what you mean by sender-agents. Do you mean a Certificate Authority? > > > Obviously, domains whose outgoing MTA service is an MTA that allows > > > cross-customer forgeries will likely suffer in reputation. > > > > Reputations based upon Sender-ID would never point to their servers as > > being at fault. Here lies the rub. Sender-ID can not be trusted, and > > yet the party at fault can not be identified. > > Why can Sender-ID not be trusted in this context? The identity will always be in question when over a shared MTA. The danger is the inevitable law suit, if the wrong party is identified and hammered by this mistake. > Yes, I agree that it "cannot be trusted" to solve the entire set of > problems that it was purported to solve, as well as the problems point > out that it won't solve, but it can still identify PRAs--and so if you > have a reputation system that you can query about PRAs you've > identified, that reputation system could tell you whether you can trust > claims from those PRAs. No. You can NOT trust the PRA. PRA is potentially comprised of a large set of domains. The domain indicated could be any of a few hundred or a few thousand domains. The recipient would be unable to determine when this could be the case! > In the case of an untrustworthy PRA, I wouldn't care very much which > particular server that message came from, if claims purportedly made > from that PRA were said to be untrustable. If you are the one claiming the PRA to be untrustworthy, how would you know when it was safe to make such an assertion? > > > That's quite as it should be, IMHO. > > > > If you were not wishing to take any action against spam, perhaps. > > I don't care to take any direct action against spam, no. (Direct action > being things like initiating lawsuits, or even spending hours on the > phone trying to get network providers to cut off accounts.) > > I just want systems that authenticates senders in multiple ways, and > other systems that provide various measures of reputation against > senders, with an end result that recipients by and large aren't affected > by the onslaught of spam attempting to reach them. Sender-ID does not provide safe measures for repudiation assessments. Sender-ID does not authenticate senders, it provides a sloppy sorting of senders. Sender-ID will not fend off the onslaught unless having more folders is a defense. > Taking direct actions against spam is a lot more work, and I'm lazy. > > I'd rather everyone be able to avoid the problem, let forgers and > spammers slowly find it harder and harder to acquire new victims, and > let them move to more lucrative (and hopefully more honest) pursuits. Sender-ID does not help in this battle. It is not a good tool but advocates removal of good tools. Sender-ID will not enable enforcement of any policies, but will break mail and cause people to use more and more mailboxes to identify themselves. How does that help? > > > If honest-company.com authorizes incompetent-isp.com to send mail on > > > their behalf, but incompetent-isp.com lets we-love-to-forge-emails.com > > > use their servers to forge emails in honest-company's name, well of > > > course honest-company's reputation will suffer. > > > > Based upon which reputation service? These providers will spend their > ^^^^^^^^^^^^^^^ > Who do you refer to here? The reputation service providers. > > scant time in court, if they were foolish enough to depend upon the > > ability of Sender-ID identify miscreants. > > Spending their scant time in court? Talk about unfair and uncivilized! > :-) I agree. > There are multiple measures of reputation involved here--the one I > thought we were talking about here is whether you could trust claims > purportedly made by a given PRA. That's quite a different thing from > whether they're a "miscreant" by any other measure. The PRA can not be trusted. The PRA can not be used to identify miscreants. The miscreant may be spoofing as trustworthy@trustworthy.com and pass with flying colors. > One can only hope for the development of a distributed reputation system > into which reporting participants could securely > anonymously/pseudonymously enter information. I only hope it's > mathematically possible to do some sort of (buzzword alert) combination > of zero-knowledge proof and automatically-maintained webs of trust > between pseudonyms, (separate writing-versus-reading webs too > hopefully.) If you wish to have a basis for repudiation, start with an identity that can better trusted. How about trustworthy@trustworthy.com:mx01.really-big-isp.com where the authenticated EHLO domain becomes part of the identity. To process this, mask the sub-domain of the EHLO response. > > > That will happen now, just more indirectly, via IP-based block lists. > > > > So you are advocating IP based blacklisting as the solution? > > It's the substandard solution available now. This conclusion could be wrong. It depends upon the level of exploit and the relative traffic from the server. > > > It can happen after SenderID becomes popular, (assuming people do > > > classicSPF tests to of course), via domain-based (and email based?) > > > block lists, for domains whose outgoing smtp services are hosted at ISPs > > > allowing cross-customer forgeries. > > > > This sounds like mumble, hand-wave. Are you advocating to block all ISP > > that take measures to control spam, in favor of this new goal of > > restricting the use of RFC2822 From Mailbox Domains? > > You're not making sense. Where do you get this "block all ISP" bit? > > I just expect that people who use ISP/MSP's that allow cross-customer > forgeries will end up with worse reputations than if they went to more > competent ISP/MSPs. You are suggesting it is okay to block those that might share an MTA server? Better to use a crowded domain then? > > Sender-ID must not be trusted as explained. Expectations of a > > reputation service used against the PRA will not provide satisfactory > > results. In addition, complaints raised as a result must be ignored. > > If to provide a reputation service, it must be made clear PRA is not a > > valid basis for registering complaints nor blocking spam. Is there a > > better way to make that point clear? > > I don't know, but it still doesn't make sense to me. > > Let's say that you use a reputation system says that the PRA > "trustable-person@untrustable-msp.com is not trustable. The PRA can not be trusted. What assertion can be made using a tool that can not be trusted? > Then even if you get a SenderID PASS on that PRA, unless you've > overridden things with a white list on your end, why should you trust > claims seemingly coming from trustable-person@untrustable-msp.com? There is no means to know the level of trust to place on these assertions. It would be foolish to think gaps in these assertions will not be exploited. > (Claims being "I got this message from someone@example.com" headers in > the message body.) You are assuming a mapping that can not be verified. There is no way to know if that is a good assumption, even if it passes all the tests. > > > > As one of your users have vouched for this sender, a > > > > bounce should not be a problem, as this is not a bad actor. > > > > > > I wouldn't assume the "not a bad actor" bit--we're talking about > > > potential attack vectors, so by definition we have to assume that anyone > > > could be a bad actor. > > > > You have allowed a user to create a white-list. If you discover they > > are white-listing an egregious spammer sending in bulk to non-existent > > users in your domain, you may reconsider allowing this specific > > white-listing or perhaps dropping this user. If these messages are to > > valid users, then it does not sound like a typical spoof bounce attack. > > Of course it's not a typical attack nowadays. We're talking a weakness > in a system that's not yet in place, and how folks can exploit that > weakness. > > No one's going to be attacking the weaknesses of a system before the > system is widely implemented, hence those attacks won't be they typical > ones right now. It seems your only defense would be to always use a single recipient limit if you refuse to merge a per user white-list. If the cost for that feature is enough, you should be able to detect abuse by way of logs to make this method of attack rare. As I said, BATV ends this without a large adoption. > > It also appears they do not appear on an IP blacklist. > > True. > > > I assume you are suggesting this spammer also knows valid accounts on > > your system, but also knows that these other users will be rejecting > > their message based upon a filtering result (not a blacklist). > > That's one way, yes. (I don't see a real difference between the results > of "a filtering result" and "a blacklist" btw.) > > > Hence the need for BATV? > > SES/BATV is a protection a *sender* can put up to prevent bounces to > their own domain--and it's fantastic for that! > > But as a recipient, you can't use SES to solve a problem, because you > are powerless to tell the sender to re-send with an SES-signed return > path. (Well, you could refuse all mail that doesn't have either > Classic-SPF PASS results or validated SES-or-BATV return paths.) As I said, it seems your only defense would be to always use a single recipient limit, if you refuse to merge a per user white-list. It would be foolish to expect cooperation if this were an attack. > > The danger, as stated, is that if only submitter were checked, it would > > not matter what was contained within these headers and the user > > would be under the false impression at least one of the headers had > > been checked. What had been checked will remain a mystery. > > A receiving MTA that didn't want to check could always just prepend the > SUBMITTER in a Resent-From body header, and then MUAs would be able to > see what was verified. I suspect this will be the standard practice used by all providers. Prepend a Resent-From to quell support calls. Is this a good practice? The shortest path would be to stop at the EHLO domain and ask if the >From is part of that set. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 12 23:59:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01082 for ; Thu, 12 Aug 2004 23:59: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 i7D3dVMI069423; Thu, 12 Aug 2004 20:39: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 i7D3dVkU069422; Thu, 12 Aug 2004 20:39:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D3dT2U069415 for ; Thu, 12 Aug 2004 20:39:29 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7D3dR77004840 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 Aug 2004 23:39:28 -0400 Subject: RE: Does marid-submitter-02 really make sense? From: Mark Shewmaker To: Douglas Otis Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092361125.7627.196.camel@ddev.mail-abuse.org> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> <1092361125.7627.196.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1092368581.3295.1289.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 Aug 2004 23:43:01 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Thu, 12 Aug 2004 23:39:30 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-12 at 21:38, Douglas Otis wrote: > On Thu, 2004-08-12 at 15:59, Mark Shewmaker wrote: > > On Thu, 2004-08-12 at 13:09, Douglas Otis wrote: > > > On Thu, 2004-08-12 at 04:39, Mark Shewmaker wrote: > > > > On Wed, 2004-08-11 at 13:03, Douglas Otis wrote: > > > > > > > > A public list assessing these identities used to block mail would be > > > > > doomed. Abuse *beyond* the domain holder's control would elicit a legal > > > > > challenge to any assertion of their reputation that stops their mail. > > > > > > > > Then people who live in jurisdictions where such is possible will > > > > suffer, but that's no reason to make those who live in more civilized > > > > parts of the world suffer along with them. > > > > > > This does not provided the domain holder any alternative! > > > > Sure it does--use a competent mail service provider. > > I do not understand why you see a network service provider monitoring > outbound mail as being incompetent. I never said anything like that. (At least I hope I didn't.) (Although with Unified-SPF, I would expect to look forward to a day in which ISPs can safely remove outbound mail blocks at residential addresses. Separate issue though.) > By isolating to the Sender-ID, which may be a small percentage of the > traffic traveling through a shared MTA, even should the provider be > extremely diligent, this domain may become exploited. Then if the shared MTA is exploited, then domain's reputation will suffer, even if the domain didn't actually intend to be a victim. That's simply the way things are. People will not think as highly of that PRA afterward, for some amount of time at least, and won't put as much trust in their claims. People will alter their opinions. I'm sorry if that bothers you. Now, if the PRA tries to start suing people who have started to think less highly of his purported claims, then yes, I think that's unfair and uncivilized behavior on the PRA's part. I don't believe in thought crimes. > It is not the > same problem as checking the host by IP. The IP properly identifies the > mail stream. If there is an error that blocks such a shared MTA by IP, > the problem will be corrected quickly. Sender-ID allows the domain to > be exploited, isolated, blocked, and ignored. Ouch. Yeah--ouch! I can only conclude that people who put themselves in such a vulnerable position are likely to quickly correct the problem when their vulnerabilities are exploited--after which their reputation should improve. Or they'll go out of business. Or they'll go to the courts, at which point I can only hope that their reputation would plummet. (I for one try to avoid doing business with companies like that--companies that won't admit, stand behind, and correct their problems.) > > I don't know what "transparent interception techniques" you're talking > > about. > > Some network providers have their routers redirect the destination > address for port 25 connections to their SMTP server to monitor the > traffic. This is a competent and effective means to quickly identify > and remove egregious abuse by checking SMTP error logs. Sender-ID could > fully validate for the wrong party however. Oh-okay. Well, if it could fully validate for the wrong party, then either the MSP is allowing cross-customer forgeries, or the purported sending domain has their SPF records set up poorly. (Or both.) > > > Sender-ID does not stop phishing, > > > > Well, sender_agents would help in the phishing area. :-) > > Something like Identified Internet Mail would help. I don't know what > you mean by sender-agents. Do you mean a Certificate Authority? It's a modifier I've been pushing for a few months as a way to get SenderID to fully address the phishing problem, to little avail unfortunately. (I'm frustrated at my inability to stir up interest so far, as IMHO sender_agents would make SenderID *FAR* more useful.) See: http://www.imc.org/ietf-mxcomp/mail-archive/msg03112.html Here's the idea in a nutshell: 1. Postulate: Authenticating the return path is a separate sort of thing from authenticating the forwarding path of purported (re) senders. A. Classic SPF validates the return path. SES/BATV validates the return path. B. Sender ID attempts to validate the purported (re) senders, but only validates the latest purported (re) sender directly. C. Phishing detection detection has to do with message body tests, not envelope tests, hence if it were to be included in one of Classic SPF or SenderID, SenderID is the logical choice. So there's a question of how to put such a test in SenderID. 2. Postulate: Since Phishing/re-sender tests and return path bounce-a-bility tests are mostly uncoupled from one another, so should be one's response to a failing result of such tests. A. If I get a message where return-path tests FAIL, then I should reject the message. It doesn't matter if the failure is determined via classic SPF tests, or via SES/BATV tests. B. If I get a message whose contents (including body headers) show it to be internally inconsistent (a type of message corruption) or otherwise a type of internal forgery, I should reject the message. 3. The type of phishing I'm addressing is where someone claims to send a message in a body header From:'s name, but From: isn't okay with that. *OR* A later PRA claims to send a message in the name of a previous PRA, but the previous PRA isn't okay with that. So I proposed a sender_agents modifier that allowed users to say that they don't allow other people (PRA addresses) to speak for them in general, and to give an exception list of addresses that do. So if I got a message From: you, but with a Sender: of good-friend-of-yours, I could do a query to see that you trusted this good friend of yours, so that I should trust the message to be genuine from your point of view, were I to trust that the message really came from your friend. That would mean that if I got the message directly from your friend, I could trust it. Or, if your friend sent the message to my old, trustable ISP, that forwarded it to me, since you had whitelisted your friend going forward, and I had whitelisted my old account at my old ISP going backwards, those two trust chains meet without any PRA in between them, and I can (mostly) trust the message that I ended up getting to be genuine. Or, if you say you participate in sender_agents, and I get a message with body-header From: you, but Sender: evil-person@example.com, I know I can reject the message, even if SenderID said it really came from evil-person, and even if classic-SPF said the return-path was good. (Unless I had white-listed evil-person for some reason--but obviously no technical solution can overcome poor judgement in choosing friends!) Anyway, it's only slightly more complicated than that--in ways you can guess really, to accommodate multiple forwards and mailing lists. But the upshot of it is that sender_agents can stop phishing to a large extent, among participating players. (Ie, if paypal.com published a sender_agent modifier within an spf record, recipients who took advantage of it could have messages they would have received with body header From: billing@paypal.com and Sender: forger@example.com rejected, ***without being dependent upon a single blocklist to see that forger@example.com was untrustworthy***. However, they would be dependent upon blocklists or a keen eye to see notice forgeries of the type of billing@paypa2.com, or billing@paypa1.com (with numeral 1 instead of letter L.)) > > > > Obviously, domains whose outgoing MTA service is an MTA that allows > > > > cross-customer forgeries will likely suffer in reputation. > > > > > > Reputations based upon Sender-ID would never point to their servers as > > > being at fault. Here lies the rub. Sender-ID can not be trusted, and > > > yet the party at fault can not be identified. > > > > Why can Sender-ID not be trusted in this context? > > The identity will always be in question when over a shared MTA. The > danger is the inevitable law suit, if the wrong party is identified and > hammered by this mistake. Sorry--if my reputation system makes me give a poor reputation to someone because they're using a shared MTA that allows cross-customer forgeries, then my reputation system is doing it's job. I simply won't think highly of people who willingly expose themselves to such vulnerabilities. It's unfortunate if I can be prosecuted for such a thought crime. > > There are multiple measures of reputation involved here--the one I > > thought we were talking about here is whether you could trust claims > > purportedly made by a given PRA. That's quite a different thing from > > whether they're a "miscreant" by any other measure. > > The PRA can not be trusted. The PRA can not be used to identify > miscreants. > The miscreant may be spoofing as > trustworthy@trustworthy.com and pass with flying colors. If someone else can spoof trustworthy@trustworthy.com, then I hope my reputation systems will assign a poor reputation to the trustworthy.com domain, because any claims of anyone to be from there aren't, well, trustworthy. The fact that trustworthy@trustworthy.com tells me to trust that a message really comes from him if it comes through a specific IP still doesn't mean I should trust such claims if I know that that specific IP itself isn't trustworthy. (Ie, if trustworthy is a friend of mine who I happen to trust 100%, and he trusts a specific IP 100%, but I only trust it 10%, then I should only trust messages from through that IP, where I can only authenticate via that IP, by just 10%. Goofy wording, but you get the idea.) > If you wish to have a basis for repudiation, start with an identity that > can better trusted. How about > trustworthy@trustworthy.com:mx01.really-big-isp.com where the > authenticated EHLO domain becomes part of the identity. To process this, > mask the sub-domain of the EHLO response. That makes sense, except for the EHLO bit, (getting people to give honest EHLO strings is going to be another herculean effort, GRRR), but..the real reason I wasn't pushing for that level of things is that I don't expect people who report problems to, on the whole, be able to reliably report the sending EHLO domain or even IP. Plus--I expect that people will move to more trustworthy MSP's that don't allow cross-customer-forgeries, so I'm guessing that that level of resolution will not only become unnecessary, but end up being too much work for people to be willing to bother with. > You are suggesting it is okay to block those that might share an MTA > server? If it's an insecure MTA, yes: Today I block MTA IPs that are known to be compromised and spewing viruses. There may be trustworthy people using those IPS--too bad. :-/ But I don't see any reason to block mail from a shared MTA that doesn't allow cross-customer forgeries. But one that does allow those forgeries, and for whom that's become a practical problem, yeah, I would tend to start wanting to block other domains using that MTA. (From a practical point of view it's not a binary thing--some folks would allow a bit and then notice and correct the problem, and for other's it's a technical possibility but a practical impossibility to any large extent.) > It seems your only defense would be to always use a single recipient > limit if you refuse to merge a per user white-list. If the cost for that > feature is enough, you should be able to detect abuse by way of logs to > make this method of attack rare. Yeah. And to be fair, if most MTA's switch to using SUBMITTER anyway, then it's mostly only the forgeries that become expensive. And I guess it's probably worth the expense there. > As I said, BATV ends this without a large adoption. No it doesn't. BATV and SES only help for domains in which the purported sending domain participates. > As I said, it seems your only defense would be to always use a single > recipient limit, if you refuse to merge a per user white-list. It would > be foolish to expect cooperation if this were an attack. Correct. > > A receiving MTA that didn't want to check could always just prepend the > > SUBMITTER in a Resent-From body header, and then MUAs would be able to > > see what was verified. > > I suspect this will be the standard practice used by all providers. Prepend a Resent-From to quell support calls. Is this a good practice? It's a lazy way for recipient MTAs to operate, against the spec but somewhat compatible with it as far as end results go, but I hope they won't *actually* do this. > The shortest path would be to stop at the EHLO domain and ask if the > >From is part of that set. I don't see how that would help--the server sending the message can be different from the domain listed in the return path. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 01:33: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 BAA05358 for ; Fri, 13 Aug 2004 01:33:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D5CkNX076971; Thu, 12 Aug 2004 22:12:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D5CkOU076970; Thu, 12 Aug 2004 22:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D5CjRL076949 for ; Thu, 12 Aug 2004 22:12:45 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7D5Cidt005978 for ; Fri, 13 Aug 2004 06:12:44 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7D5Ci0Z005977; Fri, 13 Aug 2004 06:12:44 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Does marid-submitter-02 really make sense? References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> <1092361125.7627.196.camel@ddev.mail-abuse.org> <1092368581.3295.1289.camel@localhost.localdomain> From: Graham Murray Date: Fri, 13 Aug 2004 06:12:44 +0100 In-Reply-To: <1092368581.3295.1289.camel@localhost.localdomain> (Mark Shewmaker's message of "Thu, 12 Aug 2004 23:43:01 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark Shewmaker writes: > If someone else can spoof trustworthy@trustworthy.com, then I hope my > reputation systems will assign a poor reputation to the trustworthy.com > domain, because any claims of anyone to be from there aren't, well, > trustworthy. > > The fact that trustworthy@trustworthy.com tells me to trust that a > message really comes from him if it comes through a specific IP still > doesn't mean I should trust such claims if I know that that specific IP > itself isn't trustworthy. > > (Ie, if trustworthy is a friend of mine who I happen to trust 100%, and > he trusts a specific IP 100%, but I only trust it 10%, then I should > only trust messages from through that IP, where I can only authenticate > via that IP, by just 10%. Goofy wording, but you get the idea.) This is an area where those most vulnerable to phishing or forging (eg financial institutions, eBay, eCommerce sites etc) could help. If they were to always send mail from their own (non-shared) servers, which are identifiable as theirs in domain name, rnds and whois (on the IP address), it would make it much easier for the recipient systems to apply checks. If the PRA and reverse path say it comes from accounts@bigbank.com, the EHLO and rDNS of the connecting IP are mailserver.bigbank.com then it is much easier to assign trust than if the EHLO and rDNS are mailer3.outsourcingcompany.com. I have received (genuine) emails from financial institutions and retailers (who have both bricks and mortar and online sales) which have been sent 'on their behalf' by public relations companies. I think using third parties to send such emails is not helping at all in the fight against phishing. So the solutions are not just technical, the senders who want a good reputation will have to adopt safe procedures as well. From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 01:56: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 BAA06512 for ; Fri, 13 Aug 2004 01: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 i7D5gXE3079646; Thu, 12 Aug 2004 22:42:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D5gXPh079645; Thu, 12 Aug 2004 22:42:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D5gWXh079634 for ; Thu, 12 Aug 2004 22:42:32 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2004 22:45:11 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7D5gSIZ025622; Thu, 12 Aug 2004 22:42:28 -0700 (PDT) Received: from fenton-w2k01.cisco.com (stealth-10-32-245-99.cisco.com [10.32.245.99]) by imail.cisco.com (8.12.5/8.12.10) with SMTP id i7D6FJkZ028570; Thu, 12 Aug 2004 23:15:20 -0700 Message-Id: <4.3.2.7.2.20040812213202.04052ec0@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Aug 2004 22:33:02 -0700 To: "Gordon Fecyk" , "Michael R. Brumm" , "william(at)elan.net" , From: Jim Fenton Subject: RE: Additional security consideration for marid-core In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553DE@srv1.pan-am.ca> 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:"1092377722.738723"; x:"432000"; a:"rsa-sha1"; b:"0:3875"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"BMuDM70Yls3sOUbrLI0BMNLHsPdUYNgt2t22zKLStf239LzVb25ERxzSrOsaz" "6hVnNKA1HVKQ/3SkXRjxi1KskYJ6gzREM+0XP0kOMgCiYrnccXgxV0p/mBPT2" "quZycKuetm6HvjwdAAv97l3CHW4yD7sNJccL8sFwa69925pi4="; c:"Date: Thu, 12 Aug 2004 22:33:02 -0700"; c:"From: Jim Fenton "; c:"Subject: RE: Additional security consideration for marid-core" 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: Responding to a few messages with one message: At 04:23 AM 8/12/2004 -0500, Gordon Fecyk wrote: >> I have been >> rather concerned that authorization based on IP address will >> push them in the direction of these sorts of attacks on IP >> address space, which is a place where none of us would like >> to see them go. > >As if this hasn't been done before. > >ISPs have been authorizing mail relay based on IP for seven years now. And >k1dd13z were supposedly attacking IRC and other TCP-based networks for at >least as long. I'm not convinced there are attacks they already haven't >tried. Agreed that these aren't new attacks. What's new is the additional motivation to launch such an attack. At 11:31 AM 8/12/2004 -0600, Michael R. Brumm wrote: >Jim Fenton wrote: >>Such an attack might occur if the attacker obtained access to a >>router which participates in external BGP routing. Such a router >>could advertise a more specific route to a rogue SMTP client, >>temporarily overriding the legitimate owner of the address. > >At that point, much larger attacks can be done. For example, DNS queries for >reputable domains could be redirected to a spammers DNS server which replies >with a MARID record authorizing the IP addresses of zombies. This would >allow the attacker to basically hijack the reputable domains and send out >spam to everyone. I'm under the impression that these attacks would be fairly short-lived, so redirection of DNS would be possible but DNS caches would mitigate that threat (not sure to what extent). But a short-lived attack misappropriating one of the outgoing mail server addresses would allow the attacker to send messages from that domain and have them verify correctly, since that is done as the message is received. >Note that although the attack scenario I mentioned above is different from >the one mentioned in section 6.1, it too would be solved by DNSSEC (at least >that is my understanding). Redirection of the DNS server would be solved by DNSSEC, but redirection of the outgoing email server's address would not. At 11:50 PM 8/11/2004 -0700, william(at)elan.net wrote: >It not an easy thing to achieve for somebody to try to use somebody elses >(otherwise already actively used) ip space, this will be quickly discovered >and tracked to the source ASN doing the announcement. Just having hacked >access to bgp router is also not enough, you need to actually have prior >authorization with upstream, which it itself will usually require access >to email account of isp or organization attacker is trying to appear as. >And if somebody does have hacked access to large enough bgp router they >could actualy do a lot lot worth things then just spam or phishing >(routers are worth quite a bit on the black market, on the order of >1:10,000 or more what zombie is worth). In a world where authorization to use a given PRA is under control, the opportunity for a phisher to send messages as .com is probably quite lucrative. >Now it is not exactly that I'm saying its not a threat or that it can not >happen (it probably will), but there are a easier means to achieve similar >result, like using zombies or if access to particular net is desired hacking >computer on that net. But if others do really feel like this should be >included as possible threat, my opinion is that first paragraph is all >that should be included and is enough (lets not give a spammer who have read >the document any ideas about hacking bgp routers, as you so allegantly put >at the end it this "is a place where none of us would like to see them go"). I thought a lot before I wrote what I did. I believe we aren't teaching the bad guys any new tricks here, any more than we are in the section about TCP sequence number attacks. -Jim From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 03:20: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 DAA24400 for ; Fri, 13 Aug 2004 03:20: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 i7D6uJjC087147; Thu, 12 Aug 2004 23:56: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 i7D6uJNl087146; Thu, 12 Aug 2004 23:56:19 -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 i7D6uItq087139 for ; Thu, 12 Aug 2004 23:56:18 -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 4546E132DD7; Fri, 13 Aug 2004 02:59:55 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 3B7FC633; Fri, 13 Aug 2004 02:56:04 -0400 (EDT) Date: Fri, 13 Aug 2004 02:56:04 -0400 From: Meng Weng Wong To: Mark Lentczner Cc: IETF MARID WG Subject: Re: What Meng said Message-ID: <20040813065604.GI28401@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with everything Mark says, so I must have communicated my position poorly :) If I could have one more chance to explain my thinking, let's cut to the chase: On Wed, Aug 11, 2004 at 02:38:38PM -0700, Mark Lentczner wrote: | else client supplies just Mail From { | r2 = check MAIL FROM against its Sender-ID record (hoping it will | be same as PRA) | | accept body of message | extract PRA from headers | if PRA == MAIL FROM { exit with r2 } | | r3 = check PRA against its Sender-ID record | exit with r3 | } I agree that this is how Sender ID should work. My question is: can you reject if the r2 result is FAIL? I think you can. Here's why. The forwarding scenario is, of course, our weak link. Under SPF Classic, noncompliant forwarders who didn't do SRS could expect to get their mail rejected. Under Sender ID, noncompliant forwarders who don't prepend a Resent-From header could expect to get their mail rejected. Under Sender ID, noncompliant forwarders who don't offer a SUBMITTER parameter could expect to get their mail rejected. In all cases, noncompliant forwarders get their mail rejected. Therefore, immediately rejecting after MAIL if (the SUBMITTER value is not provided and r2 is FAIL), is no worse than continuing to accept the message and extracting the PRA, because the PRA can be expected to fail anyway if it's forwarding. This means that we *can* safely assume, in the absence of SUBMITTER, that MAIL-FROM == PRA, whether or not we think the sender is omitting it because 1) they are not Sender-ID aware, or 2) they are aware and Mail-From == PRA. If we do this, then the essential requirements of the SPF Classic community are respected in Sender ID. I do not think this course of action harms the essential requirements of Caller ID so why not make both sides happy? Back to the algorithm: | else client supplies just Mail From { | r2 = check MAIL FROM against its Sender-ID record (hoping it will | be same as PRA) so, if the r2 is FAIL, reject. if the r2 is PASS, proceed. | accept body of message | extract PRA from headers | if PRA == MAIL FROM { exit with r2 } | | r3 = check PRA against its Sender-ID record | exit with r3 | } the important requirement for me is being able to, when SUBMITTER is absent, reject based on a MAIL FROM fail result, and being able to, when SUBMITTER is absent, accept based on a MAIL FROM pass result. If course if SUBMITTER is provided that overrides the return-path, but i really would like to be able to avoid going into the headers upon FAIL. If the result is a PASS then going into the headers is fine by me; we would then check that the PRA either matches the MAIL FROM or passes an SPF check directly. (non-SUBMITTER compliant VERP mailing lists with Sender: owner-listname are a good case where PRA != MAIL-FROM but spf_check(PRA) == PASS == spf_check(MAIL-FROM)). perhaps some data can tell whether such an algorithm would be more or less prone to error in the field. From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 03:34: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 DAA24942 for ; Fri, 13 Aug 2004 03:34:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D7FGiD089139; Fri, 13 Aug 2004 00:15:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D7FG7N089138; Fri, 13 Aug 2004 00:15:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D7FFJv089128 for ; Fri, 13 Aug 2004 00:15:16 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7D7F177009096 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 13 Aug 2004 03:15:03 -0400 Subject: Re: 'Recognized' mailing lists, RE: What Meng said From: Mark Shewmaker To: Michel Bouissou Cc: ietf-mxcomp@imc.org In-Reply-To: <45279.127.0.0.1.1092271751.squirrel@127.0.0.1> References: <700EEF5641B7E247AC1C9B82C05D125D0553D0@srv1.pan-am.ca> <1092271010.18780.979.camel@localhost.localdomain> <45279.127.0.0.1.1092271751.squirrel@127.0.0.1> Content-Type: text/plain Message-Id: <1092381517.15747.1297.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 13 Aug 2004 03:18:38 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Fri, 13 Aug 2004 03:15:03 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-11 at 20:49, Michel Bouissou wrote: > Some put: > List-ID: > ...but some put: > List-ID: > Ohoho... And some even put: > List-ID: Long description without quotes or anything > > Uh... Too bad. The PRA algorithm will really need to be smart ;-) Just look inside the <>'s. The algorithm would just have to drop any assumptions that PRAs have to have local-parts. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 11:48:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24040 for ; Fri, 13 Aug 2004 11:48: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 i7DFLxMd026566; Fri, 13 Aug 2004 08:21: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 i7DFLxIM026565; Fri, 13 Aug 2004 08:21:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from knecht.Neophilic.COM (dsl081-247-036.sfo1.dsl.speakeasy.net [64.81.247.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFLwWn026556 for ; Fri, 13 Aug 2004 08:21:58 -0700 (PDT) (envelope-from eric@sendmail.com) Received: from [10.0.1.100] ([10.0.0.2]) by knecht.Neophilic.COM (8.12.11/8.13.0.PreAlpha0) with ESMTP id i7DFLfFu079728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Aug 2004 08:21:48 -0700 (PDT) Date: Thu, 12 Aug 2004 17:15:45 -0700 From: Eric Allman To: ned.freed@mrochek.com cc: Harry Katz , IETF MARID List Subject: Re: Changes in the queue for marid-submitter-03 Message-ID: In-Reply-To: <01LDJQ33K4PS00005R@mauve.mrochek.com> References: <01LDJQ33K4PS00005R@mauve.mrochek.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on knecht.sendmail.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Wednesday, August 11, 2004 6:14 PM -0700 ned.freed@mrochek.com wrote: [regarding section 4.1] | I'm also not comfortable with the bit about modifying the RFC 2822 | header to match the SUBMITTER field. I understand the rationale for | having this, but I think giving license to piddle with the headers | to an SMTP client goes a bit too far. How about saying that the | SMTP client can only do this sort of thing if the SUBMITTER value | on hand is found not to match the header and the SUBMITTER value is | known to be more "accurate" than what's in the header. If the | header is more definitive, the right thing to do is set the | SUBMITTER to match it, not the other way around. Ned, I don't see where it says this -- in fact, it seems to say the opposite (the SUBMITTER must match the RFC 2822 header). It does say that the _clients_ (not the SMTP servers) MUST make sure they match by adding a 2822 header if necessary, and that servers SHOULD verify that the SUBMITTER matches the PRA from the header (section 4.2). eric From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 11:49: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 LAA24196 for ; Fri, 13 Aug 2004 11:49:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFUEoM027256; Fri, 13 Aug 2004 08:30: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 i7DFUELF027255; Fri, 13 Aug 2004 08:30:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ddg.com (mail.ddg.com [66.93.83.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFUCEf027244 for ; Fri, 13 Aug 2004 08:30:13 -0700 (PDT) (envelope-from awd@DDG.com) Received: from [192.168.1.35] (account awd HELO [192.168.1.35]) by ddg.com (CommuniGate Pro SMTP 4.2) with ESMTP id 1472284; Fri, 13 Aug 2004 10:30:10 -0500 In-Reply-To: <20040813065604.GI28401@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/alternative; boundary=Apple-Mail-3-287175174 Message-Id: Cc: Mark Lentczner , Meng Weng Wong From: "Andrew W. Donoho" Subject: Re: What Meng said Date: Fri, 13 Aug 2004 10:30:08 -0500 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3-287175174 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Meng and MARID Community, On Aug 13, 2004, at 01:56, Meng Weng Wong wrote: > Therefore, immediately rejecting after MAIL if (the > SUBMITTER value is not provided and r2 is FAIL), is no worse > than continuing to accept the message and extracting the > PRA, because the PRA can be expected to fail anyway if it's > forwarding. > > This means that we *can* safely assume, > in the absence of SUBMITTER, that MAIL-FROM == PRA, > whether or not we think the sender is omitting it because > 1) they are not Sender-ID aware, or > 2) they are aware and Mail-From == PRA. > > If we do this, then the essential requirements of the SPF > Classic community are respected in Sender ID. > > I do not think this course of action harms the essential > requirements of Caller ID so why not make both sides happy? As a new participant who attened the MARID F2F, I would like to suggest that Meng's interpretation should be cast in the Sender-ID specification. It currently is not. Judging by Mr. Lyon's (jimbo, jimlyon@exchange.microsoft.com) comments, he has a very different interpretation and expects Meng's Mail-From checking to occur some time in the vague future, if at all. This does not sound like the parties to the merging of the SPF and Caller-ID specs have the same interpretation. Because premature marketing activities are being introduced today before the Sender-ID spec is finalized nor the IPR issues determined, there is a very real chance that marketing may overwhelm the standards process. We should tread carefully here. The rush to specification for Sender-ID seems ill advised. The SPF community has some operational experience with the effectiveness of Mail-From checking. (I volunteered to work with the SMTP-Verify group in ASRG to document this experience. Please join me and help perform this important test of engineering assertions.) Furthermore, because Mail-From checking is conceptually simple, it offers implementation simplicity and a good method to harden the mapping between domain names and IP addresses for email. It is not the only solution. At the MARID meeting, I encouraged this community that if they were willing to extend SMTP with SUBMITTER then they should, at the same time, consider tightening up HELO/EHLO checking. From this list, Meng has also proposed that we eliminate sending to non-MX advertised hosts. Both of these issues should be considered before embracing the addition of new tags. Perhaps an ESMTP extension, say STRICT, could be used to announce both support of and adherence to HELO/EHLO checking and only sending to MX advertised hosts. (As I am, obviously, not an SMTP expert, I encourage others to make a real proposal.) I am just identifying that these loose interpretations of the SMTP spec have contributed to the abuse of the email system. Shouldn't we try to close those holes and exploit DNS as an important "third party" identifier/authenticator service to improve email? I am saying that simple mechanisms without IPR encumbrances should be exploited by this community. SPF-Classic and some form of stricter SMTP checking meet this criterion. The PRA and other mechanisms may offer value but, because of their complexity, should be deferred until these simpler mechanism's specifications are finalized. As the difference between Mr. Wong's and Mr. Lyon's interpretation of the Sender-ID spec shows, there is still some important conceptual work to be done here. A rush to deploy a complex implementation that may not have the desired anti-spam/anti-phishing effect is not good engineering practice. In other words, while we have an extremely rough consensus, the running code may not actually solve the identification problem. We should look to simplify and refine our solution. Andrew ____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-3-287175174 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Meng and MARID Community, On Aug 13, 2004, at 01:56, Meng Weng Wong wrote: Therefore, immediately rejecting after MAIL if (the SUBMITTER value is not provided and r2 is FAIL), is no worse than continuing to accept the message and extracting the PRA, because the PRA can be expected to fail anyway if it's forwarding. This means that we *can* safely assume, in the absence of SUBMITTER, that MAIL-FROM == PRA, whether or not we think the sender is omitting it because 1) they are not Sender-ID aware, or 2) they are aware and Mail-From == PRA. If we do this, then the essential requirements of the SPF Classic community are respected in Sender ID. I do not think this course of action harms the essential requirements of Caller ID so why not make both sides happy? As a new participant who attened the MARID F2F, I would like to suggest that Meng's interpretation should be cast in the Sender-ID specification. It currently is not. Judging by Mr. Lyon's (jimbo, jimlyon@exchange.microsoft.com) comments, he has a very different interpretation and expects Meng's Mail-From checking to occur some time in the vague future, if at all. This does not sound like the parties to the merging of the SPF and Caller-ID specs have the same interpretation. Because premature marketing activities are being introduced today before the Sender-ID spec is finalized nor the IPR issues determined, there is a very real chance that marketing may overwhelm the standards process. We should tread carefully here. The rush to specification for Sender-ID seems ill advised. The SPF community has some operational experience with the effectiveness of Mail-From checking. (I volunteered to work with the SMTP-Verify group in ASRG to document this experience. Please join me and help perform this important test of engineering assertions.) Furthermore, because Mail-From checking is conceptually simple, it offers implementation simplicity and a good method to harden the mapping between domain names and IP addresses for email. It is not the only solution. At the MARID meeting, I encouraged this community that if they were willing to extend SMTP with SUBMITTER then they should, at the same time, consider tightening up HELO/EHLO checking. From this list, Meng has also proposed that we eliminate sending to non-MX advertised hosts. Both of these issues should be considered before embracing the addition of new tags. Perhaps an ESMTP extension, say STRICT, could be used to announce both support of and adherence to HELO/EHLO checking and only sending to MX advertised hosts. (As I am, obviously, not an SMTP expert, I encourage others to make a real proposal.) I am just identifying that these loose interpretations of the SMTP spec have contributed to the abuse of the email system. Shouldn't we try to close those holes and exploit DNS as an important "third party" identifier/authenticator service to improve email? I am saying that simple mechanisms without IPR encumbrances should be exploited by this community. SPF-Classic and some form of stricter SMTP checking meet this criterion. The PRA and other mechanisms may offer value but, because of their complexity, should be deferred until these simpler mechanism's specifications are finalized. As the difference between Mr. Wong's and Mr. Lyon's interpretation of the Sender-ID spec shows, there is still some important conceptual work to be done here. A rush to deploy a complex implementation that may not have the desired anti-spam/anti-phishing effect is not good engineering practice. In other words, while we have an extremely rough consensus, the running code may not actually solve the identification problem. We should look to simplify and refine our solution. Andrew Helvetica____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-3-287175174-- From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 12:04:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25223 for ; Fri, 13 Aug 2004 12:04: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 i7DFgbHP029320; Fri, 13 Aug 2004 08:42: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 i7DFgbEN029319; Fri, 13 Aug 2004 08:42:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFgafA029311 for ; Fri, 13 Aug 2004 08:42:37 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LDJXAYEIIO00005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Fri, 13 Aug 2004 08:42:36 -0700 (PDT) Date: Fri, 13 Aug 2004 08:33:10 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Changes in the queue for marid-submitter-03 In-reply-to: "Your message dated Thu, 12 Aug 2004 17:15:45 -0700" To: Eric Allman Cc: ned.freed@mrochek.com, Harry Katz , IETF MARID List Message-id: <01LDLYHA86JQ00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <01LDJQ33K4PS00005R@mauve.mrochek.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > --On Wednesday, August 11, 2004 6:14 PM -0700 ned.freed@mrochek.com > wrote: > [regarding section 4.1] > | I'm also not comfortable with the bit about modifying the RFC 2822 > | header to match the SUBMITTER field. I understand the rationale for > | having this, but I think giving license to piddle with the headers > | to an SMTP client goes a bit too far. How about saying that the > | SMTP client can only do this sort of thing if the SUBMITTER value > | on hand is found not to match the header and the SUBMITTER value is > | known to be more "accurate" than what's in the header. If the > | header is more definitive, the right thing to do is set the > | SUBMITTER to match it, not the other way around. > Ned, I don't see where it says this -- in fact, it seems to say the > opposite (the SUBMITTER must match the RFC 2822 header). The last paragraph of section 4.1: 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. This gives a pretty explicit license to modify the header to all SMTP clients IMO. > It does say > that the _clients_ (not the SMTP servers) MUST make sure they match > by adding a 2822 header if necessary, and that servers SHOULD verify > that the SUBMITTER matches the PRA from the header (section 4.2). Which is exactly what I said. Note my use of the term "SMTP client", not once but twice. I note, however, that the distinction between the actions taken by the SMTP client and server on a relay MTA is blurry at best. I guess another way to address this would be to only allow this during initial submission. But I worry that this doesn't catch the intended case for this action. The real concern is that we don't want relay MTAs making MARID "work" by blithely patching the header to match the SUBMITTER value they received. The reasons why this would be bad should be obvious. Ned From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 12:40: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 MAA27603 for ; Fri, 13 Aug 2004 12:40: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 i7DGIWI9033269; Fri, 13 Aug 2004 09:18: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 i7DGIW6g033268; Fri, 13 Aug 2004 09:18:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from knecht.Neophilic.COM (dsl081-247-036.sfo1.dsl.speakeasy.net [64.81.247.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGIVBm033258 for ; Fri, 13 Aug 2004 09:18:31 -0700 (PDT) (envelope-from eric@sendmail.com) Received: from [10.0.2.36] (knecht.Sendmail.ORG [10.0.2.36] (may be forged)) by knecht.Neophilic.COM (8.12.11/8.13.0.PreAlpha0) with ESMTP id i7DGIRFv080864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2004 09:18:27 -0700 (PDT) Date: Fri, 13 Aug 2004 09:18:27 -0700 From: Eric Allman To: ned.freed@mrochek.com cc: Harry Katz , IETF MARID List Subject: Re: Changes in the queue for marid-submitter-03 Message-ID: In-Reply-To: <01LDLYHA86JQ00005R@mauve.mrochek.com> References: <01LDJQ33K4PS00005R@mauve.mrochek.com> <01LDLYHA86JQ00005R@mauve.mrochek.com> X-Mailer: Mulberry/3.1.5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on knecht.sendmail.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit OK, I think I understand what you're getting at now. It's clear to me that _mail_ clients (in this case, either an MUA, a SUBMISSION server, or a forwarder) needs to be prepared to modify the header. But clearly a vanilla MTA can't do this, because to do so would break the underlying assumption that SUBMITTER must reflect the header; if you changed the header to match SUBMITTER then there would be nothing to prevent forgery. The intended behavior is described in section 4.2. I think Harry is thinking in terms of dropping that paragraph entirely since it arguably belongs in a different draft. eric --On Friday, August 13, 2004 08:33:10 -0700 ned.freed@mrochek.com wrote: | | > --On Wednesday, August 11, 2004 6:14 PM -0700 | > ned.freed@mrochek.com wrote: | > [regarding section 4.1] | > | I'm also not comfortable with the bit about modifying the RFC | > | 2822 header to match the SUBMITTER field. I understand the | > | rationale for having this, but I think giving license to piddle | > | with the headers to an SMTP client goes a bit too far. How | > | about saying that the SMTP client can only do this sort of | > | thing if the SUBMITTER value on hand is found not to match the | > | header and the SUBMITTER value is known to be more "accurate" | > | than what's in the header. If the header is more definitive, | > | the right thing to do is set the SUBMITTER to match it, not the | > | other way around. | | > Ned, I don't see where it says this -- in fact, it seems to say | > the opposite (the SUBMITTER must match the RFC 2822 header). | | The last paragraph of section 4.1: | | 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. | | This gives a pretty explicit license to modify the header to all | SMTP clients | IMO. | | > It does say | > that the _clients_ (not the SMTP servers) MUST make sure they | > match by adding a 2822 header if necessary, and that servers | > SHOULD verify that the SUBMITTER matches the PRA from the header | > (section 4.2). | | Which is exactly what I said. Note my use of the term "SMTP | client", not once | but twice. I note, however, that the distinction between the | actions taken by | the SMTP client and server on a relay MTA is blurry at best. | | I guess another way to address this would be to only allow this | during initial | submission. But I worry that this doesn't catch the intended case | for this | action. | | The real concern is that we don't want relay MTAs making MARID | "work" by | blithely patching the header to match the SUBMITTER value they | received. The | reasons why this would be bad should be obvious. | | Ned | | From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 12:44: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 MAA27846 for ; Fri, 13 Aug 2004 12:44:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGCsVr032868; Fri, 13 Aug 2004 09:12: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 i7DGCsB2032867; Fri, 13 Aug 2004 09:12: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 i7DGCrnL032859 for ; Fri, 13 Aug 2004 09:12:54 -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 i7DGCYj24508; Fri, 13 Aug 2004 09:12:34 -0700 Date: Fri, 13 Aug 2004 09:12:30 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <173466849.20040813091230@brandenburg.com> To: ned.freed@mrochek.com CC: Harry Katz , IETF MARID List , Subject: Re: Changes in the queue for marid-submitter-03 In-Reply-To: <01LDJQ33K4PS00005R@mauve.mrochek.com> References: <01LDJQ33K4PS00005R@mauve.mrochek.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 Folks, >> Section 4.1 : clean up terminolgy referring to an "emtpy" MAIL FROM to >> use the RFC 2821 term "null reverse-path" nfmc> I'd be tempted to go even further and make it mandatory for SUBMITTER= to be nfmc> used regardless of whether or not it matches the MAIL FROM. I strongly urge that this change be made. It simplifies the algorithm and eliminates an ambiguity that Meng cited. nfmc> I'm also not comfortable with the bit about modifying the RFC 2822 header to nfmc> match the SUBMITTER field. I understand the rationale for having this, but I nfmc> think giving license to piddle with the headers to an SMTP client goes a bit nfmc> too far. right. nfmc> How about saying that the SMTP client can only do this sort of thing nfmc> if the SUBMITTER value on hand is found not to match the header and the nfmc> SUBMITTER value is known to be more "accurate" than what's in the header. I am trying to imagine a situation in which a random SMTP client would satisfy these criteria. My concern is that the restrictions will be less important than the fact that there is language giving smtp clients permission to make the change. Since the restrictions are necessarily worded vaguely, any client smtp operator wishing to make the changes will claim that they satisfied the criteria. nfmc> If nfmc> the header is more definitive, the right thing to do is set the SUBMITTER to nfmc> match it, not the other way around. Currently, SMTP relays do not alter the contents of RCPT-TO or MAILFROM, other than using subsets of Rcpt-to. MTAs should not go around changing Submitter. If submitter is set wrong, then the message should be rejected. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 13: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 NAA00633 for ; Fri, 13 Aug 2004 13: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 i7DH8HIK039113; Fri, 13 Aug 2004 10:08: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 i7DH8HXD039112; Fri, 13 Aug 2004 10:08:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DH8H8q039106 for ; Fri, 13 Aug 2004 10:08:17 -0700 (PDT) (envelope-from csg@habeas.com) Received: from user-1121dgb.dsl.mindspring.com ([66.32.182.11] helo=[192.168.147.5]) by mallard.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BvfXQ-0003UT-00; Fri, 13 Aug 2004 10:08:20 -0700 Message-ID: <411CF4EE.4020006@habeas.com> Date: Fri, 13 Aug 2004 10:05:50 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: What Meng said References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew W. Donoho wrote: > .... there is a very real chance that marketing may overwhelm the > standards process. We should tread carefully here. The rush to > specification for Sender-ID seems ill advised. > > ... The PRA and other mechanisms may offer value but, because of their > complexity, should be deferred until these simpler mechanism's > specifications are finalized. Thank you for the most rational and sensible post I've seen on this list in the past two months. Please, folks, can we pick some of the low-hanging fruit first? Incidentally, Andrew, I tried to reply to you directly, but your SPF check bounces my mail. It does not appear that there is any way for me to send E-mail to you from any of my legitimate accounts. From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 13:49:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01579 for ; Fri, 13 Aug 2004 13:49: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 i7DHWEmA041926; Fri, 13 Aug 2004 10: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 i7DHWE1x041925; Fri, 13 Aug 2004 10:32:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHWDf1041918 for ; Fri, 13 Aug 2004 10:32:13 -0700 (PDT) (envelope-from csg@habeas.com) Received: from user-1121dgb.dsl.mindspring.com ([66.32.182.11] helo=[192.168.147.5]) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Bvfua-0002fR-00; Fri, 13 Aug 2004 10:32:16 -0700 Message-ID: <411CFA8B.4020905@habeas.com> Date: Fri, 13 Aug 2004 10:29:47 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: What Meng said References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <411CF4EE.4020006@habeas.com> In-Reply-To: <411CF4EE.4020006@habeas.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I wrote: > Incidentally, Andrew, I tried to reply to you directly, but your SPF > check bounces my mail. It does not appear that there is any way for me > to send E-mail to you from any of my legitimate accounts. Sending to the whole list because I implied here Andrew was doing something wrong. (*BLUSH*) My bad Andrew. The habeas.com SPF record is doing exactly what it's supposed to do, blocking anyone from sending E-mail with a MAIL FROM of habeas.com if it isn't sent out via the Habeas MX host. I really don't think that our IT guy realized the consequences for those of us who mostly work remotely, but that's certainly not your problem. From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 14:29: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 OAA03523 for ; Fri, 13 Aug 2004 14:29: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 i7DHuwuZ044117; Fri, 13 Aug 2004 10:56:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHuw53044116; Fri, 13 Aug 2004 10:56:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHuwDc044110 for ; Fri, 13 Aug 2004 10:56:58 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id A73C5414B5; Fri, 13 Aug 2004 10:57:01 -0700 (PDT) Subject: RE: Does marid-submitter-02 really make sense? From: Douglas Otis To: Mark Shewmaker Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092368581.3295.1289.camel@localhost.localdomain> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> <1092361125.7627.196.camel@ddev.mail-abuse.org> <1092368581.3295.1289.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1092419820.8257.100.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 13 Aug 2004 10:57:00 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-12 at 20:43, Mark Shewmaker wrote: > On Thu, 2004-08-12 at 21:38, Douglas Otis wrote: > > On Thu, 2004-08-12 at 15:59, Mark Shewmaker wrote: > > > On Thu, 2004-08-12 at 13:09, Douglas Otis wrote: > > > Sure it does--use a competent mail service provider. > > > > I do not understand why you see a network service provider monitoring > > outbound mail as being incompetent. > > I never said anything like that. (At least I hope I didn't.) > > (Although with Unified-SPF, I would expect to look forward to a day in > which ISPs can safely remove outbound mail blocks at residential > addresses. Separate issue though.) The method I was referring to does not block port 25, instead it redirects the destination. Some home access providers do block port 25 out-right to curtail Trojans, but I was not referring to that. > > By isolating to the Sender-ID, which may be a small percentage of the > > traffic traveling through a shared MTA, even should the provider be > > extremely diligent, this domain may become exploited. > > Then if the shared MTA is exploited, then domain's reputation will > suffer, even if the domain didn't actually intend to be a victim. This would be under the impression that Sender-ID could be used for repudiations. > That's simply the way things are. Not yet. > People will not think as highly of that PRA afterward, for some amount > of time at least, and won't put as much trust in their claims. This leaves those harmed, but not committing a wrong, the only recourse but to sue the repudiation service for their incompetence in considering Sender-ID a suitable identifier for the purpose of repudiation. > People will alter their opinions. I'm sorry if that bothers you. As a result, expect the amount of abuse to increase and repudiation services to suffer by the onslaught of errors. > Now, if the PRA tries to start suing people who have started to think > less highly of his purported claims, then yes, I think that's unfair and > uncivilized behavior on the PRA's part. > > I don't believe in thought crimes. Blocking mail is not a thought. > > It is not the same problem as checking the host by IP. The IP > > properly identifies the mail stream. If there is an error that > > blocks such a shared MTA by IP, the problem will be corrected > > quickly. Sender-ID allows the domain to be exploited, isolated, > > blocked, and ignored. Ouch. > > Yeah--ouch! > > I can only conclude that people who put themselves in such a vulnerable > position are likely to quickly correct the problem when their > vulnerabilities are exploited--after which their reputation should > improve. Sender-ID puts them in a vulnerable position. Their activities were responsible, the network providers activities were very responsible and abuse was being abated. Now, with Sender-ID, the abuse CAN NOT be abated. : ( > Or they'll go out of business. There is a high cost for spam where much of this is seen by the network provider. Taking away tools to curtail this abuse is not a good solution and can drive providers out of business. > Or they'll go to the courts, at which point I can only hope that their > reputation would plummet. (I for one try to avoid doing business with > companies like that--companies that won't admit, stand behind, and > correct their problems.) It will be repudiation services using Sender-ID to base their assessments, not the network providers doing their best to abate the abuse damaging their services. > > > I don't know what "transparent interception techniques" you're talking > > > about. > > > > Some network providers have their routers redirect the destination > > address for port 25 connections to their SMTP server to monitor the > > traffic. This is a competent and effective means to quickly identify > > and remove egregious abuse by checking SMTP error logs. Sender-ID could > > fully validate for the wrong party however. > > Oh-okay. > > Well, if it could fully validate for the wrong party, then either the > MSP is allowing cross-customer forgeries, or the purported sending > domain has their SPF records set up poorly. (Or both.) What restrictions are there with respect to PRAs currently? Providers can't even assess the PRA without first signing a contract with Microsoft. The SPF records must include the shared MTA, if to be set up correctly according to both SPF and Sender-ID. This sharing may not be apparent to the recipient. > > > > Sender-ID does not stop phishing, > > > > > > Well, sender_agents would help in the phishing area. :-) > > > > Something like Identified Internet Mail would help. I don't know what > > you mean by sender-agents. Do you mean a Certificate Authority? > > It's a modifier I've been pushing for a few months as a way to get > SenderID to fully address the phishing problem, to little avail > unfortunately. > > (I'm frustrated at my inability to stir up interest so far, as IMHO > sender_agents would make SenderID *FAR* more useful.) > > See: http://www.imc.org/ietf-mxcomp/mail-archive/msg03112.html > I see. Identified Internet Mail seems a much cleaner solution. > > > > > Obviously, domains whose outgoing MTA service is an MTA that allows > > > > > cross-customer forgeries will likely suffer in reputation. > > > > > > > > Reputations based upon Sender-ID would never point to their servers as > > > > being at fault. Here lies the rub. Sender-ID can not be trusted, and > > > > yet the party at fault can not be identified. > > > > > > Why can Sender-ID not be trusted in this context? > > > > The identity will always be in question when over a shared MTA. The > > danger is the inevitable law suit, if the wrong party is identified and > > hammered by this mistake. > > Sorry--if my reputation system makes me give a poor reputation to > someone because they're using a shared MTA that allows cross-customer > forgeries, then my reputation system is doing it's job. Explain that in court. The provider guarding against abuse does not examine or change the content of the mail, they look for protocol generated errors. Sender-ID repudiation makes the false assumption there is a one-to-one association of sender to mail channel in ALL cases. Sender-ID repudiation makes the false assumption that the identification has been accurately validated. > I simply won't think highly of people who willingly expose themselves to > such vulnerabilities. It's unfortunate if I can be prosecuted for such > a thought crime. Blocking mail is not a thought crime. > > > There are multiple measures of reputation involved here--the one I > > > thought we were talking about here is whether you could trust claims > > > purportedly made by a given PRA. That's quite a different thing from > > > whether they're a "miscreant" by any other measure. > > > > The PRA can not be trusted. The PRA can not be used to identify > > miscreants. > > > The miscreant may be spoofing as > > trustworthy@trustworthy.com and pass with flying colors. > > If someone else can spoof trustworthy@trustworthy.com, then I hope my > reputation systems will assign a poor reputation to the trustworthy.com > domain, because any claims of anyone to be from there aren't, well, > trustworthy. The question should be, do you blame the mail system allowing mail to share MTA servers as designed, or do you blame repudiation services for not considering such cases. > The fact that trustworthy@trustworthy.com tells me to trust that a > message really comes from him if it comes through a specific IP still > doesn't mean I should trust such claims if I know that that specific IP > itself isn't trustworthy. Mail providers MUST NOT use Sender-ID when they can not ensure a ONE-TO-ONE relationship between Domain and Server. The draft should make this warning very clear, but it does not. > (Ie, if trustworthy is a friend of mine who I happen to trust 100%, and > he trusts a specific IP 100%, but I only trust it 10%, then I should > only trust messages from through that IP, where I can only authenticate > via that IP, by just 10%. Goofy wording, but you get the idea.) Either mail gets accepted or rejected. There tends to be a binary relationship with this decision, but the integrity of the system ensures the sender knows of this. If you filter mail into folders, then there will be mail stuck into rat-hole folders where your friend wonders why you did not see their message. > > If you wish to have a basis for repudiation, start with an identity that > > can better trusted. How about > > trustworthy@trustworthy.com:mx01.really-big-isp.com where the > > authenticated EHLO domain becomes part of the identity. To process this, > > mask the sub-domain of the EHLO response. > > That makes sense, except for the EHLO bit, (getting people to give > honest EHLO strings is going to be another herculean effort, GRRR), > but..the real reason I wasn't pushing for that level of things is that I > don't expect people who report problems to, on the whole, be able to > reliably report the sending EHLO domain or even IP. That was the concept behind CSV. The incentive would be name based accreditation that helps avoid these filter rat-holes. It would not step upon the isolated domain, nor depend upon everyone giving up their preferred email address when obtaining access from differing locations. It should prove more reliable than a PRA, especially when there are a few dozen headers that may contain such information, but only a single EHLO domain. It does not require a Microsoft contract, and it does allow a safe means of repudiation or accreditation. > Plus--I expect that people will move to more trustworthy MSP's that > don't allow cross-customer-forgeries, so I'm guessing that that level of > resolution will not only become unnecessary, but end up being too much > work for people to be willing to bother with. It seems Sender-ID reduces the choices but then ignores policies of the providers where a reduction in abuse can be made. This will increase the amount of abuse. This will force people into using an increased number of email addresses and make a recipient less able to discern someone they trust from a con. By exposing an authenticated EHLO domain, the con is thwarted without forcing everyone to change their email address to send mail. It is also an identifier that can be safely assessed. > > You are suggesting it is okay to block those that might share an MTA > > server? > > If it's an insecure MTA, yes: Today I block MTA IPs that are known to > be compromised and spewing viruses. There may be trustworthy people > using those IPS--too bad. :-/ > > But I don't see any reason to block mail from a shared MTA that doesn't > allow cross-customer forgeries. Unless they sign a contract with Microsoft, the provider can not assess the identity you wish to protect. Many individuals prefer that this message information not be examined by the mail channel. > But one that does allow those forgeries, and for whom that's become a > practical problem, yeah, I would tend to start wanting to block other > domains using that MTA. (From a practical point of view it's not a > binary thing--some folks would allow a bit and then notice and correct > the problem, and for other's it's a technical possibility but a > practical impossibility to any large extent.) Should there be a list of shared MTAs? Would that be used by some to block mail? Would that result in law suits? It seems this is the question. > > It seems your only defense would be to always use a single recipient > > limit if you refuse to merge a per user white-list. If the cost for that > > feature is enough, you should be able to detect abuse by way of logs to > > make this method of attack rare. > > Yeah. > > And to be fair, if most MTA's switch to using SUBMITTER anyway, then > it's mostly only the forgeries that become expensive. And I guess it's > probably worth the expense there. > > > As I said, BATV ends this without a large adoption. > > No it doesn't. > > BATV and SES only help for domains in which the purported sending domain > participates. If the bounce recipient is eager to see this traffic stop, BATV would be easier than blacklisting legitimate providers that send bounces and then cause themselves worse problems. > > As I said, it seems your only defense would be to always use a single > > recipient limit, if you refuse to merge a per user white-list. It would > > be foolish to expect cooperation if this were an attack. > > Correct. > > > > A receiving MTA that didn't want to check could always just prepend the > > > SUBMITTER in a Resent-From body header, and then MUAs would be able to > > > see what was verified. > > > > I suspect this will be the standard practice used by all providers. > > Prepend a Resent-From to quell support calls. Is this a good practice? > > It's a lazy way for recipient MTAs to operate, against the spec but > somewhat compatible with it as far as end results go, but I hope they > won't *actually* do this. > > > The shortest path would be to stop at the EHLO domain and ask if the > > From is part of that set. > > I don't see how that would help--the server sending the message can be > different from the domain listed in the return path. A name list of the EHLO domains would be a more concise means to make channel assertions about the RFC 2822 From. (The list residing in From DNS.) This should be used as an exception and hopefully, things like Identified Internet Mail would make this choice seem lame. For institutions wishing to protect their trust relationships, then the From and not PRA protection is desired. Not allowing even a forwarded message would seem reasonable for this exceptional case. BATV with a public key may allow an exception for this limitation however. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 14:44: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 OAA04392 for ; Fri, 13 Aug 2004 14:44: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 i7DIOUBg047900; Fri, 13 Aug 2004 11:24: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 i7DIOUrp047899; Fri, 13 Aug 2004 11:24:30 -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 i7DIOTE9047892 for ; Fri, 13 Aug 2004 11:24:29 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040813182430.WRGU1550.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 13 Aug 2004 14:24:30 -0400 From: "John Glube" To: "'Meng Weng Wong'" , "'IETF MARID WG'" Cc: "'Mark Lentczner'" , "'Harry Katz'" , "'Andrew W. Donoho'" Subject: RE: What Meng said Date: Fri, 13 Aug 2004 14:24:03 -0400 Message-ID: <007e01c48162$b7b447c0$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 i7DIOTE9047893 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Meng wrote: >Therefore, immediately rejecting after MAIL if (the >SUBMITTER value is not provided and r2 is FAIL), is no >worse than continuing to accept the message and extracting >the PRA, because the PRA can be expected to fail anyway if >it's forwarding. >This means that we *can* safely assume, in the absence of >SUBMITTER, that MAIL-FROM == PRA, whether or not we think >the sender is omitting it because >1) they are not Sender-ID aware, or >2) they are aware and Mail-From == PRA. >If we do this, then the essential requirements of the SPF >Classic community are respected in Sender ID. >I do not think this course of action harms the essential >requirements of Caller ID so why not make both sides happy? I have two concerns: * Technical - Meng, if we are going to say: MAIL FROM = SUBMITTER Therefore in the absence of SUBMITTER do checks on MAIL FROM Why not: * require malformed SMTP mail from checks as a pre-cursor to avoid spammers from sending IP to recipient MX as was the case in the first US Bank phish? * allow for EHELO/HELO and PTR checks as well? I realize my questions are a bit awkward especially given Andy's previous comments, but if we are going to appease the classic SPF community to solve a problem, why not also appease the unified SPF community? Also, how is the classic SPF or unified SPF community appeased if MS has yet to commit on the license format? (On this point, I acknowledge it was agreed the WG was going to do the engineering work first and then deal with the license issue, depending on the MS proposal, but ...) In other words, from an engineering/design perspective, either: * the Sender-ID design is amended to fully meet the 'social concern' and the 'redundancy design concerns;' and, * MS fully commits on the license issue to meet the concerns of the open source community; or, * don't meet them at all and allow the design to stand as it is, acknowledge that MS is going to file a defensive IPR claim, while requiring a royalty free license in the format it feels appropriate, then everyone can clearly understand exactly what this means and the WG can make an informed decision. (I suspect my comments are a bit pre-mature and if they are, I apologize.) My own view is that: * the design should be amended to fully meet the social and redundancy design concerns. * MS should commit to meet the concerns of the open source community, while protecting its own interests. Meng, I appreciate your position is a compromise. I both respect and applaud your effort. Hopefully something is worked out which keeps the open source and corporate communities in the same tent. If what you propose works, great ... * Implementation/Non technical - This question is for Harry, Sender-ID is going to require some 're-jigging' of message headers. The US Federal Government, Australia and the European Union all have written laws regulating commercial email. All these laws tell people in essence not to use 'deceptive headers.' The US Federal Law in particular has some very specific prohibitions, especially as to what can and cannot go in the from line, etc. Both Australia and the US are in the middle of their process to write specific regulations. In the EU, most nation states have transposed the EU guide. Sender-ID is creating a new identity which did not exist when the Australian, US and EU laws were written. I have particular concerns, especially given some proposed suggestions I have seen involving how ESPs should proceed and whether these are or are not off side with the US Federal law. Has anybody bothered to check to make sure we are not creating the ultimate catch-22? Yes, you can authenticate your identity as a sender, but by complying with the Sender-ID protocol, you put yourself off side with local law. Woops. Harry, could you raise this with the lawyers at MS? I appreciate this may be a 'ghost' concern, but ... Implementation - PR On the PR side, yes, it is disconcerting and in some cases amusing to read a series of PR releases concerning Sender-ID published yesterday and today in the online media in which folks are making all kinds of statements, including one ESP saying "we are Sender-ID compliant," when the draft protocol is not finished and nobody is using Sender-ID in the wild. But ... I am not sure there is much this group can do, unless the WG chairs decide to issue a press release. Given the last brouhaha which occurred after one of the chairs was interviewed ... somehow I suspect silence is the rule of thumb. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 15: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 PAA07679 for ; Fri, 13 Aug 2004 15:13: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 i7DIoHRc051001; Fri, 13 Aug 2004 11:50:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DIoHgk051000; Fri, 13 Aug 2004 11:50:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ddg.com (mail.ddg.com [66.93.83.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DIoG2o050986 for ; Fri, 13 Aug 2004 11:50:16 -0700 (PDT) (envelope-from awd@DDG.com) Received: from [66.93.83.221] (account awd HELO [192.168.1.35]) by ddg.com (CommuniGate Pro SMTP 4.2) with ESMTP id 1472876; Fri, 13 Aug 2004 13:50:14 -0500 In-Reply-To: <411CF4EE.4020006@habeas.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <411CF4EE.4020006@habeas.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/alternative; boundary=Apple-Mail-6-299179966 Message-Id: <9C0060D6-ED59-11D8-93BF-000A9566A350@DDG.com> Cc: IETF MARID WG From: "Andrew W. Donoho" Subject: Re: What Meng said Date: Fri, 13 Aug 2004 13:50:13 -0500 To: "Carl S. Gutekunst" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-6-299179966 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 13, 2004, at 12:05, Carl S. Gutekunst wrote: > Andrew W. Donoho wrote: > >> .... there is a very real chance that marketing may overwhelm the >> standards process. We should tread carefully here. The rush to >> specification for Sender-ID seems ill advised. >> >> ... The PRA and other mechanisms may offer value but, because of >> their complexity, should be deferred until these simpler mechanism's >> specifications are finalized. > > Thank you for the most rational and sensible post I've seen on this > list in the past two months. Please, folks, can we pick some of the > low-hanging fruit first? > > Incidentally, Andrew, I tried to reply to you directly, but your SPF > check bounces my mail. It does not appear that there is any way for me > to send E-mail to you from any of my legitimate accounts. Carl, Thank you for the kind words. Here are the offending entries from my mail log. 11:58:46.69 4 SMTPI-80515(conure.mail.pas.earthlink.net) cmd: MAIL FROM: SIZE=2651 11:58:46.69 4 SMTPI-80515(conure.mail.pas.earthlink.net) SPF(habeas.com) checking 11:58:47.03 1 SMTPI-80515(conure.mail.pas.earthlink.net) Return-Path 'csg@habeas.com' rejected: sender domain does not match SPF records 11:58:49.03 4 SMTPI-80515(conure.mail.pas.earthlink.net) rsp: 587 csg@habeas.com sender domain does not match SPF records 11:58:49.03 4 SMTPI-80515(conure.mail.pas.earthlink.net) cmd: RCPT TO: 11:58:51.03 4 SMTPI-80515(conure.mail.pas.earthlink.net) rsp: 501 Unknown command 11:58:51.03 4 SMTPI-80515(conure.mail.pas.earthlink.net) cmd: DATA Here is your SPF record: habeas.com. 76012 IN TXT "v=spf1 a mx ptr ip4:66.120.210.129/27 -all" In other words, my mail server did what your policy said to do - reject. You may want to talk to your DNS administrator. Best Regards, Andrew ____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-6-299179966 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Aug 13, 2004, at 12:05, Carl S. Gutekunst wrote: Andrew W. Donoho wrote: .... there is a very real chance that marketing may overwhelm the standards process. We should tread carefully here. The rush to specification for Sender-ID seems ill advised. ... The PRA and other mechanisms may offer value but, because of their complexity, should be deferred until these simpler mechanism's specifications are finalized. Thank you for the most rational and sensible post I've seen on this list in the past two months. Please, folks, can we pick some of the low-hanging fruit first? Incidentally, Andrew, I tried to reply to you directly, but your SPF check bounces my mail. It does not appear that there is any way for me to send E-mail to you from any of my legitimate accounts. Carl, Thank you for the kind words. Here are the offending entries from my mail log. Courier11:58:46.69 4 SMTPI-80515(conure.mail.pas.earthlink.net) cmd: MAIL FROM:< SIZE=2651 11:58:46.69 4 SMTPI-80515(conure.mail.pas.earthlink.net) SPF(habeas.com) checking 11:58:47.03 1 SMTPI-80515(conure.mail.pas.earthlink.net) Return-Path 'csg@habeas.com' rejected: sender domain does not match SPF records 11:58:49.03 4 SMTPI-80515(conure.mail.pas.earthlink.net) rsp: 587 csg@habeas.com sender domain does not match SPF records 11:58:49.03 4 SMTPI-80515(conure.mail.pas.earthlink.net) cmd: RCPT TO:< 11:58:51.03 4 SMTPI-80515(conure.mail.pas.earthlink.net) rsp: 501 Unknown command 11:58:51.03 4 SMTPI-80515(conure.mail.pas.earthlink.net) cmd: DATA Here is your SPF record: habeas.com. 76012 IN TXT "v=spf1 a mx ptr ip4:66.120.210.129/27 -all" In other words, my mail server did what your policy said to do - reject. You may want to talk to your DNS administrator. Best Regards, Andrew Helvetica____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-6-299179966-- From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 16:11: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 QAA14889 for ; Fri, 13 Aug 2004 16:11: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 i7DJiTTv055539; Fri, 13 Aug 2004 12:44: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 i7DJiT58055538; Fri, 13 Aug 2004 12:44:29 -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 i7DJiSQB055497 for ; Fri, 13 Aug 2004 12:44:29 -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 i7DJiScg013881 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Aug 2004 15:44:29 -0400 Date: Fri, 13 Aug 2004 15:44:28 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Gordon Fecyk cc: ietf-mxcomp@imc.org Subject: RE: How is SPF different from RMX? In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553D6@srv1.pan-am.ca> 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 didn't know Wallace said that. If he did say it, he was right, at least about that. Even a broken clock is right twice a day. But it has been reported and discussed elsewhere that AOL does advertising to its users. I don't think that is too surprising, and it has certainly been discussed many times on many forums since 1997. So does MSN, as reported by the MSN anti-spam technical staff at the spam conference held at MIT. The MSN people said that the biggest complaint they got was that their filters were blocking the internal spamming. --Dean On Wed, 11 Aug 2004, Gordon Fecyk wrote: > > > My only gripe about AOL (as some may know) is that AOL is not against > > spam, but only against spam that doesn't pay it advertising fees to > > communicate to its users. > > I understand that a lot of us have short term memories[1], so this may come > as a shock. > > The only other person I have ever heard this type of comment from was Sanford > Wallace back in his Cyberpromo days. "He accused America Online of getting > Sprint to act, because Cyber Promotion was AOL's competitor for advertising > dollars." > > http://www.computerbits.com/archive/1997/0100/surf9701.html > > A comment like this doesn't sound much different from old "spamford." > > [1] Yet another parallel with the anti-virus industry. > > From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 18:48: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 SAA24104 for ; Fri, 13 Aug 2004 18:48: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 i7DMUONQ070397; Fri, 13 Aug 2004 15:30:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DMUO2L070396; Fri, 13 Aug 2004 15:30:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DMUNWC070387 for ; Fri, 13 Aug 2004 15:30:23 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7DMUJ77028906 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 13 Aug 2004 18:30:20 -0400 Subject: RE: Does marid-submitter-02 really make sense? From: Mark Shewmaker To: Douglas Otis Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092419820.8257.100.camel@ddev.mail-abuse.org> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> <1092361125.7627.196.camel@ddev.mail-abuse.org> <1092368581.3295.1289.camel@localhost.localdomain> <1092419820.8257.100.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1092436440.15747.1376.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 13 Aug 2004 18:34:01 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Fri, 13 Aug 2004 18:30:22 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-13 at 13:57, Douglas Otis wrote: > On Thu, 2004-08-12 at 20:43, Mark Shewmaker wrote: > > Or they'll go out of business. > > There is a high cost for spam where much of this is seen by the network > provider. Taking away tools to curtail this abuse is not a good > solution and can drive providers out of business. What tools to curtail abuse am I taking away? If a business loses money because their customers realize that they can't trust that mail claiming to be most recently (re)sent into the mail by them really was, then whether that distrust built up because they didn't publish spf records or whether it built up because people realized that the spf records they did publish could not be trusted--either way their customers will leave. How is that taking away tools to curtail abuse? > > Sorry--if my reputation system makes me give a poor reputation to > > someone because they're using a shared MTA that allows cross-customer > > forgeries, then my reputation system is doing it's job. > > Explain that in court. I describe my thoughts on how I figure out what I trust and don't trust, and your response is that I'll have to explain it in court. And you still don't understand why I call this a thought crime? > The provider guarding against abuse does not > examine or change the content of the mail, they look for protocol > generated errors. Well, I for one won't trust mail from mail servers run with such a mindset as compared with mail from mail servers that have what is in my opinion a more enlightened mindset. I can't imagine that in 5 years people would continue to find such behavior as you claim as fact to be acceptable. I expect that mail servers that don't validate the content of outgoing email (protecting against cross-customer forgeries among other things) will tend to cause such mails and their purported sending domains to be rated poorly, (when the domain gives pass results to mail from those servers.) > > If someone else can spoof trustworthy@trustworthy.com, then I hope my > > reputation systems will assign a poor reputation to the trustworthy.com > > domain, because any claims of anyone to be from there aren't, well, > > trustworthy. > > The question should be, do you blame the mail system allowing mail to > share MTA servers as designed, or do you blame repudiation services for > not considering such cases. The problem is that trustworthy.com told me I could trust an untrustable MTA. Trustworthy.com could go to a more trustworthy MSP, or they could try to convince their MSP to disallow cross-customer forgeries. > > The fact that trustworthy@trustworthy.com tells me to trust that a > > message really comes from him if it comes through a specific IP still > > doesn't mean I should trust such claims if I know that that specific IP > > itself isn't trustworthy. > > Mail providers MUST NOT use Sender-ID when they can not ensure a > ONE-TO-ONE relationship between Domain and Server. The draft should > make this warning very clear, but it does not. I see no problem with a zillion domains having a single server as an outbound MTA if that single server doesn't allow cross-customer forgeries. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 18:50: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 SAA24192 for ; Fri, 13 Aug 2004 18:50: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 i7DMaA6k070685; Fri, 13 Aug 2004 15:36: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 i7DMaAag070684; Fri, 13 Aug 2004 15:36:10 -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 i7DMaAOu070671 for ; Fri, 13 Aug 2004 15:36:10 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [66.80.0.12] (dhcp-12.danastreet.live.com [66.80.0.12]) by mail.glyphic.com (Postfix) with ESMTP id 62B4C40DD for ; Fri, 13 Aug 2004 15:36:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2AAE79DE-ED79-11D8-850F-000393A56BB6@glyphic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Mark Lentczner Subject: Changes for protocol-01 Date: Fri, 13 Aug 2004 15:36:07 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Friends - draft-ietf-marid-protocol-01 has been submitted. In addition to the changes I mentioned previously in this list, it includes: Major Changes * Language for new DNS RR type from DNS-EXT folks: Compliance now requires using new RR type, and EDNS0 compliant software. * Added back %{p} macro that was removed in last rev - some people use it * Changed the version to "spf2.0/pra" and added future extension support Descriptive Changes * Clarified interpretation of domain-spec after macro expansion * Clarified that new mechanisms can only come from new versions Minor Changes * All examples of RR records now use SPF2 RR type, not TXT * Added IANA request for new RR type * Fixed the value of IPv6 examples to conform to RFC 3849 - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 19:47:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26116 for ; Fri, 13 Aug 2004 19:47:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DNLjoe074034; Fri, 13 Aug 2004 16:21: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 i7DNLjQk074033; Fri, 13 Aug 2004 16:21:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DNLiQT074027 for ; Fri, 13 Aug 2004 16:21:45 -0700 (PDT) (envelope-from roy+dated+1095031301.e41432@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7DNObd7095731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Aug 2004 23:24:43 GMT (envelope-from roy+dated+1095031301.e41432@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7DNLfkU043885 for ; Sat, 14 Aug 2004 00:21:41 +0100 (BST) (envelope-from roy+dated+1095031301.e41432@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7DNLfAs043884 for ietf-mxcomp@imc.org; Sat, 14 Aug 2004 00:21:41 +0100 (BST) (envelope-from roy+dated+1095031301.e41432@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 14 Aug 2004 00:21:40 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16669.19716.149276.712332@giles.gnomon.org.uk> Date: Sat, 14 Aug 2004 00:21:40 +0100 To: Mark Lentczner Cc: IETF MARID WG Subject: Changes for protocol-01 In-Reply-To: <2AAE79DE-ED79-11D8-850F-000393A56BB6@glyphic.com> References: <2AAE79DE-ED79-11D8-850F-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> draft-ietf-marid-protocol-01 has been submitted. Any chance of posting a pointer (or just posting the text) so we don't have to wait for it to show up in the ID archives? -roy From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 19:56: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 TAA26453 for ; Fri, 13 Aug 2004 19:56: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 i7DNg5HD075192; Fri, 13 Aug 2004 16:42: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 i7DNg5Op075191; Fri, 13 Aug 2004 16:42:05 -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 i7DNg49l075178 for ; Fri, 13 Aug 2004 16:42:04 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [66.80.0.12] (dhcp-12.danastreet.live.com [66.80.0.12]) by mail.glyphic.com (Postfix) with ESMTP id 73DC240C3 for ; Fri, 13 Aug 2004 16:42:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <16669.19716.149276.712332@giles.gnomon.org.uk> References: <2AAE79DE-ED79-11D8-850F-000393A56BB6@glyphic.com> <16669.19716.149276.712332@giles.gnomon.org.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <61400E86-ED82-11D8-850F-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: Changes for protocol-01 Date: Fri, 13 Aug 2004 16:42:04 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Any chance of posting a pointer (or just posting the text) so we don't > have to wait for it to show up in the ID archives? Hope this doesn't get me in trouble.... Here is a link to the HTML version: http://www.ozonehouse.com/mark/protocol-01.html Note: The version published by the internet-draft editor should be considered official, not this. They should be the same, only the official one is in text format. - Mark From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 20: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 UAA26885 for ; Fri, 13 Aug 2004 20: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 i7DNcxKV075001; Fri, 13 Aug 2004 16:38:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DNcxwp075000; Fri, 13 Aug 2004 16:38:59 -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.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DNcwu9074994 for ; Fri, 13 Aug 2004 16:38:59 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 16:39:03 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Aug 2004 16:39:06 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 16:39:03 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 16:38:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7379.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4818E.B12420E9" Subject: New draft-ietf-marid-core-03 and draft-ietf-marid-pra-00 Date: Fri, 13 Aug 2004 16:38:22 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF80CC4A@df-fido-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: New draft-ietf-marid-core-03 and draft-ietf-marid-pra-00 Thread-Index: AcSBjp8Ld/mIu9qbR664kchd+beaYA== From: "Jim Lyon" To: "Internet Draft Editor" Cc: "Andrew Newton" , "Marshall Rose" , "IETF MARID WG" X-OriginalArrivalTime: 13 Aug 2004 23:38:59.0386 (UTC) FILETIME=[B4EB11A0:01C4818E] 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_01C4818E.B12420E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I-D Editor, One revised draft, draft-ietf-marid-core-03 and one new draft, draft-ietf-marid-pra-00 are attached. The MARID WG chairs are copied for approval for the new draft. Change record (for the working group): Section 2.1: Changed "it makes no attempt to authenticate the local-part" to "it is not directed at the local-part". Section 4: Moved PRA definition to new draft-ietf-marid-pra-00. Section 6.3: Changed title from "Forged Resent-From Attacks" to "Forged Sender Attacks". Changed "In order to avoid this attack" to "In order to neutralize this attack". New Section 6.4: Address Space Hijacking Section 7: Added language that e-mail forwarders, mailing list servers and third-party mailers SHOULD publish Sender ID records, and SHOULD use MTAs for which the Sender ID test will yield a "pass" result. Page header now matches title. Fixed a few typos. Thanks, -- Jim Lyon mailto:JimLyon@Microsoft.Com tel:+1-425-706-0867 Internet commerce will never really take off until you can buy something online without getting spammed by the vendor. ------_=_NextPart_001_01C4818E.B12420E9 Content-Type: text/plain; name="draft-ietf-marid-pra-00.txt" Content-Description: draft-ietf-marid-pra-00.txt Content-Disposition: attachment; filename="draft-ietf-marid-pra-00.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQogICBNQVJJRCBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSi4gTHlvbg0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0IENvcnANCiAgIERvY3VtZW50OiBkcmFm dC1pZXRmLW1hcmlkLXByYS0wMC50eHQNCiAgIEV4cGlyZXM6IEZlYnJ1YXJ5IDIwMDUgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA0DQoNCg0KICAgICAgICAgICAg IFB1cnBvcnRlZCBSZXNwb25zaWJsZSBBZGRyZXNzIGluIEUtTWFpbCBNZXNzYWdlcw0KDQoNClN0 YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0 LCBJIGNlcnRpZnkgdGhhdCBhbnkgYXBwbGljYWJsZQ0KICAgcGF0ZW50IG9yIG90aGVyIElQUiBj bGFpbXMgb2Ygd2hpY2ggSSBhbSBhd2FyZSBoYXZlIGJlZW4gZGlzY2xvc2VkLA0KICAgb3Igd2ls bCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggSSBiZWNvbWUgYXdhcmUgd2lsbCBiZQ0K ICAgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggUkZDIDM2NjguDQoNCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n DQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBz LiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQog ICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9j dW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVy bmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGEgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnLzFpZC1hYnN0cmFjdHMuaHRtbA0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBT aGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9zaGFkb3cuaHRtbA0KDQpBYnN0cmFjdA0KDQogICBUaGUgZG9jdW1lbnQgZGVmaW5l cyBhbiBhbGdvcml0aG0gYnkgd2hpY2gsIGdpdmVuIGFuIGUtbWFpbCBtZXNzYWdlLA0KICAgb25l IGNhbiBleHRyYWN0IHRoZSBpZGVudGl0eSBvZiB0aGUgcGFydHkgdGhhdCBhcHBlYXJzIHRvIGhh dmUgbW9zdA0KICAgcHJveGltYXRlbHkgY2F1c2VkIHRoYXQgbWVzc2FnZSB0byBiZSBkZWxpdmVy ZWQuICBUaGlzIGlkZW50aXR5IGlzDQogICBjYWxsZWQgdGhlICJQdXJwb3J0ZWQgUmVzcG9uc2li bGUgQWRkcmVzcyIgKFBSQSkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkouIEx5b24gICAg ICAgICAgICAgICAgRXhwaXJlcyAtIEZlYnJ1YXJ5IDIwMDUgICAgICAgICAgICAgICBbUGFnZSAx XQ0KDA0KICAgICAgICAgICBQdXJwb3J0ZWQgUmVzcG9uc2libGUgQWRkcmVzcyBpbiBFLU1haWwg TWVzc2FnZXMgQXVndXN0IDIwMDQNCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiBJbnRy b2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4yDQogICAyLiBEZXRlcm1pbmluZyB0aGUgUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3Mu Li4uLi4uLi4uLi4uLi4uLi4zDQogICAzLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQogICA0LiBJQU5BIENvbnNpZGVyYXRp b25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQogICA1LiBB Y2tub3dsZWRnZW1lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi40DQogICA2LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi40DQogICAgICA2LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQogICAgICA2LjIgSW5mb3JtYXRp dmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICA3 LiBBdXRob3IncyBBZGRyZXNzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi41DQoNCkNvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudA0KDQogICBUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVk IGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQoNCg0KMS4gSW50cm9kdWN0aW9uDQoNCiAgIE1v c3QgRS1NYWlsIGZsb3dzIHJlbGF0aXZlbHkgZGlyZWN0bHkgZnJvbSBhIHNlbmRlciB0byBhIHJl Y2lwaWVudCwNCiAgIHdpdGggYSBzbWFsbCBudW1iZXIgb2YgTWFpbCBUcmFuc2ZlciBBZ2VudHMg KE1UQXMpIGluIGJldHdlZW4uICBTb21lDQogICBtZXNzYWdlcywgaG93ZXZlciwgYXJlIHJlc2Vu dCBieSBmb3J3YXJkaW5nIGFnZW50cywgbWFpbGluZyBsaXN0DQogICBzZXJ2ZXJzLCBhbmQgb3Ro ZXIgc3VjaCBzb2Z0d2FyZS4gIFRoZXNlIG1lc3NhZ2VzIGVmZmVjdGl2ZWx5IHJlc3VsdA0KICAg aW4gdHdvIG9yIG1vcmUgbWFpbCB0cmFuc2FjdGlvbnM6IG9uZSBmcm9tIHRoZSBzZW5kZXIgdG8g dGhlDQogICBmb3J3YXJkaW5nIGFnZW50LCBhbmQgYW5vdGhlciBmcm9tIHRoZSBhZ2VudCB0byB0 aGUgZGVzdGluYXRpb24uDQoNCiAgIEluIHNvbWUgY2FzZXMsIG1lc3NhZ2VzIHRyYXZlbCB0aHJv dWdoIG1vcmUgdGhhbiBvbmUgb2YgdGhlc2UgYWdlbnRzLg0KICAgVGhpcyBjYW4gb2NjdXIsIGZv ciBleGFtcGxlLCB3aGVuIG9uZSBtYWlsaW5nIGxpc3QgaXMgc3Vic2NyaWJlZCB0bw0KICAgYW5v dGhlciwgb3Igd2hlbiB0aGUgYWRkcmVzcyBzdWJzY3JpYmVkIHRvIGEgbWFpbGluZyBsaXN0IGlz IGENCiAgIGZvcndhcmRpbmcgc2VydmljZS4NCg0KICAgRnVydGhlciBjb21wbGljYXRpbmcgdGhl IHNpdHVhdGlvbiwgaW4gc29tZSBjYXNlcyB0aGUgcGFydHkgdGhhdA0KICAgaW50cm9kdWNlcyBh IG1lc3NhZ2UgaXMgbm90IHRoZSBhdXRob3Igb2YgdGhlIG1lc3NhZ2UuICBGb3IgZXhhbXBsZSwN CiAgIG1hbnkgbmV3cyB3ZWIgc2l0ZXMgaGF2ZSBhICJNYWlsIHRoaXMgYXJ0aWNsZSIgZnVuY3Rp b24gdGhhdCB0aGUNCiAgIHB1YmxpYyBjYW4gdXNlIHRvIGUtbWFpbCBhIGNvcHkgb2YgdGhlIGFy dGljbGUgdG8gYSBmcmllbmQuICBJbiB0aGlzDQogICBjYXNlLCB0aGUgbWFpbCBpcyAiZnJvbSIg dGhlIHBlcnNvbiB3aG8gcHJlc3NlZCB0aGUgYnV0dG9uLCBidXQgaXMNCiAgIHBoeXNpY2FsbHkg c2VudCBieSB0aGUgb3BlcmF0b3Igb2YgdGhlIHdlYiBzaXRlLg0KDQogICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBhbiBhbGdvcml0aG0gdGhhdCBhbGxvd3Mgb25lIHRvIGRldGVybWluZSB3aG8N CiAgIGFwcGVhcnMgdG8gaGF2ZSBtb3N0IHJlY2VudGx5IGNhdXNlZCBhbiBlLW1haWwgbWVzc2Fn ZSB0byBiZQ0KICAgZGVsaXZlcmVkLiAgSXQgZG9lcyB0aGlzIGJ5IGluc3BlY3RpbmcgdGhlIGhl YWRlcnMgaW4gdGhlIG1lc3NhZ2UuDQogICBbUkZDMjgyMl0gY29udGFpbnMgYSBkZXRhaWxlZCBz cGVjaWZpY2F0aW9uIG9mIGFsbCBvZiB0aGUgcmVsZXZhbnQNCiAgIGhlYWRlcnMuDQoNCiAgIE5v dGUgdGhhdCB0aGUgcmVzdWx0cyBvZiB0aGlzIGFsZ29yaXRobSBhcmUgb25seSBhcyB0cnV0aGZ1 bCBhcyB0aGUNCiAgIGhlYWRlcnMgY29udGFpbmVkIGluIHRoZSBtZXNzYWdlOyBpZiBhIG1lc3Nh Z2UgY29udGFpbnMgZnJhdWR1bGVudCBvcg0KICAgaW5jb3JyZWN0IGhlYWRlcnMsIHRoaXMgYWxn b3JpdGhtIHdpbGwgeWllbGQgYW4gaW5jb3JyZWN0IHJlc3VsdC4NCg0KDQpKLiBMeW9uICAgICAg ICAgICAgICAgIEV4cGlyZXMgLSBGZWJydWFyeSAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMl0N CgwNCiAgICAgICAgICAgUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MgaW4gRS1NYWlsIE1l c3NhZ2VzIEF1Z3VzdCAyMDA0DQoNCg0KICAgRm9yIHRoaXMgcmVhc29uLCB0aGUgcmVzdWx0IG9m IHRoZSBhbGdvcml0aG0gaXMgY2FsbGVkIHRoZSAiUHVycG9ydGVkDQogICBSZXNwb25zaWJsZSBB ZGRyZXNzIiAtLSAicHVycG9ydGVkIiBiZWNhdXNlIGl0IHRlbGxzIHlvdSB3aGF0IGENCiAgIG1l c3NhZ2UgY2xhaW1zIGFib3V0IHdoZXJlIGl0IGNhbWUgZnJvbSwgYnV0IG5vdCBuZWNlc3Nhcmls eSB3aGVyZSBpdA0KICAgYWN0dWFsbHkgY2FtZSBmcm9tLg0KDQogICBUaGlzIGRvY3VtZW50IGRv ZXMgbm90IHByZXNjcmliZSBhbnkgcGFydGljdWxhciB1c2VzIGZvciB0aGUNCiAgIFB1cnBvcnRl ZCBSZXNwb25zaWJsZSBBZGRyZXNzLiAgSG93ZXZlciwgW1NlbmRlcklEXSBkZXNjcmliZXMgYQ0K ICAgbWV0aG9kIG9mIGRldGVybWluaW5nIHdoZXRoZXIgYSBwYXJ0aWN1bGFyIE1UQSBpcyBhdXRo b3JpemVkIHRvIHNlbmQNCiAgIG1haWwgb24gYmVoYWxmIG9mIHRoZSBkb21haW4gY29udGFpbmVk IGluIHRoZSBQUkEuDQoNCg0KMi4gRGV0ZXJtaW5pbmcgdGhlIFB1cnBvcnRlZCBSZXNwb25zaWJs ZSBBZGRyZXNzDQoNCiAgIFRoZSBwdXJwb3J0ZWQgcmVzcG9uc2libGUgYWRkcmVzcyAoUFJBKSBv ZiBhIG1lc3NhZ2UgaXMgZGV0ZXJtaW5lZCBieQ0KICAgdGhlIGZvbGxvd2luZyBhbGdvcml0aG06 DQoNCiAgICAgMS4gTG9jYXRlIHRoZSBmaXJzdCBub24tZW1wdHkgUmVzZW50LVNlbmRlciBoZWFk ZXIgaW4gdGhlIG1lc3NhZ2UuDQogICAgICAgIElmIG5vIHN1Y2ggaGVhZGVyIGlzIGZvdW5kLCBj b250aW51ZSB3aXRoIHN0ZXAgMi4gIElmIGl0IGlzDQogICAgICAgIHByZWNlZGVkIGJ5IGEgbm9u LWVtcHR5IFJlc2VudC1Gcm9tIGhlYWRlciBhbmQgb25lIG9yIG1vcmUNCiAgICAgICAgUmVjZWl2 ZWQgb3IgUmV0dXJuLVBhdGggaGVhZGVycyBvY2N1ciBhZnRlciBzYWlkIFJlc2VudC1Gcm9tDQog ICAgICAgIGhlYWRlciBhbmQgYmVmb3JlIHRoZSBSZXNlbnQtU2VuZGVyIGhlYWRlciwgY29udGlu dWUgd2l0aCBzdGVwDQogICAgICAgIDIuICBPdGhlcndpc2UsIHByb2NlZWQgdG8gc3RlcCA1Lg0K DQogICAgIDIuIExvY2F0ZSB0aGUgZmlyc3Qgbm9uLWVtcHR5IFJlc2VudC1Gcm9tIGhlYWRlciBp biB0aGUgbWVzc2FnZS4NCiAgICAgICAgSWYgYSBSZXNlbnQtRnJvbSBoZWFkZXIgaXMgZm91bmQs IHByb2NlZWQgdG8gc3RlcCA1LiBPdGhlcndpc2UsDQogICAgICAgIGNvbnRpbnVlIHdpdGggc3Rl cCAzLg0KDQogICAgIDMuIExvY2F0ZSBhbGwgdGhlIG5vbi1lbXB0eSBTZW5kZXIgaGVhZGVycyBp biB0aGUgbWVzc2FnZS4gIElmDQogICAgICAgIHRoZXJlIGFyZSBubyBzdWNoIGhlYWRlcnMsIGNv bnRpbnVlIHdpdGggc3RlcCA0LiAgSWYgdGhlcmUgaXMNCiAgICAgICAgZXhhY3RseSBvbmUgc3Vj aCBoZWFkZXIsIHByb2NlZWQgdG8gc3RlcCA1LiAgSWYgdGhlcmUgaXMgbW9yZQ0KICAgICAgICB0 aGFuIG9uZSBzdWNoIGhlYWRlciwgcHJvY2VlZCB0byBzdGVwIDYuDQoNCiAgICAgNC4gTG9jYXRl IGFsbCB0aGUgbm9uLWVtcHR5IEZyb20gaGVhZGVycyBpbiB0aGUgbWVzc2FnZS4gIElmIHRoZXJl DQogICAgICAgIGlzIGV4YWN0bHkgb25lIHN1Y2ggaGVhZGVyLCBjb250aW51ZSB3aXRoIHN0ZXAg NS4gIE90aGVyd2lzZSwNCiAgICAgICAgcHJvY2VlZCB0byBzdGVwIDYuDQoNCiAgICAgNS4gQSBw cmV2aW91cyBzdGVwIGhhcyBzZWxlY3RlZCBhIHNpbmdsZSBoZWFkZXIgZnJvbSB0aGUgbWVzc2Fn ZS4NCiAgICAgICAgSWYgdGhhdCBoZWFkZXIgaXMgbWFsZm9ybWVkIChlLmcuIGl0IGFwcGVhcnMg dG8gY29udGFpbiBtdWx0aXBsZQ0KICAgICAgICBtYWlsYm94ZXMsIG9yIHRoZSBzaW5nbGUgbWFp bGJveCBpcyBob3BlbGVzc2x5IG1hbGZvcm1lZCwgb3IgdGhlDQogICAgICAgIHNpbmdsZSBtYWls Ym94IGRvZXMgbm90IGNvbnRhaW4gYSBkb21haW4gbmFtZSksIGNvbnRpbnVlIHdpdGgNCiAgICAg ICAgc3RlcCA2LiAgT3RoZXJ3aXNlLCByZXR1cm4gdGhhdCBzaW5nbGUgbWFpbGJveCBhcyB0aGUg UHVycG9ydGVkDQogICAgICAgIFJlc3BvbnNpYmxlIEFkZHJlc3MuDQoNCiAgICAgNi4gVGhlIG1l c3NhZ2UgaXMgaWxsLWZvcm1lZCwgYW5kIGl0IGlzIGltcG9zc2libGUgdG8gZGV0ZXJtaW5lIGEN CiAgICAgICAgUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MuDQoNCg0KICAgTm90ZSB0aGF0 IHdoYXQgY29uc3RpdHV0ZXMgYSBob3BlbGVzc2x5IG1hbGZvcm1lZCBoZWFkZXIgb3IgYQ0KICAg aG9wZWxlc3NseSBtYWxmb3JtZWQgbWFpbGJveCBpbiBzdGVwIDUgYWJvdmUgaXMgYSBtYXR0ZXIg Zm9yIGxvY2FsDQoNCg0KSi4gTHlvbiAgICAgICAgICAgICAgICBFeHBpcmVzIC0gRmVicnVhcnkg MjAwNSAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQogICAgICAgICAgIFB1cnBvcnRlZCBSZXNw b25zaWJsZSBBZGRyZXNzIGluIEUtTWFpbCBNZXNzYWdlcyBBdWd1c3QgMjAwNA0KDQoNCiAgIHBv bGljeS4gIFN1Y2ggbG9jYWwgcG9saWN5IHdpbGwgbmV2ZXIgY2F1c2UgdHdvIGltcGxlbWVudGF0 aW9ucyB0bw0KICAgcmV0dXJuIGRpZmZlcmVudCBQUkFzLiAgSG93ZXZlciBpdCBtYXkgY2F1c2Ug b25lIGltcGxlbWVudGF0aW9uIHRvDQogICByZXR1cm4gYSBQUkEgd2hlcmUgYW5vdGhlciBpbXBs ZW1lbnRhdGlvbiBkb2VzIG5vdC4gIFRoaXMgd2lsbCBvbmx5DQogICBvY2N1ciB3aGVuIGRlYWxp bmcgd2l0aCBhIG1lc3NhZ2UgY29udGFpbmluZyBoZWFkZXJzIG9mIHF1ZXN0aW9uYWJsZQ0KICAg bGVnYWxpdHkuDQoNCiAgIE5vdGUgdGhhdCBzdGVwcyAxIGFuZCAyIGFib3ZlIGV4dHJhY3QgdGhl IFJlc2VudC1TZW5kZXIgb3IgUmVzZW50LQ0KICAgRnJvbSBoZWFkZXIgZnJvbSB0aGUgZmlyc3Qg cmVzZW50IGJsb2NrIChhcyBkZWZpbmVkIGJ5IHNlY3Rpb24gMy42LjYNCiAgIG9mIFtSRkMyODIy XSkgaWYgYW55LiAgU3RlcHMgMyBhbmQgNCBhYm92ZSBleHRyYWN0IHRoZSBTZW5kZXIgb3IgRnJv bQ0KICAgaGVhZGVyIGlmIHRoZXJlIGFyZSBubyByZXNlbnQgYmxvY2tzLg0KDQoNCjMuIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBQUkEsIGFzIGRlc2NyaWJlZCBieSB0aGlzIGRv Y3VtZW50LCBpcyBleHRyYWN0ZWQgZnJvbSBtZXNzYWdlDQogICBoZWFkZXJzIHRoYXQgaGF2ZSBo aXN0b3JpY2FsbHkgbm90IGJlZW4gdmVyaWZpZWQuICBUaHVzLCBhbnlvbmUgdXNpbmcNCiAgIHRo ZSBQUkEgZm9yIGFueSBwdXJwb3NlIE1VU1QgYmUgYXdhcmUgdGhhdCB0aGUgaGVhZGVycyBmcm9t IHdoaWNoIGlzDQogICBpcyBkZXJpdmVkIG1pZ2h0IGJlIGZyYXVkdWxlbnQsIG1hbGljaW91cywg bWFsZm9ybWVkIGFuZC9vcg0KICAgaW5jb3JyZWN0LiAgW1NlbmRlcklEXSBkZXNjcmliZXMgb25l IG1lY2hhbmlzbSBmb3IgdmFsaWRhdGluZyB0aGUNCiAgIFBSQS4NCg0KDQo0LiBJQU5BIENvbnNp ZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgY29udGFpbnMgbm8gYWN0aW9ucyBmb3IgSUFO QS4NCg0KDQo1LiBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFRoZSBQUkEgY29uY2VwdCB3YXMgZmly c3QgcHVibGlzaGVkIGluIFtDYWxsZXJJRF0uICBJdCBhcyBiZWVuDQogICByZWZpbmVkIHVzaW5n IHZhbHVhYmxlIHN1Z2dlc3Rpb25zIGZyb20gbWVtYmVycyBvZiB0aGUgTUFSSUQgd29ya2luZw0K ICAgZ3JvdXAuDQoNCg0KNi4gUmVmZXJlbmNlcw0KDQo2LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMN Cg0KICAgW1JGQzIxMTldICAgUy4gQnJhZG5lciwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3Mg dG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIFJGQyAyMTE5 Lg0KDQogICBbUkZDMjgyMl0gICBQLiBSZXNuaWNrIChlZGl0b3IpLCAiSW50ZXJuZXQgTWVzc2Fn ZSBGb3JtYXQiLCBSRkMgMjgyMi4NCg0KDQoNCg0KDQoNCg0KDQoNCkouIEx5b24gICAgICAgICAg ICAgICAgRXhwaXJlcyAtIEZlYnJ1YXJ5IDIwMDUgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0K ICAgICAgICAgICBQdXJwb3J0ZWQgUmVzcG9uc2libGUgQWRkcmVzcyBpbiBFLU1haWwgTWVzc2Fn ZXMgQXVndXN0IDIwMDQNCg0KDQoNCjYuMiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtD YWxsZXJJRF0gIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbiwgQ2FsbGVyIElEIGZvciBFLU1haWwgVGVj aG5pY2FsDQogICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uLA0KICAgICAgICAgICAgICAgaHR0 cDovL3d3dy5taWNyb3NvZnQuY29tL21zY29ycC90d2MvcHJpdmFjeS9zcGFtX2NhbGxlcmlkDQog ICAgICAgICAgICAgICAubXNweC4NCg0KICAgW1NlbmRlcklEXSAgSi4gTHlvbiBhbmQgTS4gV29u ZywgIlNlbmRlciBJRDogIEF1dGhlbnRpY2F0aW5nIEUtTWFpbCIsDQogICAgICAgICAgICAgICBk cmFmdC1pZXRmLW1hcmlkLWNvcmUtMDMuICBXb3JrIGluIHByb2dyZXNzLg0KDQoNCg0KNy4gQXV0 aG9yJ3MgQWRkcmVzcw0KDQogICBKaW0gTHlvbg0KICAgTWljcm9zb2Z0IENvcnBvcmF0aW9uDQog ICBPbmUgTWljcm9zb2Z0IFdheQ0KICAgUmVkbW9uZCwgV0EgOTgwNTINCiAgIFVTQQ0KICAgamlt bHlvbkBtaWNyb3NvZnQuY29tDQoNCg0KSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA0K DQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9y IHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciBy aWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1l bnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRv Y3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdo dHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJl c2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50 aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3 aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBp biBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRl IHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5z ZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQg bWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVz ZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJz IG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYg b24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoN CiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRz IGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0 aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNo bm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFy ZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdCBpZXRmLQ0K ICAgaXByQGlldGYub3JnLg0KDQoNCg0KDQoNCkouIEx5b24gICAgICAgICAgICAgICAgRXhwaXJl cyAtIEZlYnJ1YXJ5IDIwMDUgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KICAgICAgICAgICBQ dXJwb3J0ZWQgUmVzcG9uc2libGUgQWRkcmVzcyBpbiBFLU1haWwgTWVzc2FnZXMgQXVndXN0IDIw MDQNCg0KDQoNCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVudCBhbmQg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAi QVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hF IFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVU IFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVND TEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5HIEJV VCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAgSU5G T1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJ RUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFS VElDVUxBUiBQVVJQT1NFLg0KDQoNCkNvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0 IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNCkuICBUaGlzIGRvY3VtZW50IGlzIHN1Ympl Y3QNCiAgIHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVk IGluIEJDUCA3OCwgYW5kDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRo b3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1 bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBi eSB0aGUNCiAgIEludGVybmV0IFNvY2lldHkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkouIEx5b24gICAgICAgICAgICAgICAgRXhwaXJl cyAtIEZlYnJ1YXJ5IDIwMDUgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA== ------_=_NextPart_001_01C4818E.B12420E9 Content-Type: text/plain; name="draft-ietf-marid-core-03.txt" Content-Description: draft-ietf-marid-core-03.txt Content-Disposition: attachment; filename="draft-ietf-marid-core-03.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQogICBNQVJJRCBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSi4gTHlvbg0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0IENvcnANCiAgIERvY3VtZW50OiBkcmFm dC1pZXRmLW1hcmlkLWNvcmUtMDMudHh0ICAgICAgICAgICAgICAgICAgICAgICBNLiBXb25nDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHBvYm94LmNvbQ0KICAgRXhwaXJlczogRmVicnVhcnkgMjAwNSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDQNCg0KDQogICAgICAgICAgICAgICAgICAgICBT ZW5kZXIgSUQ6IEF1dGhlbnRpY2F0aW5nIEUtTWFpbA0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8N Cg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBJIGNlcnRpZnkgdGhhdCBh bnkgYXBwbGljYWJsZQ0KICAgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggSSBh bSBhd2FyZSBoYXZlIGJlZW4gZGlzY2xvc2VkLA0KICAgb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFu ZCBhbnkgb2Ygd2hpY2ggSSBiZWNvbWUgYXdhcmUgd2lsbCBiZQ0KICAgZGlzY2xvc2VkLCBpbiBh Y2NvcmRhbmNlIHdpdGggUkZDIDM2NjguDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJ RVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGEgIndvcmsgaW4g cHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4g YmUgYWNjZXNzZWQgYXQNCiAgICAgICBodHRwOi8vd3d3LmlldGYub3JnLzFpZC1hYnN0cmFjdHMu aHRtbA0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg Y2FuIGJlIGFjY2Vzc2VkIGF0DQogICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bA0KDQpBYnN0cmFjdA0KDQogICBJbnRlcm5ldCBtYWlsIHN1ZmZlcnMgZnJvbSB0aGUgZmFjdCB0 aGF0IG11Y2ggdW53YW50ZWQgbWFpbCBpcyBzZW50DQogICB1c2luZyBzcG9vZmVkIGFkZHJlc3Nl cyAtLSAic3Bvb2ZlZCIgaW4gdGhpcyBjYXNlIG1lYW5zIHRoZSBhZGRyZXNzDQogICBpcyB1c2Vk IHdpdGhvdXQgdGhlIHBlcm1pc3Npb24gb2YgdGhlIGRvbWFpbiBvd25lci4gIFRoaXMgZG9jdW1l bnQNCiAgIGRlc2NyaWJlcyB0aGUgZm9sbG93aW5nOiAgbWVjaGFuaXNtcyBieSB3aGljaCBhIGRv bWFpbiBvd25lciBjYW4NCiAgIHB1Ymxpc2ggaXRzIHNldCBvZiBvdXRnb2luZyBNVEFzLCBtZWNo YW5pc21zIGJ5IHdoaWNoIFNNVFAgc2VydmVycw0KICAgY2FuIGRldGVybWluZSB3aGF0IGVtYWls IGFkZHJlc3MgaXMgYWxsZWdlZGx5IHJlc3BvbnNpYmxlIGZvciBtb3N0DQogICBwcm94aW1hdGVs eSBpbnRyb2R1Y2luZyBhIG1lc3NhZ2UgaW50byB0aGUgSW50ZXJuZXQgbWFpbCBzeXN0ZW0sIGFu ZA0KICAgd2hldGhlciB0aGF0IGludHJvZHVjdGlvbiBpcyBhdXRob3JpemVkIGJ5IHRoZSBvd25l ciBvZiB0aGUgZG9tYWluDQogICBjb250YWluZWQgaW4gdGhhdCBlbWFpbCBhZGRyZXNzLg0KDQog ICBUaGUgc3BlY2lmaWNhdGlvbiBpcyBjYXJlZnVsbHkgdGFpbG9yZWQgdG8gZW5zdXJlIHRoYXQg dGhlDQogICBvdmVyd2hlbG1pbmcgbWFqb3JpdHkgb2YgbGVnaXRpbWF0ZSBlbWFpbGVycywgcmVt YWlsZXJzIGFuZCBtYWlsaW5nDQogICBsaXN0IG9wZXJhdG9ycyBhcmUgYWxyZWFkeSBjb21wbGlh bnQuDQoNCg0KDQpMeW9uLCBXb25nICAgICAgICAgICAgIEV4cGlyZXMgLSBGZWJydWFyeSAyMDA1 ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCiAgICAgICAgICAgICAgICAgICBTZW5kZXIgSUQ6 IEF1dGhlbnRpY2F0aW5nIEUtTWFpbCAgICAgICAgQXVndXN0IDIwMDQNCg0KDQpUYWJsZSBvZiBD b250ZW50cw0KDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zDQogICAyLiBQcm9ibGVtIFN0YXRlbWVudC4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zDQogICAgICAyLjEgUG9zaXRp dmUgUHJvYmxlbSBTdGF0ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zDQog ICAgICAyLjIgTmVnYXRpdmUgUHJvYmxlbSBTdGF0ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi40DQogICAzLiBEZWNpc2lvbiBNb2RlbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQogICA0LiBEZXRlcm1pbmluZyB0aGUgUHVycG9y dGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MuLi4uLi4uLi4uLi4uLi4uLi41DQogICA1LiBBY3Rpb25z IEJhc2VkIG9uIHRoZSBEZWNpc2lvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41 DQogICAgICA1LjEgTmV1dHJhbCBvciBOb25lIG9yIFBlcm1FcnJvci4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi42DQogICAgICA1LjIgUGFzcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICAgICA1LjMgRmFpbC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICAgICA1LjQg U29mdEZhaWwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li42DQogICAgICA1LjUgVGVtcEVycm9yLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi42DQogICA2LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICAgICA2LjEgRE5TIEF0dGFja3Mu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43DQogICAgICA2 LjIgVENQIEF0dGFja3MuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi43DQogICAgICA2LjMgRm9yZ2VkIFNlbmRlciBBdHRhY2tzLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi43DQogICAgICA2LjQgQWRkcmVzcyBTcGFjZSBIaWphY2tpbmcu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43DQogICA3LiBJbXBsZW1lbnRhdGlv biBHdWlkYW5jZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQogICAg ICA3LjEgU2ltcGxlIEUtbWFpbGVycy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi44DQogICAgICA3LjIgRS1NYWlsIEZvcndhcmRlcnMuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQogICAgICA3LjMgTWFpbGluZyBMaXN0IFNlcnZlcnMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQogICAgICA3LjQgVGhpcmQt UGFydHkgTWFpbGVycy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45DQog ICAgICA3LjUgTVVBIEltcGxlbWVudGVycy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi45DQogICA4LiBJQU5BIENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45DQogICA5LiBBY2tub3dsZWRnZW1lbnRzLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45DQogICAxMC4gUmVmZXJl bmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEw DQogICAgICAxMC4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjEwDQogICAgICAxMC4yIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQogICAxMS4gQXV0aG9ycycgQWRkcmVzc2Vz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExDQoNCkNvbnZlbnRp b25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudA0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhp cw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZD MjExOV0uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAg ICBFeHBpcmVzIC0gRmVicnVhcnkgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQogICAg ICAgICAgICAgICAgICAgU2VuZGVyIElEOiBBdXRoZW50aWNhdGluZyBFLU1haWwgICAgICAgIEF1 Z3VzdCAyMDA0DQoNCg0KMS4gSW50cm9kdWN0aW9uDQoNCiAgIFRvZGF5LCBhIGh1Z2UgbWFqb3Jp dHkgb2YgdW53YW50ZWQgZW1haWwgY29udGFpbnMgaGVhZGVycyB0aGF0IGxpZQ0KICAgYWJvdXQg dGhlIG9yaWdpbiBvZiB0aGUgbWFpbC4gIFRoaXMgaXMgdHJ1ZSBvZiBtb3N0IHNwYW0gYW5kDQog ICBzdWJzdGFudGlhbGx5IGFsbCBvZiB0aGUgdmlydXMgZW1haWwgdGhhdCBpcyBzZW50Lg0KDQog ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSBzdWNoIHRoYXQgcmVjZWl2aW5n IE1UQXMsIE1EQXMNCiAgIGFuZC9vciBNVUFzIGNhbiByZWNvZ25pemUgbWFpbCBpbiB0aGUgYWJv dmUgY2F0ZWdvcnkgYW5kIHRha2UNCiAgIGFwcHJvcHJpYXRlIGFjdGlvbi4gIEZvciBleGFtcGxl LCBhbiBNVEEgbWlnaHQgcmVmdXNlIHRvIGFjY2VwdCBhDQogICBtZXNzYWdlLCBhbiBNREEgbWln aHQgZGlzY2FyZCBhIG1lc3NhZ2UgcmF0aGVyIHRoYW4gcGxhY2luZyBpdCBpbnRvIGENCiAgIG1h aWxib3gsIGFuZCBhbiBNVUEgbWlnaHQgcmVuZGVyIHRoYXQgbWVzc2FnZSBpbiBzb21lIGRpc3Rp bmN0aXZlDQogICBmYXNoaW9uLg0KDQogICBJbiBvcmRlciB0byBhdm9pZCBmdXJ0aGVyIGZyYWdt ZW50YXRpb24gb2YgdGhlIEludGVybmV0IGVtYWlsIHN5c3RlbSwNCiAgIGl0IGlzIG5lY2Vzc2Fy eSB0aGF0IHRoZSBJbnRlcm5ldCBjb21tdW5pdHkgYXMgYSB3aG9sZSBjb21lIHRvIGENCiAgIGNv bnNlbnN1cyBhcyB0byB3aGF0IG1haWwgc2VuZGVycyBzaG91bGQgZG8gdG8gbWFrZSB0aGVpciBt YWlsIGFwcGVhcg0KICAgbm9uLXNwb29mZWQsIGFuZCBob3cgbWFpbCByZWNlaXZlcnMgc2hvdWxk IGRldGVybWluZSB3aGV0aGVyIG1haWwgaXMNCiAgIHNwb29mZWQuICBPbiB0aGUgb3RoZXIgaGFu ZCwgaXQgaXMgbm90IG5lY2Vzc2FyeSB0byByZWFjaCBhIGNvbnNlbnN1cw0KICAgcmVnYXJkaW5n IHRoZSBhY3Rpb25zIHRoYXQgdmFyaW91cyBwYXJ0aWVzIHRha2Ugb25jZSBhIG1lc3NhZ2UgaGFz DQogICBiZWVuIGRldGVybWluZWQgdG8gYmUgc3Bvb2ZlZC4gIFRoaXMgY2FuIGJlIGRvbmUgdW5p bGF0ZXJhbGx5IC0tIG9uZQ0KICAgYWdlbnQgbWlnaHQgZGVjaWRlIHRvIGRpc2NhcmQgYSBzcG9v ZmVkIG1lc3NhZ2Ugd2hpbGUgYW5vdGhlciBkZWNpZGVzDQogICB0byBhZGQgYSBkaXNjbGFpbWVy Lg0KDQoNCjIuIFByb2JsZW0gU3RhdGVtZW50DQoNCjIuMSBQb3NpdGl2ZSBQcm9ibGVtIFN0YXRl bWVudA0KDQogICBCcmllZmx5IHN0YXRlZCwgdGhlIG1lY2hhbmlzbXMgb2YgdGhpcyBkb2N1bWVu dCBhbGxvdyBvbmUgdG8gYW5zd2VyDQogICB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uOg0KDQogICBX aGVuIGEgbWVzc2FnZSBpcyB0cmFuc2ZlcnJlZCB2aWEgU01UUCBiZXR3ZWVuIHR3byBVTlJFTEFU RUQgcGFydGllcywNCiAgIGRvZXMgdGhlIFNNVFAgY2xpZW50IGhvc3QgaGF2ZSBwZXJtaXNzaW9u IHRvIHNlbmQgbWFpbCBvbiBiZWhhbGYgb2YNCiAgIHRoZSBtYWlsYm94IHRoYXQgYWxsZWdlZGx5 IGNhdXNlZCB0aGUgbW9zdCByZWNlbnQgaW50cm9kdWN0aW9uIG9mIHRoZQ0KICAgbWVzc2FnZSBp bnRvIHRoZSBtYWlsIGRlbGl2ZXJ5IHN5c3RlbT8NCg0KICAgQXMgc2VlbiBmcm9tIHRoZSBxdWVz dGlvbiwgdGhpcyBtZWNoYW5pc20gYXBwbGllcyB0byB1bnJlbGF0ZWQNCiAgIHBhcnRpZXM6ICBp dCBpcyB1c2VmdWwgYXQgdGhlIHBvaW50IHdoZXJlIGEgbWVzc2FnZSBwYXNzZXMgYWNyb3NzIHRo ZQ0KICAgSW50ZXJuZXQgZnJvbSBvbmUgb3JnYW5pemF0aW9uIHRvIGFub3RoZXIuICBJdCBpcyBi ZXlvbmQgdGhlIHNjb3BlIG9mDQogICB0aGlzIGRvY3VtZW50IHRvIGRlc2NyaWJlIGF1dGhlbnRp Y2F0aW9uIG1lY2hhbmlzbXMgdGhhdCBjYW4gYmUNCiAgIGRlcGxveWVkIHdpdGhpbiBhbiBvcmdh bml6YXRpb24uDQoNCiAgIFRoZSBtZWNoYW5pc20gb2YgdGhpcyBkb2N1bWVudCBhbHNvIHNlZWtz IHRvIGF1dGhlbnRpY2F0ZSB0aGUgbWFpbGJveA0KICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBNT1NU IFJFQ0VOVCBpbnRyb2R1Y3Rpb24gb2YgYSBtZXNzYWdlIGludG8gdGhlDQogICBtYWlsIGRlbGl2 ZXJ5IHN5c3RlbS4gIEluIHNpbXBsZSBjYXNlcywgdGhpcyBpcyB3aG8gdGhlIG1haWwgaXMgZnJv bS4NCiAgIEhvd2V2ZXIsIGluIHRoZSBjYXNlIG9mIGEgdGhpcmQtcGFydHkgbWFpbGVyLCBhIGZv cndhcmRlciBvciBhDQogICBtYWlsaW5nIGxpc3Qgc2VydmVyLCB0aGUgYWRkcmVzcyBiZWluZyBh dXRoZW50aWNhdGVkIGlzIHRoYXQgb2YgdGhlDQogICB0aGlyZCBwYXJ0eSwgdGhlIGZvcndhcmRl ciBvciB0aGUgbWFpbGluZyBsaXN0Lg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICBFeHBp cmVzIC0gRmVicnVhcnkgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQogICAgICAgICAg ICAgICAgICAgU2VuZGVyIElEOiBBdXRoZW50aWNhdGluZyBFLU1haWwgICAgICAgIEF1Z3VzdCAy MDA0DQoNCg0KICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBtZWFucyB0byBhdXRoZW50aWNhdGUg dGhlIERPTUFJTiBvZiB0aGUNCiAgIGFwcHJvcHJpYXRlIGVtYWlsIGFkZHJlc3M7IGl0IGlzIG5v dCBkaXJlY3RlZCBhdCB0aGUgbG9jYWwtcGFydC4gIEENCiAgIGRvbWFpbiBvd25lciBnZXRzIHRv IGRldGVybWluZSB3aGljaCBTTVRQIGNsaWVudHMgc3BlYWsgb24gYmVoYWxmIG9mDQogICBhZGRy ZXNzZXMgd2l0aGluIHRoZSBkb21haW47IGEgcmVzcG9uc2libGUgZG9tYWluIG93bmVyIHNob3Vs ZCBub3QNCiAgIGF1dGhvcml6ZSBTTVRQIGNsaWVudHMgdGhhdCB3aWxsIGxpZSBhYm91dCBsb2Nh bCBwYXJ0cy4NCg0KICAgSW4gdGhlIGxvbmcgcnVuLCBvbmNlIHRoZSBkb21haW4gb2YgdGhlIHNl bmRlciBpcyBhdXRoZW50aWNhdGVkLCBpdA0KICAgd2lsbCBiZSBwb3NzaWJsZSB0byB1c2UgdGhh dCBkb21haW4gYXMgcGFydCBvZiBhIG1lY2hhbmlzbSB0bw0KICAgZGV0ZXJtaW5lIHRoZSBsaWtl bGlob29kIHRoYXQgYSBnaXZlbiBtZXNzYWdlIGlzIHNwYW0sIHVzaW5nLCBmb3INCiAgIGV4YW1w bGUsIHJlcHV0YXRpb24gYW5kIGFjY3JlZGl0YXRpb24gc2VydmljZXMuIChUaGVzZSBzZXJ2aWNl cyBhcmUNCiAgIG5vdCB0aGUgc3ViamVjdCBvZiB0aGUgcHJlc2VudCBtZWNoYW5pc20sIGJ1dCBp dCBzaG91bGQgZW5hYmxlIHRoZW0uKQ0KDQoNCjIuMiBOZWdhdGl2ZSBQcm9ibGVtIFN0YXRlbWVu dA0KDQogICBGb2xsb3dpbmcgYXJlIHNldmVyYWwgYWx0ZXJuYXRlIHF1ZXN0aW9ucywgd2hpY2gg dGhpcyBzcGVjaWZpY2F0aW9uDQogICBtYWtlcyBubyBhdHRlbXB0IHRvIGFuc3dlcjoNCg0KICAg MS4gSXMgdGhlIGhvc3QgYXQgYSBwYXJ0aWN1bGFyIElQIGFkZHJlc3MgYXV0aG9yaXplZCB0byBh Y3QgYXMgYW4NCiAgICAgIFNNVFAgY2xpZW50Pw0KDQogICAyLiBJcyBhbiBTTVRQIGNsaWVudCBh dXRob3JpemVkIHRvIHVzZSBhIHBhcnRpY3VsYXIgZG9tYWluIG5hbWUgaW4NCiAgICAgIGl0cyBT TVRQIEVITE8gY29tbWFuZD8NCg0KICAgMy4gSXMgYW4gU01UUCBjbGllbnQgYXV0aG9yaXplZCB0 byB1c2UgYSBwYXJ0aWN1bGFyIGVtYWlsIGFkZHJlc3MgaW4NCiAgICAgIGFuIFNNVFAgIk1BSUwg RlJPTToiIGNvbW1hbmQ/DQoNCiAgIDQuIFdhcyBhIG1lc3NhZ2UgcmVhbGx5IGF1dGhvcmVkIGJ5 IHdobyBpdCBjbGFpbXMgdG8gYmUgYXV0aG9yZWQgYnk/DQoNCg0KMy4gRGVjaXNpb24gTW9kZWwN Cg0KICAgVGhlIGVzc2VuY2Ugb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGlzOg0KDQogICBHaXZlbiBh biBlbWFpbCBtZXNzYWdlLCBhbmQgZ2l2ZW4gYW4gSVAgYWRkcmVzcyBmcm9tIHdoaWNoIGl0IGhh cw0KICAgYmVlbiAob3Igd2lsbCBiZSkgcmVjZWl2ZWQsIGlzIHRoZSBTTVRQIGNsaWVudCBhdCB0 aGF0IElQIGFkZHJlc3MNCiAgIGF1dGhvcml6ZWQgdG8gc2VuZCB0aGF0IGVtYWlsIG1lc3NhZ2U/ DQoNCiAgIFRoaXMgcXVlc3Rpb24gd2lsbCB1c3VhbGx5IGJlIGFza2VkIGJ5IGFuIFNNVFAgc2Vy dmVyIGFzIHBhcnQgb2YNCiAgIGRlY2lkaW5nIHdoZXRoZXIgdG8gYWNjZXB0IGFuIGluY29taW5n IG1haWwgbWVzc2FnZS4gIEhvd2V2ZXIsIHRoaXMNCiAgIHF1ZXN0aW9uIGNvdWxkIGFsc28gYmUg YXNrZWQgbGF0ZXIgYnkgYSBkaWZmZXJlbnQgcGFydHkuICBBbiBNVUEsIGZvcg0KICAgZXhhbXBs ZSwgY291bGQgdXNlIHRoZSByZXN1bHQgb2YgdGhpcyBxdWVzdGlvbiB0byBkZXRlcm1pbmUgaG93 IHRvDQogICBmaWxlIG9yIHByZXNlbnQgYSBtZXNzYWdlLg0KDQoNCg0KDQoNCg0KDQoNCkx5b24s IFdvbmcgICAgICAgICAgICAgRXhwaXJlcyAtIEZlYnJ1YXJ5IDIwMDUgICAgICAgICAgICAgICBb UGFnZSA0XQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJRDogQXV0aGVudGljYXRpbmcg RS1NYWlsICAgICAgICBBdWd1c3QgMjAwNA0KDQoNCiAgIFRoZXJlIGFyZSBmb3VyIHN0ZXBzIHRv IGFuc3dlcmluZyB0aGlzIHF1ZXN0aW9uOg0KDQogICAoMSkgIEZyb20gdGhlIGhlYWRlcnMgb2Yg dGhlIGVtYWlsIG1lc3NhZ2UsIGV4dHJhY3QgdGhlICJwdXJwb3J0ZWQNCiAgICAgICByZXNwb25z aWJsZSBhZGRyZXNzIi4gIFRoaXMgaXMgdGhlIG1haWxib3ggdGhhdCB0aGUgbWVzc2FnZQ0KICAg ICAgIGNsYWltcyBpcyByZXNwb25zaWJsZSBmb3IgdGhlIG1vc3QgcmVjZW50IGludHJvZHVjdGlv biBvZiB0aGUNCiAgICAgICBtZXNzYWdlIGludG8gdGhlIGRlbGl2ZXJ5IHN5c3RlbS4gIFRoaXMg c3RlcCBpcyBkZXNjcmliZWQgaW4NCiAgICAgICBkZXRhaWwgaW4gc2VjdGlvbiA0IGJlbG93LiAg QSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLA0KICAgICAgIFtTdWJtaXR0ZXJdLCBkZXNjcmliZXMg YW4gU01UUCBleHRlbnNpb24gdGhhdCBhbGxvd3MgYW4gU01UUA0KICAgICAgIHNlcnZlciB0byBw ZXJmb3JtIHRoaXMgY2hlY2sgYXQgdGhlIHRpbWUgb2YgdGhlIFNNVFAgTUFJTA0KICAgICAgIGNv bW1hbmQgaW5zdGVhZCBvZiB0aGUgU01UUCBEQVRBIGNvbW1hbmQuDQoNCiAgICgyKSAgRXh0cmFj dCB0aGUgZG9tYWluIHBhcnQgb2YgdGhlIHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzLg0K ICAgICAgIENhbGwgdGhpcyB0aGUgInB1cnBvcnRlZCByZXNwb25zaWJsZSBkb21haW4iLg0KDQog ICAoMykgIENhbGwgdGhlIGNoZWNrX2hvc3QgZnVuY3Rpb24gZGVmaW5lZCBpbiBbUHJvdG9jb2xd LCBwYXNzaW5nIHRoZQ0KICAgICAgIGZvbGxvd2luZyBwYXJhbWV0ZXJzOg0KICAgICAgICAgYS4g VGhlIElQIGFkZHJlc3MgKGVpdGhlciBJUHY0IG9yIElQdjYpIGZyb20gd2hpY2ggdGhlIG1lc3Nh Z2UNCiAgICAgICBpcyBiZWluZyBvciBoYXMgYmVlbiByZWNlaXZlZC4NCiAgICAgICAgIGIuIFRo ZSBwdXJwb3J0ZWQgcmVzcG9uc2libGUgZG9tYWluIGZyb20gc3RlcCAoMikgYWJvdmUuDQogICAg ICAgICBjLiBUaGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3MgZnJvbSBzdGVwICgxKSBh Ym92ZS4NCg0KICAgVGhlIHJlc3VsdCBvZiB0aGUgY2hlY2tfaG9zdCBmdW5jdGlvbiBpcyBvbmUg b2YgdGhlIHZhbHVlcyAiTmV1dHJhbCIsDQogICAiUGFzcyIsICJGYWlsIiwgIlNvZnRGYWlsIiwg Ik5vbmUiLCAiVGVtcEVycm9yIiBvciAiUGVybUVycm9yIi4NCiAgIFNlY3Rpb24gNSBkZXNjcmli ZXMgaG93IHRoZXNlIHJlc3VsdHMgYXJlIHVzZWQgYnkgTVRBcyByZWNlaXZpbmcNCiAgIG1lc3Nh Z2VzLiAgVGhpcyBzcGVjaWZpY2F0aW9uIGltcG9zZXMgbm8gcmVxdWlyZW1lbnRzIG9uIHBhcnRp ZXMNCiAgIHBlcmZvcm1pbmcgdGhpcyB0ZXN0IGluIG90aGVyIGVudmlyb25tZW50cy4NCg0KDQo0 LiBEZXRlcm1pbmluZyB0aGUgUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MNCg0KICAgVGhl IHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzIChQUkEpIG9mIGEgbWVzc2FnZSBNVVNUIGJl DQogICBkZXRlcm1pbmVkIHVzaW5nIHRoZSBhbGdvcml0aG0gZGVzY3JpYmVkIGluIFtQUkFdLg0K DQogICBJZiB0aGUgU2VuZGVyIElEIGNoZWNrIGlzIGJlaW5nIHBlcmZvcm1lZCBieSBhbiBNVEEg YXMgcGFydCBvZg0KICAgcmVjZWl2aW5nIGFuIGUtbWFpbCBtZXNzYWdlLCBhbmQgdGhlIFBSQSBh bGdvcml0aG0gY2Fubm90IGRldGVybWluZSBhDQogICBQUkEsIHRoZW4gdGhlIG1lc3NhZ2UgU0hP VUxEIGJlIHJlamVjdGVkIHdpdGggZXJyb3IgIjU1MCA1LjEuNw0KICAgTWlzc2luZyBwdXJwb3J0 ZWQgUmVzcG9uc2libGUgQWRkcmVzcyIuDQoNCg0KNS4gQWN0aW9ucyBCYXNlZCBvbiB0aGUgRGVj aXNpb24NCg0KICAgV2hlbiB0aGUgU2VuZGVyIElEIHRlc3QgaXMgdXNlZCBieSBhbiBTTVRQIHNl cnZlciBhcyBwYXJ0IG9mDQogICByZWNlaXZpbmcgYSBtZXNzYWdlLCB0aGUgc2VydmVyIHNob3Vs ZCB0YWtlIHRoZSBhY3Rpb25zIGRlc2NyaWJlZCBieQ0KICAgdGhpcyBzZWN0aW9uLg0KDQogICBU aGUgY2hlY2tfaG9zdCBmdW5jdGlvbiByZXR1cm5zIG9uZSBvZiB0aGUgZm9sbG93aW5nIHJlc3Vs dHMuIFNlZQ0KICAgW1Byb3RvY29sXSBmb3IgdGhlIG1lYW5pbmcgb2YgdGhlc2UgcmVzdWx0cy4N Cg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICBFeHBpcmVzIC0gRmVicnVhcnkgMjAwNSAg ICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQogICAgICAgICAgICAgICAgICAgU2VuZGVyIElEOiBB dXRoZW50aWNhdGluZyBFLU1haWwgICAgICAgIEF1Z3VzdCAyMDA0DQoNCg0KNS4xIE5ldXRyYWwg b3IgTm9uZSBvciBQZXJtRXJyb3INCg0KICAgQW4gU01UUCBzZXJ2ZXIgcmVjZWl2aW5nIG9uZSBv ZiB0aGVzZSByZXN1bHRzIFNIT1VMRCBOT1QgcmVqZWN0IHRoZQ0KICAgbWVzc2FnZSBmb3IgdGhp cyByZWFzb24gYWxvbmUsIGJ1dCBNQVkgc3ViamVjdCB0aGUgbWVzc2FnZSB0bw0KICAgaGVpZ2h0 ZW5lZCBzY3J1dGlueSBieSBvdGhlciBhbnRpLXNwYW0gbWVhc3VyZXMsIGFuZCBNQVkgcmVqZWN0 IHRoZQ0KICAgbWVzc2FnZSBhcyBhIHJlc3VsdCBvZiB0aGlzIGhlaWdodGVuZWQgc2NydXRpbnku DQoNCjUuMiBQYXNzDQoNCiAgIEFuIFNNVFAgc2VydmVyIHJlY2VpdmluZyB0aGlzIHJlc3VsdCBT SE9VTEQgdHJlYXQgdGhlIG1lc3NhZ2UgYXMNCiAgIGF1dGhlbnRpYy4gIEl0IG1heSBhY2NlcHQg b3IgcmVqZWN0IHRoZSBtZXNzYWdlIGRlcGVuZGluZyBvbiBvdGhlcg0KICAgcG9saWNpZXMuDQoN CjUuMyBGYWlsDQoNCiAgIEFuIFNNVFAgc2VydmVyIHJlY2VpdmluZyB0aGlzIHJlc3VsdCBTSE9V TEQgcmVqZWN0IHRoZSBtZXNzYWdlIHdpdGggYQ0KICAgIjU1MCA1LjcuMSBTZW5kZXIgSUQgeHh4 IC0geXl5IiBTTVRQIGVycm9yLCB3aGVyZSAieHh4IiBpcyByZXBsYWNlZA0KICAgd2l0aCB0aGUg YWRkaXRpb25hbCByZWFzb24gcmV0dXJuZWQgYnkgdGhlIGNoZWNrX2hvc3QgZnVuY3Rpb24gYW5k DQogICAieXl5IiBpcyByZXBsYWNlZCB3aXRoIHRoZSBleHBsYW5hdGlvbiBzdHJpbmcgcmV0dXJu ZWQgYnkgdGhlDQogICBjaGVja19ob3N0IGZ1bmN0aW9uLg0KDQo1LjQgU29mdEZhaWwNCg0KICAg QW4gU01UUCBzZXJ2ZXIgcmVjZWl2aW5nIHRoaXMgcmVzdWx0IFNIT1VMRCBOT1QgcmVqZWN0IHRo ZSBtZXNzYWdlDQogICBmb3IgdGhpcyByZWFzb24gYWxvbmUsIGJ1dCBNQVkgc3ViamVjdCB0aGUg bWVzc2FnZSB0byBoZWlnaHRlbmVkDQogICBzY3J1dGlueSBieSBvdGhlciBhbnRpLXNwYW0gbWVh c3VyZXMsIGFuZCBNQVkgcmVqZWN0IHRoZSBtZXNzYWdlIGFzIGENCiAgIHJlc3VsdCBvZiB0aGlz IGhlaWdodGVuZWQgc2NydXRpbnkuICBBIG1lc3NhZ2UgZm9yIHdoaWNoIHRoZSByZXN1bHQNCiAg IGlzICJTb2Z0RmFpbCIgaXMgbGVzcyBsaWtlbHkgdG8gYmUgYXV0aGVudGljIHRoYW4gYSBtZXNz YWdlIGZvciB3aGljaA0KICAgdGhlIHJlc3VsdCBpcyAiTmV1dHJhbCIuDQoNCjUuNSBUZW1wRXJy b3INCg0KICAgQW4gU01UUCBzZXJ2ZXIgcmVjZWl2aW5nIHRoaXMgcmVzdWx0IE1BWSByZWplY3Qg dGhlIG1lc3NhZ2Ugd2l0aCBhDQogICAiNDUwIDQuNC4zIFNlbmRlciBJRCBjaGVjayBpcyB0ZW1w b3JhcmlseSB1bmF2YWlsYWJsZSIgZXJyb3IgY29kZS4NCiAgIEFsdGVybmF0aXZlbHksIGFuIFNN VFAgc2VydmVyIHJlY2VpdmluZyB0aGlzIHJlc3VsdCBNQVkgYWNjZXB0IGENCiAgIG1lc3NhZ2Ug YW5kIG9wdGlvbmFsbHkgc3ViamVjdCBpdCB0byBoZWlnaHRlbmVkIHNjcnV0aW55IGJ5IG90aGVy DQogICBhbnRpLXNwYW0gbWVhc3VyZXMuDQoNCg0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMN Cg0KICAgVGhpcyBlbnRpcmUgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbmV3IG1lY2hhbmlzbSBmb3Ig bWl0aWdhdGluZyBzcG9vZmVkDQogICBlbWFpbCwgd2hpY2ggaXMgdG9kYXkgYSBwZXJ2YXNpdmUg c2VjdXJpdHkgcHJvYmxlbSBpbiB0aGUgSW50ZXJuZXQuDQoNCiAgIEFzc3VtaW5nIHRoYXQgdGhp cyBtZWNoYW5pc20gaXMgd2lkZWx5IGRlcGxveWVkLCB0aGUgZm9sbG93aW5nDQogICBzZWN0aW9u cyBkZXNjcmliZSBjb3VudGVyLWF0dGFja3MgdGhhdCBjb3VsZCBiZSB1c2VkIHRvIGRlZmVhdCB0 aGlzDQogICBtZWNoYW5pc20uDQoNCg0KDQoNCkx5b24sIFdvbmcgICAgICAgICAgICAgRXhwaXJl cyAtIEZlYnJ1YXJ5IDIwMDUgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KICAgICAgICAgICAg ICAgICAgIFNlbmRlciBJRDogQXV0aGVudGljYXRpbmcgRS1NYWlsICAgICAgICBBdWd1c3QgMjAw NA0KDQoNCjYuMSBETlMgQXR0YWNrcw0KDQogICBUaGUgbmV3IG1lY2hhbmlzbSBpcyBlbnRpcmVs eSBkZXBlbmRlbnQgb24gRE5TIGxvb2t1cHMsIGFuZCBpcw0KICAgdGhlcmVmb3JlIG9ubHkgYXMg c2VjdXJlIGFzIEROUy4gIEFuIGF0dGFja2VyIGJlbnQgb24gc3Bvb2ZpbmcNCiAgIG1lc3NhZ2Vz IGNvdWxkIGF0dGVtcHQgdG8gZ2V0IGhpcyBtZXNzYWdlcyBhY2NlcHRlZCBieSBzZW5kaW5nIGZv cmdlZA0KICAgYW5zd2VycyB0byBETlMgcXVlcmllcy4NCg0KICAgQW4gTVRBIGNvdWxkIGxhcmdl bHkgZGVmZWF0IHN1Y2ggYW4gYXR0YWNrIGJ5IHVzaW5nIGEgcHJvcGVybHkNCiAgIHBhcmFub2lk IEROUyByZXNvbHZlci4gIEROU1NFQyBtYXkgdWx0aW1hdGVseSBwcm92aWRlIGEgd2F5IHRvDQog ICBjb21wbGV0ZWx5IG5ldXRyYWxpemUgdGhpcyBjbGFzcyBvZiBhdHRhY2tzLg0KDQoNCjYuMiBU Q1AgQXR0YWNrcw0KDQogICBUaGlzIG1lY2hhbmlzbSBpcyBkZXNpZ25lZCB0byBiZSB1c2VkIGlu IGNvbmp1bmN0aW9uIHdpdGggU01UUCBvdmVyDQogICBUQ1AuICBBIHN1ZmZpY2llbnRseSByZXNv dXJjZWZ1bCBhdHRhY2tlciBtaWdodCBiZSBhYmxlIHRvIHNlbmQgVENQDQogICBwYWNrZXRzIHdp dGggZm9yZ2VkIGZyb20tYWRkcmVzc2VzLCBhbmQgdGh1cyBleGVjdXRlIGFuIGVudGlyZSBTTVRQ DQogICBzZXNzaW9uIHRoYXQgYXBwZWFycyB0byBjb21lIGZyb20gc29tZXdoZXJlIG90aGVyIHRo YW4gaXRzIHRydWUNCiAgIG9yaWdpbi4NCg0KICAgU3VjaCBhbiBhdHRhY2sgcmVxdWlyZXMgZ3Vl c3Npbmcgd2hhdCBUQ1Agc2VxdWVuY2UgbnVtYmVycyBhbiBTTVRQDQogICBzZXJ2ZXIgd2lsbCB1 c2UuIEl0IGFsc28gcmVxdWlyZXMgdHJhbnNtaXR0aW5nIGNvbXBsZXRlbHkgaW4gdGhlDQogICBi bGluZCAtIHRoZSBhdHRhY2sgd2lsbCBiZSB1bmFibGUgaGVhciBhbnkgb2YgdGhlIHNlcnZlcidz IHNpZGUgb2YNCiAgIHRoZSBjb252ZXJzYXRpb24uDQoNCiAgIEF0dGFja3Mgb2YgdGhpcyBzb3J0 IGNhbiBiZSBhbWVsaW9yYXRlZCBpZiBJUCBnYXRld2F5cyByZWZ1c2UgdG8NCiAgIGZvcndhcmQg cGFja2V0cyB3aGVuIHRoZSBzb3VyY2UgYWRkcmVzcyBpcyBjbGVhcmx5IGJvZ3VzLg0KDQoNCjYu MyBGb3JnZWQgU2VuZGVyIEF0dGFja3MNCg0KICAgVGhpcyBtZWNoYW5pc20gY2hvb3NlcyBhIHB1 cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzIGZyb20gb25lIG9mIGENCiAgIG51bWJlciBvZiBt ZXNzYWdlIGhlYWRlcnMsIGFuZCB0aGVuIHVzZXMgdGhhdCBhZGRyZXNzIGZvciB2YWxpZGF0aW9u Lg0KICAgQSBtZXNzYWdlIHdpdGggYSB0cnVlIFJlc2VudC1Gcm9tIGhlYWRlciAoZm9yIGV4YW1w bGUpLCBidXQgYSBmb3JnZWQNCiAgIEZyb20gaGVhZGVyIHdpbGwgYmUgYWNjZXB0ZWQuICBTaW5j ZSBtYW55IE1VQXMgZG8gbm90IGRpc3BsYXkgYWxsIG9mDQogICB0aGUgaGVhZGVycyBvZiByZWNl aXZlZCBtZXNzYWdlcywgdGhlIG1lc3NhZ2Ugd2lsbCBhcHBlYXIgdG8gYmUNCiAgIGZvcmdlZCB3 aGVuIGRpc3BsYXllZC4NCg0KICAgSW4gb3JkZXIgdG8gbmV1dHJhbGl6ZSB0aGlzIGF0dGFjaywg TVVBcyB3aWxsIG5lZWQgdG8gc3RhcnQNCiAgIGRpc3BsYXlpbmcgYXQgbGVhc3QgdGhlIGhlYWRl ciB0aGF0IHdhcyB2ZXJpZmllZC4NCg0KDQo2LjQgQWRkcmVzcyBTcGFjZSBIaWphY2tpbmcNCg0K ICAgVGhpcyBtZWNoYW5pc20gYXNzdW1lcyB0aGUgaW50ZWdyaXR5IG9mIElQIGFkZHJlc3Mgc3Bh Y2UgZm9yDQogICBkZXRlcm1pbmluZyB3aGV0aGVyIGEgZ2l2ZW4gY2xpZW50IGlzIGF1dGhvcml6 ZWQgdG8gc2VuZCBtZXNzYWdlcw0KICAgZnJvbSBhIGdpdmVuIFBSQS4gIEluIGFkZGl0aW9uIHRv IHRoZSBUQ1AgYXR0YWNrIGdpdmVuIGluIHNlY3Rpb24NCiAgIDYuMiwgYSBzdWZmaWNpZW50bHkg cmVzb3VyY2VmdWwgYXR0YWNrZXIgbWlnaHQgYmUgYWJsZSB0byBhbHRlciB0aGUNCiAgIElQIHJv dXRpbmcgc3RydWN0dXJlIHRvIHBlcm1pdCB0d28td2F5IGNvbW11bmljYXRpb24gdXNpbmcgYQ0K DQoNCkx5b24sIFdvbmcgICAgICAgICAgICAgRXhwaXJlcyAtIEZlYnJ1YXJ5IDIwMDUgICAgICAg ICAgICAgICBbUGFnZSA3XQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJRDogQXV0aGVu dGljYXRpbmcgRS1NYWlsICAgICAgICBBdWd1c3QgMjAwNA0KDQoNCiAgIHNwZWNpZmllZCBJUCBh ZGRyZXNzLiAgSXQgd291bGQgdGhlbiBiZSBwb3NzaWJsZSB0byBleGVjdXRlIGFuIFNNVFANCiAg IHNlc3Npb24gdGhhdCBhcHBlYXJzIHRvIGNvbWUgZnJvbSBhbiBhdXRob3JpemVkIGFkZHJlc3Ms IHdpdGhvdXQgdGhlDQogICBuZWVkIHRvIGd1ZXNzIFRDUCBzZXF1ZW5jZSBudW1iZXJzIG9yIHRy YW5zbWl0IGluIHRoZSBibGluZC4NCg0KICAgU3VjaCBhbiBhdHRhY2sgbWlnaHQgb2NjdXIgaWYg dGhlIGF0dGFja2VyIG9idGFpbmVkIGFjY2VzcyB0byBhDQogICByb3V0ZXIgd2hpY2ggcGFydGlj aXBhdGVzIGluIGV4dGVybmFsIEJHUCByb3V0aW5nLiAgU3VjaCBhIHJvdXRlcg0KICAgY291bGQg YWR2ZXJ0aXNlIGEgbW9yZSBzcGVjaWZpYyByb3V0ZSB0byBhIHJvZ3VlIFNNVFAgY2xpZW50LA0K ICAgdGVtcG9yYXJpbHkgb3ZlcnJpZGluZyB0aGUgbGVnaXRpbWF0ZSBvd25lciBvZiB0aGUgYWRk cmVzcy4NCg0KDQo3LiBJbXBsZW1lbnRhdGlvbiBHdWlkYW5jZQ0KDQogICBUaGlzIHNlY3Rpb24g ZGVzY3JpYmVzIHRoZSBhY3Rpb25zIHRoYXQgY2VydGFpbiBtZW1iZXJzIG9mIHRoZQ0KICAgSW50 ZXJuZXQgZW1haWwgZWNvc3lzdGVtIG11c3QgdGFrZSB0byBiZSBjb21wbGlhbnQgd2l0aCB0aGlz DQogICBzcGVjaWZpY2F0aW9uLg0KDQoNCjcuMSBTaW1wbGUgRS1tYWlsZXJzDQoNCiAgIEEgZG9t YWluIHRoYXQgaW5qZWN0cyBvcmlnaW5hbCBlbWFpbCBpbnRvIHRoZSBJbnRlcm5ldCwgdXNpbmcg aXRzIG93bg0KICAgbmFtZSBpbiBGcm9tIGhlYWRlcnMsIG5lZWQgZG8gbm90aGluZyB0byBiZSBj b21wbGlhbnQuICBIb3dldmVyLCBzdWNoDQogICBkb21haW5zIFNIT1VMRCBwdWJsaXNoIGUtbWFp bCBwb2xpY3kgcmVjb3JkcyBpbiBETlMuDQoNCg0KNy4yIEUtTWFpbCBGb3J3YXJkZXJzDQoNCiAg IEEgcHJvZ3JhbSB0aGF0IGZvcndhcmRzIHJlY2VpdmVkIG1haWwgdG8gb3RoZXIgYWRkcmVzc2Vz IE1VU1QgYWRkIGFuDQogICBhcHByb3ByaWF0ZSBoZWFkZXIgdGhhdCBjb250YWlucyBhbiBlbWFp bCBhZGRyZXNzIHRoYXQgaXQgaXMNCiAgIGF1dGhvcml6ZWQgdG8gdXNlLiAgU3VjaCBwcm9ncmFt cyBTSE9VTEQgdXNlIHRoZSBSZXNlbnQtRnJvbSBoZWFkZXINCiAgIGZvciB0aGlzIHB1cnBvc2Uu DQoNCiAgIEFkZGl0aW9uYWxseSwgZS1tYWlsIGZvcndhcmRlcnMgU0hPVUxEIHB1Ymxpc2ggU2Vu ZGVyIElEIHJlY29yZHMgZm9yDQogICB0aGVpciBkb21haW5zLCBhbmQgU0hPVUxEIHVzZSBNVEFz IGZvciB3aGljaCB0aGUgU2VuZGVyIElEIGNoZWNrDQogICB5aWVsZHMgYSAicGFzcyIgcmVzdWx0 Lg0KDQogICBTb21lIG9mIHRvZGF5J3MgZm9yd2FyZGVycyBhbHJlYWR5IGFkZCBhbiBhcHByb3By aWF0ZSBoZWFkZXINCiAgIChhbHRob3VnaCBtYW55IG9mIHRoZW0gdXNlIFNlbmRlciByYXRoZXIg dGhhbiBSZXNlbnQtRnJvbS4pDQoNCg0KNy4zIE1haWxpbmcgTGlzdCBTZXJ2ZXJzDQoNCiAgIEEg bWFpbGluZyBsaXN0IHNlcnZlciBNVVNUIGFkZCBhbiBhcHByb3ByaWF0ZSBoZWFkZXIgdGhhdCBj b250YWlucyBhbg0KICAgZW1haWwgYWRkcmVzcyB0aGF0IGl0IGlzIGF1dGhvcml6ZWQgdG8gdXNl LiAgU3VjaCBwcm9ncmFtcyBTSE9VTEQgdXNlDQogICB0aGUgUmVzZW50LUZyb20gaGVhZGVyIGZv ciB0aGlzIHB1cnBvc2UuDQoNCiAgIEFkZGl0aW9uYWxseSwgbWFpbGluZyBsaXN0IHNlcnZlcnMg U0hPVUxEIHB1Ymxpc2ggU2VuZGVyIElEIHJlY29yZHMNCiAgIGZvciB0aGVpciBkb21haW5zLCBh bmQgU0hPVUxEIHVzZSBNVEFzIGZvciB3aGljaCB0aGUgU2VuZGVyIElEIGNoZWNrDQogICB5aWVs ZHMgYSAicGFzcyIgcmVzdWx0Lg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICBFeHBpcmVz IC0gRmVicnVhcnkgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQogICAgICAgICAgICAg ICAgICAgU2VuZGVyIElEOiBBdXRoZW50aWNhdGluZyBFLU1haWwgICAgICAgIEF1Z3VzdCAyMDA0 DQoNCg0KICAgTW9zdCBvZiB0b2RheSdzIG1haWxpbmcgbGlzdCBzb2Z0d2FyZSBhbHJlYWR5IGFk ZHMgYW4gYXBwcm9wcmlhdGUNCiAgIGhlYWRlciAoYWx0aG91Z2ggbW9zdCBvZiB0aGVtIHVzZSBT ZW5kZXIgcmF0aGVyIHRoYW4gUmVzZW50LUZyb20pLg0KDQoNCjcuNCBUaGlyZC1QYXJ0eSBNYWls ZXJzDQoNCiAgIEEgcHJvZ3JhbSB0aGF0IHNlbmRzIG1haWwgb24gYmVoYWxmIG9mIGFub3RoZXIg dXNlciBNVVNUIGFkZCBhbg0KICAgYXBwcm9wcmlhdGUgaGVhZGVyIHRoYXQgY29udGFpbnMgYW4g ZW1haWwgYWRkcmVzcyB0aGF0IGl0IGlzDQogICBhdXRob3JpemVkIHRvIHVzZS4gIFN1Y2ggcHJv Z3JhbXMgU0hPVUxEIHVzZSB0aGUgU2VuZGVyIGhlYWRlciBmb3INCiAgIHRoaXMgcHVycG9zZS4N Cg0KICAgQWRkaXRpb25hbGx5LCB0aGlyZC1wYXJ0IG1haWxlcnMgc2VydmVycyBTSE9VTEQgcHVi bGlzaCBTZW5kZXIgSUQNCiAgIHJlY29yZHMgZm9yIHRoZWlyIGRvbWFpbnMsIGFuZCBTSE9VTEQg dXNlIE1UQXMgZm9yIHdoaWNoIHRoZSBTZW5kZXINCiAgIElEIGNoZWNrIHlpZWxkcyBhICJwYXNz IiByZXN1bHQuDQoNCiAgIE1hbnksIGJ1dCBub3QgYWxsLCBvZiB0b2RheSdzIHRoaXJkLXBhcnR5 IG1haWxlcnMgYXJlIGFscmVhZHkNCiAgIGNvbXBsaWFudC4NCg0KDQo3LjUgTVVBIEltcGxlbWVu dGVycw0KDQogICBXaGVuIGRpc3BsYXlpbmcgYSByZWNlaXZlZCBtZXNzYWdlLCBhbiBNVUEgU0hP VUxEIGRpc3BsYXkgdGhlDQogICBwdXJwb3J0ZWQgcmVzcG9uc2libGUgYWRkcmVzcyBhcyBkZWZp bmVkIGJ5IHRoaXMgZG9jdW1lbnQgd2hlbmV2ZXINCiAgIHRoYXQgYWRkcmVzcyBkaWZmZXJzIGZy b20gdGhlIFJGQyAyODIyIEZyb20gYWRkcmVzcy4gIFRoaXMgZGlzcGxheQ0KICAgU0hPVUxEIGJl IGluIGFkZGl0aW9uIHRvIHRoZSBSRkMgMjgyMiBGcm9tIGFkZHJlc3MuDQoNCiAgIFdoZW4gYSBy ZWNlaXZlZCBtZXNzYWdlIGNvbnRhaW5zIG11bHRpcGxlIGhlYWRlcnMgdGhhdCBtaWdodCBiZSB1 c2VkDQogICBmb3IgdGhlIHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzIGRldGVybWluYXRp b24sIGFuIE1VQSBzaG91bGQNCiAgIGNvbnNpZGVyIGRpc3BsYXlpbmcgYWxsIG9mIHRoZW0uIFRo YXQgaXMsIGlmIGEgbWVzc2FnZSBjb250YWlucw0KICAgc2V2ZXJhbCBSZXNlbnQtRnJvbSdzLCBh IFNlbmRlciBhbmQgYSBGcm9tLCBhbiBNVUEgc2hvdWxkIGNvbnNpZGVyDQogICBkaXNwbGF5aW5n IGFsbCBvZiB0aGVtLg0KDQoNCjguIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1 bWVudCBjb250YWlucyBubyBhY3Rpb25zIGZvciBJQU5BLg0KDQoNCjkuIEFja25vd2xlZGdlbWVu dHMNCg0KICAgVmFyaWF0aW9ucyBvbiB0aGUgaWRlYSBvZiB1c2luZyBhIEROUyByZWNvcmQgdG8g Y2hlY2sgdGhlIGxlZ2l0aW1hY3kNCiAgIG9mIGFuIGVtYWlsIGFkZHJlc3MgaGF2ZSBvY2N1cnJl ZCBtdWx0aXBsZSB0aW1lcy4gVGhlIGVhcmxpZXN0IGtub3duDQogICB3b3JrIGlzIFtWaXhpZV07 IG90aGVycyBpbmNsdWRlIFtSTVhdLCBbU1BGXSBhbmQgW0NhbGxlcklEXS4NCg0KICAgVGhlIGN1 cnJlbnQgZG9jdW1lbnQgYm9ycm93cyBoZWF2aWx5IGZyb20gZWFjaCBvZiB0aGUgYWJvdmUsIGFu ZA0KICAgaW5jb3Jwb3JhdGVzIGlkZWFzIHByb3Bvc2VkIGJ5IG1hbnkgbWVtYmVycyBvZiB0aGUg TUFSSUQgd29ya2luZw0KICAgZ3JvdXAuICBUaGUgY29udHJpYnV0aW9ucyBvZiBlYWNoIG9mIHRo ZSBhYm92ZSBhcmUgZ3JhdGVmdWxseQ0KICAgYWNrbm93bGVkZ2VkLg0KDQoNCg0KTHlvbiwgV29u ZyAgICAgICAgICAgICBFeHBpcmVzIC0gRmVicnVhcnkgMjAwNSAgICAgICAgICAgICAgIFtQYWdl IDldDQoMDQogICAgICAgICAgICAgICAgICAgU2VuZGVyIElEOiBBdXRoZW50aWNhdGluZyBFLU1h aWwgICAgICAgIEF1Z3VzdCAyMDA0DQoNCg0KDQoxMC4gUmVmZXJlbmNlcw0KDQoxMC4xIE5vcm1h dGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtQUkFdICAgICAgIEouIEx5b24sICJQdXJwb3J0ZWQgUmVz cG9uc2libGUgQWRkcmVzcyBpbiBFLU1haWwNCiAgICAgICAgICAgICAgIE1lc3NhZ2VzIiwgZHJh ZnQtaWV0Zi1tYXJpZC1wcmEtMDAuICBXb3JrIGluIHByb2dyZXNzLg0KDQogICBbUHJvdG9jb2xd ICBNLiBXb25nIGFuZCBNLiBMZW50Y3puZXIsICJUaGUgU1BGIFJlY29yZCBGb3JtYXQgYW5kIFRl c3QNCiAgICAgICAgICAgICAgIFByb3RvY29sIiwgZHJhZnQtaWV0Zi1tYXJpZC1wcm90b2NvbC0w MS4gIFdvcmsgaW4NCiAgICAgICAgICAgICAgIHByb2dyZXNzLg0KDQogICBbUkZDMjExOV0gICBT LiBCcmFkbmVyLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAg ICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgUkZDIDIxMTkuDQoNCg0KMTAuMiBJbmZvcm1h dGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtDYWxsZXJJRF0gIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbiwg Q2FsbGVyIElEIGZvciBFLU1haWwgVGVjaG5pY2FsDQogICAgICAgICAgICAgICBTcGVjaWZpY2F0 aW9uLA0KICAgICAgICAgICAgICAgaHR0cDovL3d3dy5taWNyb3NvZnQuY29tL21zY29ycC90d2Mv cHJpdmFjeS9zcGFtX2NhbGxlcmlkDQogICAgICAgICAgICAgICAubXNweC4NCg0KICAgW1JNWF0g ICAgICAgSC4gRGFuaXNjaCwgIlRoZSBSTVggRE5TIFJSIGFuZCBtZXRob2QgZm9yIGxpZ2h0d2Vp Z2h0DQogICAgICAgICAgICAgICBTTVRQIHNlbmRlciBhdXRob3JpemF0aW9uIiwgZHJhZnQtZGFu aXNjaC1kbnMtcnItc210cC0wNC4NCiAgICAgICAgICAgICAgIFdvcmsgaW4gcHJvZ3Jlc3MuDQoN CiAgIFtTUEZdICAgICAgIE0uIExlbnRjem5lciBhbmQgTS4gV29uZywgIlNlbmRlciBQb2xpY3kg RnJhbWV3b3JrIChTUEYpOg0KICAgICAgICAgICAgICAgQSBDb252ZW50aW9uIHRvIERlc2NyaWJl IEhvc3RzIEF1dGhvcml6ZWQgdG8gU2VuZCBTTVRQDQogICAgICAgICAgICAgICBUcmFmZmljIiwg ZHJhZnQtbWVuZ3dvbmctc3BmLTAxLiAgV29yayBpbiBwcm9ncmVzcy4NCg0KICAgW1N1Ym1pdHRl cl0gRS4gQWxsbWFuIGFuZCBILiBLYXR6LCAiU01UUCBTZXJ2aWNlIEV4dGVuc2lvbiBmb3INCiAg ICAgICAgICAgICAgIEluZGljYXRpbmcgdGhlIFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBvZiBhbiBF LW1haWwNCiAgICAgICAgICAgICAgIE1lc3NhZ2UiLCBkcmFmdC1pZXRmLW1hcmlkLXN1Ym1pdHRl ci0wMy4gIFdvcmsgaW4NCiAgICAgICAgICAgICAgIHByb2dyZXNzLg0KDQogICBbVml4aWVdICAg ICBQYXVsIFZpeGllLCAiUmVwdWRpYXRpbmcgTWFpbC1Gcm9tIiwNCiAgICAgICAgICAgICAgIGh0 dHA6Ly9vcHMuaWV0Zi5vcmcvbGlzdHMvbmFtZWRyb3BwZXJzL25hbWVkcm9wcGVycy4yMDAyLw0K ICAgICAgICAgICAgICAgbXNnMDA2NTguaHRtbA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTHlv biwgV29uZyAgICAgICAgICAgICBFeHBpcmVzIC0gRmVicnVhcnkgMjAwNSAgICAgICAgICAgICAg W1BhZ2UgMTBdDQoMDQogICAgICAgICAgICAgICAgICAgU2VuZGVyIElEOiBBdXRoZW50aWNhdGlu ZyBFLU1haWwgICAgICAgIEF1Z3VzdCAyMDA0DQoNCg0KDQoxMS4gQXV0aG9ycycgQWRkcmVzc2Vz DQoNCiAgIEppbSBMeW9uDQogICBNaWNyb3NvZnQgQ29ycG9yYXRpb24NCiAgIE9uZSBNaWNyb3Nv ZnQgV2F5DQogICBSZWRtb25kLCBXQSA5ODA1Mg0KICAgVVNBDQogICBqaW1seW9uQG1pY3Jvc29m dC5jb20NCg0KICAgTWVuZyBXZW5nIFdvbmcNCiAgIFNpbmdhcG9yZQ0KICAgbWVuZ3dvbmdAZHVt Ym8ucG9ib3guY29tDQoNCg0KSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA0KDQogICBU aGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3Bl IG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMg dGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlv biBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50 IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAg IG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0 aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFu eSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJl c3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1Ag NzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRo ZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8g YmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0 byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0K ICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRo aXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGlu ZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRo ZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVu dGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywg b3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5 IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBs ZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdCBpZXRmLQ0KICAgaXBy QGlldGYub3JnLg0KDQoNCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVu dCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFu DQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04g SEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElO VEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JD RSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVE SU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0K ICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5Z IElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9S IEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkx5b24sIFdvbmcgICAgICAgICAgICAgRXhwaXJl cyAtIEZlYnJ1YXJ5IDIwMDUgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KICAgICAgICAgICAg ICAgICAgIFNlbmRlciBJRDogQXV0aGVudGljYXRpbmcgRS1NYWlsICAgICAgICBBdWd1c3QgMjAw NA0KDQoNCg0KDQpDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIElu dGVybmV0IFNvY2lldHkgKDIwMDQpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0 aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgs IGFuZA0KICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4g YWxsIHRoZWlyIHJpZ2h0cy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0 aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJ bnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkx5b24sIFdvbmcgICAgICAgICAg ICAgRXhwaXJlcyAtIEZlYnJ1YXJ5IDIwMDUgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA== ------_=_NextPart_001_01C4818E.B12420E9-- From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 20:06:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26949 for ; Fri, 13 Aug 2004 20:06: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 i7DNiilN075338; Fri, 13 Aug 2004 16:44: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 i7DNiits075337; Fri, 13 Aug 2004 16:44:44 -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.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DNiifT075330 for ; Fri, 13 Aug 2004 16:44:44 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 16:44:49 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Aug 2004 16:44:51 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 16:44:49 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 16:44:44 -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="----_=_NextPart_001_01C4818F.858ACFC3" Subject: draft-ietf-marid-submitter-03 Date: Fri, 13 Aug 2004 16:44:47 -0700 Message-ID: Thread-Topic: draft-ietf-marid-submitter-03 Thread-Index: AcSBj4RwDhDyx0eSQNGHFu9Dssvupg== From: "Harry Katz" To: Cc: "IETF MARID List" , "Eric Allman" X-OriginalArrivalTime: 13 Aug 2004 23:44:44.0706 (UTC) FILETIME=[82BEB820:01C4818F] 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_01C4818F.858ACFC3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To the Internet Drafts editor: Please publish the attached revised Internet Draft, draft-ietf-marid-submitter-03.txt Changes in this draft by section number:=20 - in 1, amended wording about the advantages of basing validation on RFC 2822 headers. - in 4.1, amended wording to use "null reverse-path" to conform with RFC 2821 terminology. - in 4.1, made SUBMITTER a MUST on all messages for conformance. - in 4.2, changed SHOULD reject to MUST reject when SUBMITTER value does not match PRA value derived from headers. - in 4.2, added a paragraph noting that the SUBMITTER parameter is not to be used as a reverse-path address. - added 5.5, example of SUBMITTER usage when reverse path is null. - changed several references from [SENDER-ID] to [PRA] to reflect creation of separate [PRA] document. - minor wording changes and corrections throughout. =20 Thanks. ------_=_NextPart_001_01C4818F.858ACFC3 Content-Type: text/plain; name="draft-ietf-marid-submitter-03.txt" Content-Description: draft-ietf-marid-submitter-03.txt Content-Disposition: attachment; filename="draft-ietf-marid-submitter-03.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQogICBNQVJJRCBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEUuIEFsbG1hbg0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNlbmRtYWlsLCBJbmMNCiAgIERvY3VtZW50OiBkcmFm dC1pZXRmLW1hcmlkLXN1Ym1pdHRlci0wMy50eHQgICAgICAgICAgICAgICAgICBILiBLYXR6DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBN aWNyb3NvZnQgQ29ycA0KICAgRXhwaXJlczogIEZlYnJ1YXJ5IDIwMDUgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDQNCg0KDQogICAgICAgICAgICAgICAgICAgICAg ICBTTVRQIFNlcnZpY2UgRXh0ZW5zaW9uIGZvcg0KICAgICAgICAgSW5kaWNhdGluZyB0aGUgUmVz cG9uc2libGUgU3VibWl0dGVyIG9mIGFuIEUtbWFpbCBNZXNzYWdlDQoNCg0KU3RhdHVzIG9mIHRo aXMgTWVtbw0KDQogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIEkgY2VydGlm eSB0aGF0IGFueSBhcHBsaWNhYmxlDQogICBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3 aGljaCBJIGFtIGF3YXJlIGhhdmUgYmVlbiBkaXNjbG9zZWQsDQogICBvciB3aWxsIGJlIGRpc2Ns b3NlZCwgYW5kIGFueSBvZiB3aGljaCBJIGJlY29tZSBhd2FyZSB3aWxsIGJlDQogICBkaXNjbG9z ZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBSRkMgMzY2OC4gW1NURF0NCg0KICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiBUYXNrIEZvcmNlIChJRVRGKSwgaXRzDQogICBh cmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5 IGFsc28NCiAgIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRz Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJp YWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQN CiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQogICBU aGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vz c2VkIGF0DQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCg0KQ29w eXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgy MDA0KS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8g ZGVmaW5lcyBhbiBleHRlbnNpb24gdG8gdGhlIFNpbXBsZSBNYWlsIFRyYW5zZmVyIFByb3RvY29s DQogICAoU01UUCkgc2VydmljZSwgd2hpY2ggYWxsb3dzIGFuIFNNVFAgY2xpZW50IHRvIHNwZWNp ZnkgdGhlDQogICByZXNwb25zaWJsZSBzdWJtaXR0ZXIgb2YgYW4gZS1tYWlsIG1lc3NhZ2UuICBU aGUgcmVzcG9uc2libGUNCiAgIHN1Ym1pdHRlciBpcyB0aGUgZS1tYWlsIGFkZHJlc3Mgb2YgdGhl IGVudGl0eSBtb3N0IHJlY2VudGx5DQogICByZXNwb25zaWJsZSBmb3IgaW50cm9kdWNpbmcgYSBt ZXNzYWdlIGludG8gdGhlIHRyYW5zcG9ydCBzdHJlYW0uDQogICBUaGlzIGV4dGVuc2lvbiBoZWxw cyByZWNlaXZpbmcgZS1tYWlsIHNlcnZlcnMgZWZmaWNpZW50bHkgZGV0ZXJtaW5lDQogICB3aGV0 aGVyIHRoZSBTTVRQIGNsaWVudCBpcyBhdXRob3JpemVkIHRvIHRyYW5zbWl0IG1haWwgb24gYmVo YWxmIG9mDQogICB0aGUgcmVzcG9uc2libGUgc3VibWl0dGVyJ3MgZG9tYWluLg0KDQoNCg0KQWxs bWFuLCBLYXR6ICAgICAgICAgICBFeHBpcmVzIC0gRmVicnVhcnkgMjAwNSAgICAgICAgICAgICAg IFtQYWdlIDFdDQoMDQogICAgICAgICAgICAgICAgIFNNVFAgUmVzcG9uc2libGUgU3VibWl0dGVy IEV4dGVuc2lvbiAgICAgIEF1Z3VzdCAyMDA0DQoNCg0KDQpDb252ZW50aW9ucyBVc2VkIGluIFRo aXMgRG9jdW1lbnQNCg0KICAgSW4gZXhhbXBsZXMsICJDOiIgYW5kICJTOiIgaW5kaWNhdGUgbGlu ZXMgc2VudCBieSB0aGUgY2xpZW50IGFuZA0KICAgc2VydmVyIHJlc3BlY3RpdmVseS4NCg0KICAg VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJT SEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1B WSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnBy ZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDLTIxMTkgW0tFWVdPUkRTXS4NCg0KDQpUYWJsZSBvZiBD b250ZW50cw0KDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yDQogICAyLiBUaGUgU1VCTUlUVEVSIFNlcnZpY2UgRXh0 ZW5zaW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQogICAzLiBUaGUgU1VCTUlU VEVSIEtleXdvcmQgb2YgdGhlIEVITE8gQ29tbWFuZC4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQog ICA0LiBUaGUgU1VCTUlUVEVSIFBhcmFtZXRlciBvZiB0aGUgTUFJTCBDb21tYW5kLi4uLi4uLi4u Li4uLi4uLi4uLi40DQogICAgICA0LjEgU2V0dGluZyB0aGUgU1VCTUlUVEVSIFBhcmFtZXRlciBW YWx1ZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICAgICA0LjIgUHJvY2Vzc2luZyB0aGUgU1VC TUlUVEVSIFBhcmFtZXRlci4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICAgICA0LjMgVHJh bnNtaXR0aW5nIHRvIGEgTm9uLVNVQk1JVFRFUiBBd2FyZSBTTVRQIFNlcnZlci4uLi4uLi4uLi42 DQogICA1LiBFeGFtcGxlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi42DQogICAgICA1LjEgTWFpbCBTdWJtaXNzaW9uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICAgICA1LjIgTWFpbCBGb3J3YXJkaW5n Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICAgICA1LjMg TW9iaWxlIFVzZXIuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li44DQogICAgICA1LjQgR3Vlc3QgRS1tYWlsIFNlcnZpY2UuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi45DQogICAgICA1LjUgU1VCTUlUVEVSIFVzZWQgb24gYSBOb24tRGVs aXZlcnkgUmVwb3J0Li4uLi4uLi4uLi4uLi4uLi4uLjEwDQogICA2LiBTZWN1cml0eSBDb25zaWRl cmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQogICA3LiBJ QU5BIENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjExDQogICA4LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjExDQogICAgICA4LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExDQogICAgICA4LjIgSW5mb3JtYXRp dmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExDQogICA5 LiBBY2tub3dsZWRnbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjEyDQogICAxMC4gQXV0aG9ycycgQWRkcmVzc2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEyDQogICAxMS4gQ2hhbmdlIEhpc3RvcnkuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEzDQogICAxMi4gRnVsbCBDb3B5 cmlnaHQgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE0DQoN Cg0KMS4gSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBwcmFjdGljZSBvZiBmYWxzaWZ5aW5nIHRoZSBp ZGVudGl0eSBvZiB0aGUgc2VuZGVyIG9mIGFuIGUtbWFpbA0KICAgbWVzc2FnZSwgY29tbW9ubHkg Y2FsbGVkICJzcG9vZmluZyIsIGlzIGEgcHJldmFsZW50IHRhY3RpYyB1c2VkIGJ5DQogICBzZW5k ZXJzIG9mIHVuc29saWNpdGVkIGNvbW1lcmNpYWwgZS1tYWlsIG9yICJzcGFtIi4gIFRoaXMgZm9y bSBvZg0KICAgYWJ1c2UgaGFzIGhpZ2hsaWdodGVkIHRoZSBuZWVkIHRvIGltcHJvdmUgaWRlbnRp ZmljYXRpb24gb2YgdGhlDQogICAicmVzcG9uc2libGUgc3VibWl0dGVyIiBvZiBhbiBlLW1haWwg bWVzc2FnZS4NCg0KICAgSW4gdGhpcyBzcGVjaWZpY2F0aW9uLCB0aGUgcmVzcG9uc2libGUgc3Vi bWl0dGVyIGlzIHRoZSBlbnRpdHkgbW9zdA0KICAgcmVjZW50bHkgcmVzcG9uc2libGUgZm9yIGlu amVjdGluZyBhIG1lc3NhZ2UgaW50byB0aGUgZS1tYWlsDQogICB0cmFuc3BvcnQgc3RyZWFtLiAg VGhlIGUtbWFpbCBhZGRyZXNzIG9mIHRoZSByZXNwb25zaWJsZSBzdWJtaXR0ZXINCiAgIHdpbGwg YmUgcmVmZXJyZWQgdG8gYXMgdGhlICJwdXJwb3J0ZWQgcmVzcG9uc2libGUgYWRkcmVzcyIgKFBS QSkgb2YNCg0KDQpBbGxtYW4sIEthdHogICAgICAgICAgIEV4cGlyZXMgLSBGZWJydWFyeSAyMDA1 ICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25z aWJsZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICAgQXVndXN0IDIwMDQNCg0KDQogICB0aGUgbWVz c2FnZS4gIFRoZSAicHVycG9ydGVkIHJlc3BvbnNpYmxlIGRvbWFpbiIgKFBSRCkgaXMgdGhlIGRv bWFpbg0KICAgcG9ydGlvbiBvZiB0aGF0IGFkZHJlc3MuDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBjb2RpZmllcyBydWxlcyBmb3IgZW5jb2RpbmcgdGhlIHB1cnBvcnRlZA0KICAgcmVzcG9uc2li bGUgYWRkcmVzcyBpbnRvIHRoZSBTTVRQIHRyYW5zcG9ydCBwcm90b2NvbC4gIFRoaXMgd2lsbA0K ICAgcGVybWl0IHJlY2VpdmluZyBTTVRQIHNlcnZlcnMgdG8gZWZmaWNpZW50bHkgdmFsaWRhdGUg d2hldGhlciBvciBub3QNCiAgIHRoZSBTTVRQIGNsaWVudCBpcyBhdXRob3JpemVkIHRvIHRyYW5z bWl0IG1haWwgb24gYmVoYWxmIG9mIHRoZQ0KICAgcmVzcG9uc2libGUgc3VibWl0dGVyJ3MgZG9t YWluLg0KDQogICBCcm9hZGx5IHNwZWFraW5nLCB0aGVyZSBhcmUgdHdvIHBvc3NpYmxlIGFwcHJv YWNoZXMgZm9yIGRldGVybWluaW5nDQogICB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJl c3M7IGVpdGhlciBmcm9tIFJGQyAyODIxIFtTTVRQXQ0KICAgcHJvdG9jb2wgZGF0YSBvciBmcm9t IFJGQyAyODIyIFtNU0ctRk9STUFUXSBtZXNzYWdlIGhlYWRlcnMuICBFYWNoDQogICBhcHByb2Fj aCBoYXMgY2VydGFpbiBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzLg0KDQogICBEZXJpdmlu ZyB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGRvbWFpbiBmcm9tIFJGQyAyODIxIGRhdGEgaGFz IHRoZQ0KICAgYWR2YW50YWdlIHRoYXQgdmFsaWRhdGlvbiBjYW4gYmUgcGVyZm9ybWVkIGJlZm9y ZSB0aGUgU01UUCBjbGllbnQgaGFzDQogICB0cmFuc21pdHRlZCB0aGUgbWVzc2FnZSBib2R5LiAg SWYgc3Bvb2ZpbmcgaXMgZGV0ZWN0ZWQsIHRoZW4gdGhlIFNNVFANCiAgIHNlcnZlciBoYXMgdGhl IG9wcG9ydHVuaXR5LCBkZXBlbmRpbmcgdXBvbiBsb2NhbCBwb2xpY3ksIHRvIHJlamVjdA0KICAg dGhlIG1lc3NhZ2UgYmVmb3JlIGl0IGlzIGV2ZXIgdHJhbnNtaXR0ZWQuICBUaGUgZGlzYWR2YW50 YWdlIG9mIHRoaXMNCiAgIGFwcHJvYWNoIGlzIHRoZSByaXNrIG9mIGZhbHNlIHBvc2l0aXZlcywg dGhhdCBpcywgaW5jb3JyZWN0bHkNCiAgIGNvbmNsdWRpbmcgdGhhdCB0aGUgc2VuZGVyJ3MgZS1t YWlsIGFkZHJlc3MgaGFzIGJlZW4gc3Bvb2ZlZC4gIFRoZXJlDQogICBhcmUgdG9kYXkgbGVnaXRp bWF0ZSByZWFzb25zIHdoeSB0aGUgSW50ZXJuZXQgZG9tYWluIG5hbWVzIHVzZWQgaW4NCiAgIFJG QyAyODIxIGNvbW1hbmRzIG1heSBiZSBkaWZmZXJlbnQgZnJvbSB0aGF0IG9mIHRoZSBzZW5kZXIg b2YgYW4gZS0NCiAgIG1haWwgbWVzc2FnZS4NCg0KICAgRGVyaXZpbmcgdGhlIHB1cnBvcnRlZCBy ZXNwb25zaWJsZSBkb21haW4gZnJvbSBSRkMgMjgyMiBoZWFkZXJzIGhhcw0KICAgdGhlIGFkdmFu dGFnZSB0aGF0IHZhbGlkYXRpb24gY2FuIHVzdWFsbHkgYmUgYmFzZWQgb24gYW4gaWRlbnRpdHkN CiAgIHRoYXQgaXMgZGlzcGxheWVkIHRvIHJlY2lwaWVudHMgYnkgZXhpc3RpbmcgTVVBcyBhcyB0 aGUgc2VuZGVyJ3MNCiAgIGlkZW50aXR5LiAgVGhpcyBhaWRzIGluIGRldGVjdGlvbiBvZiBhIHBh cnRpY3VsYXJseSBub3hpb3VzIGZvcm0gb2YNCiAgIHNwb29maW5nIGtub3duIGFzICJwaGlzaGlu ZyIgaW4gd2hpY2ggYSBtYWxpY2lvdXMgc2VuZGVyIGF0dGVtcHRzIHRvDQogICBmb29sIGEgcmVj aXBpZW50IGludG8gYmVsaWV2aW5nIHRoYXQgYSBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBhbg0K ICAgZW50aXR5IHdlbGwga25vd24gdG8gdGhlIHJlY2lwaWVudC4gIFRoaXMgYXBwcm9hY2ggY2Fy cmllcyBhIGxvd2VyDQogICByaXNrIG9mIGZhbHNlIHBvc2l0aXZlcyBzaW5jZSB0aGVyZSBhcmUg ZmV3ZXIgbGVnaXRpbWF0ZSByZWFzb25zIGZvcg0KICAgUkZDIDI4MjIgaGVhZGVycyB0byBkaWZm ZXIgZnJvbSB0aGUgdHJ1ZSBzZW5kZXIgb2YgdGhlIG1lc3NhZ2UuICBUaGUNCiAgIGRpc2FkdmFu dGFnZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgaXQgZG9lcyByZXF1aXJlIHBhcnNpbmcgYW5k DQogICBhbmFseXNpcyBvZiBtZXNzYWdlIGhlYWRlcnMuICBJbiBwcmFjdGljZSwgbXVjaCBpZiBu b3QgYWxsIHRoZQ0KICAgbWVzc2FnZSBib2R5IGlzIGFsc28gdHJhbnNtaXR0ZWQgc2luY2UgdGhl IFNNVFAgcHJvdG9jb2wgZGVzY3JpYmVkIGluDQogICBSRkMgMjgyMSBwcm92aWRlcyBubyBtZWNo YW5pc20gdG8gaW50ZXJydXB0IG1lc3NhZ2UgdHJhbnNtaXNzaW9uDQogICBhZnRlciB0aGUgREFU QSBjb21tYW5kIGhhcyBiZWVuIGlzc3VlZC4NCg0KICAgSXQgaXMgZGVzaXJhYmxlIHRvIHVuaWZ5 IHRoZXNlIHR3byBhcHByb2FjaGVzIGluIGEgd2F5IHRoYXQgY29tYmluZXMNCiAgIHRoZSBiZW5l Zml0cyBvZiBib3RoIHdoaWxlIG1pbmltaXppbmcgdGhlaXIgcmVzcGVjdGl2ZSBkaXNhZHZhbnRh Z2VzLg0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGp1c3Qgc3VjaCBhIHVuaWZp ZWQgYXBwcm9hY2guICBJdCB1c2VzDQogICB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBbU01U UF0gdG8gZGVzY3JpYmUgYW4gZXh0ZW5zaW9uIHRvIHRoZQ0KICAgU01UUCBwcm90b2NvbC4gIFVz aW5nIHRoaXMgZXh0ZW5zaW9uLCBhbiBTTVRQIGNsaWVudCBjYW4gc3BlY2lmeSB0aGUNCiAgIGUt bWFpbCBhZGRyZXNzIG9mIHRoZSBlbnRpdHkgbW9zdCByZWNlbnRseSByZXNwb25zaWJsZSBmb3Ig c3VibWl0dGluZw0KICAgdGhlIG1lc3NhZ2UgdG8gdGhlIFNNVFAgY2xpZW50IGluIGEgbmV3IFNV Qk1JVFRFUiBwYXJhbWV0ZXIgb2YgdGhlDQogICBTTVRQIE1BSUwgY29tbWFuZC4gIFNNVFAgc2Vy dmVycyBjYW4gdXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gdmFsaWRhdGUNCg0KDQpBbGxtYW4sIEth dHogICAgICAgICAgIEV4cGlyZXMgLSBGZWJydWFyeSAyMDA1ICAgICAgICAgICAgICAgW1BhZ2Ug M10NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0ZW5z aW9uICAgICAgQXVndXN0IDIwMDQNCg0KDQogICB0aGF0IHRoZSBTTVRQIGNsaWVudCBpcyBhdXRo b3JpemVkIHRvIHRyYW5zbWl0IGUtbWFpbCBvbiBiZWhhbGYgb2YNCiAgIHRoZSBJbnRlcm5ldCBk b21haW4gY29udGFpbmVkIGluIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyLg0KDQoNCjIuIFRoZSBT VUJNSVRURVIgU2VydmljZSBFeHRlbnNpb24NCg0KICAgVGhlIGZvbGxvd2luZyBTTVRQIHNlcnZp Y2UgZXh0ZW5zaW9uIGlzIGhlcmVieSBkZWZpbmVkOg0KDQogICAoMSkgIFRoZSBuYW1lIG9mIHRo aXMgU01UUCBzZXJ2aWNlIGV4dGVuc2lvbiBpcyAiUmVzcG9uc2libGUNCiAgICAgICAgU3VibWl0 dGVyIjsNCg0KICAgKDIpICBUaGUgRUhMTyBrZXl3b3JkIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0 aGlzIGV4dGVuc2lvbiBpcw0KICAgICAgICAiU1VCTUlUVEVSIjsNCg0KICAgKDMpICBUaGUgU1VC TUlUVEVSIGtleXdvcmQgaGFzIG5vIHBhcmFtZXRlcnM7DQoNCiAgICg0KSAgTm8gYWRkaXRpb25h bCBTTVRQIHZlcmJzIGFyZSBkZWZpbmVkIGJ5IHRoaXMgZXh0ZW5zaW9uOw0KDQogICAoNSkgIEFu IG9wdGlvbmFsIHBhcmFtZXRlciBpcyBhZGRlZCB0byB0aGUgTUFJTCBjb21tYW5kIHVzaW5nIHRo ZQ0KICAgICAgICBlc210cC1rZXl3b3JkICJTVUJNSVRURVIiLCBhbmQgaXMgdXNlZCB0byBzcGVj aWZ5IHRoZSBlLW1haWwNCiAgICAgICAgYWRkcmVzcyBvZiB0aGUgZW50aXR5IHJlc3BvbnNpYmxl IGZvciBzdWJtaXR0aW5nIHRoZSBtZXNzYWdlIGZvcg0KICAgICAgICBkZWxpdmVyeTsNCg0KICAg KDYpICBUaGlzIGV4dGVuc2lvbiBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIHN1Ym1pc3Npb24gcHJv dG9jb2wNCiAgICAgICAgW1NVQk1JVF0uDQoNCg0KMy4gVGhlIFNVQk1JVFRFUiBLZXl3b3JkIG9m IHRoZSBFSExPIENvbW1hbmQNCg0KICAgQW4gU01UUCBzZXJ2ZXIgaW5jbHVkZXMgdGhlIFNVQk1J VFRFUiBrZXl3b3JkIGluIGl0cyBFSExPIHJlc3BvbnNlIHRvDQogICB0ZWxsIHRoZSBTTVRQIGNs aWVudCB0aGF0IHRoZSBTVUJNSVRURVIgc2VydmljZSBleHRlbnNpb24gaXMNCiAgIHN1cHBvcnRl ZC4NCg0KICAgVGhlIFNVQk1JVFRFUiBrZXl3b3JkIGhhcyBubyBwYXJhbWV0ZXJzLg0KDQoNCjQu IFRoZSBTVUJNSVRURVIgUGFyYW1ldGVyIG9mIHRoZSBNQUlMIENvbW1hbmQNCg0KICAgVGhlIHN5 bnRheCBvZiB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciBpczoNCg0KICAgICAgIlNVQk1JVFRFUj0i IE1haWxib3gNCg0KICAgd2hlcmUgTWFpbGJveCBpcyB0aGUgQUJORiBbQUJORl0gcHJvZHVjdGlv biBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjINCiAgIG9mIFtTTVRQXS4gIENoYXJhY3RlcnMgc3Vj aCBhcyBTUCwgIisiIGFuZCAiPSIgd2hpY2ggbWF5IG9jY3VyIGluDQogICBNYWlsYm94IGJ1dCBh cmUgbm90IHBlcm1pdHRlZCBpbiBFU01UUCBwYXJhbWV0ZXIgdmFsdWVzIE1VU1QgYmUNCiAgIGVu Y29kZWQgYXMgInh0ZXh0IiBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA0IG9mIFtEU05dLg0KDQoN Cg0KDQoNCkFsbG1hbiwgS2F0eiAgICAgICAgICAgRXhwaXJlcyAtIEZlYnJ1YXJ5IDIwMDUgICAg ICAgICAgICAgICBbUGFnZSA0XQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3BvbnNpYmxl IFN1Ym1pdHRlciBFeHRlbnNpb24gICAgICBBdWd1c3QgMjAwNA0KDQoNCjQuMSBTZXR0aW5nIHRo ZSBTVUJNSVRURVIgUGFyYW1ldGVyIFZhbHVlDQoNCiAgIFRoZSBwdXJwb3NlIG9mIHRoZSBTVUJN SVRURVIgcGFyYW1ldGVyIGlzIHRvIGFsbG93IHRoZSBTTVRQIGNsaWVudCB0bw0KICAgaW5kaWNh dGUgdG8gdGhlIHNlcnZlciB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3Mgb2YgdGhl DQogICBtZXNzYWdlIGRpcmVjdGx5IGluIHRoZSBSRkMgMjgyMSBwcm90b2NvbC4NCg0KICAgVGhl cmVmb3JlLCBTTVRQIGNsaWVudHMgdGhhdCBzdXBwb3J0IHRoZSBSZXNwb25zaWJsZSBTdWJtaXR0 ZXINCiAgIGV4dGVuc2lvbiBNVVNUIGluY2x1ZGUgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIgb24g YWxsIG1lc3NhZ2VzLiAgVGhpcw0KICAgaW5jbHVkZXMgbWVzc2FnZXMgY29udGFpbmluZyBhIG51 bGwgcmV2ZXJzZS1wYXRoIGluIHRoZSBNQUlMIGNvbW1hbmQuDQoNCiAgIFNNVFAgY2xpZW50cyBN VVNUIHNldCB0aGUgU1VNQklUVEVSIHBhcmFtZXRlciB2YWx1ZSB0byB0aGUgcHVycG9ydGVkDQog ICByZXNwb25zaWJsZSBhZGRyZXNzIG9mIHRoZSBtZXNzYWdlIGFzIGRlZmluZWQgaW4gW1BSQV0u ICBUaGlzIGFsc28NCiAgIGFwcGxpZXMgdG8gbWVzc2FnZXMgY29udGFpbmluZyBhIG51bGwgcmV2 ZXJzZS1wYXRoLg0KDQogICBJbiBzb21lIGNpcmN1bXN0YW5jZXMsIGRlc2NyaWJlZCBpbiBzZWN0 aW9uIDcgb2YgW1NFTkRFUi1JRF0sIFNNVFANCiAgIGNsaWVudHMgbWF5IG5lZWQgdG8gYWRkIFJG QyAyODIyIGhlYWRlcnMgdG8gdGhlIG1lc3NhZ2UgaW4gb3JkZXIgdG8NCiAgIGVuc3VyZSB0aGF0 IHRoZSBjb3JyZWN0IFNVQk1JVFRFUiBwYXJhbWV0ZXIgdmFsdWUgY2FuIGJlIHNldC4NCg0KNC4y IFByb2Nlc3NpbmcgdGhlIFNVQk1JVFRFUiBQYXJhbWV0ZXINCg0KICAgUmVjZWl2ZXJzIG9mIGUt bWFpbCBtZXNzYWdlcyBzZW50IHdpdGggdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIgU0hPVUxEDQog ICBzZWxlY3QgdGhlIGRvbWFpbiBwYXJ0IG9mIHRoZSBTVUJNSVRURVIgYWRkcmVzcyB2YWx1ZSBh cyB0aGUNCiAgIHB1cnBvcnRlZCByZXNwb25zaWJsZSBkb21haW4gb2YgdGhlIG1lc3NhZ2UsIGFu ZCBTSE9VTEQgcGVyZm9ybSBzdWNoDQogICB0ZXN0cywgaW5jbHVkaW5nIHRob3NlIGRlZmluZWQg aW4gW1NFTkRFUi1JRF0sIGFzIGFyZSBkZWVtZWQNCiAgIG5lY2Vzc2FyeSB0byBkZXRlcm1pbmUg d2hldGhlciB0aGUgY29ubmVjdGluZyBTTVRQIGNsaWVudCBpcw0KICAgYXV0aG9yaXplZCB0byB0 cmFuc21pdCBlLW1haWwgbWVzc2FnZXMgb24gYmVoYWxmIG9mIHRoYXQgZG9tYWluLg0KDQogICBJ ZiB0aGVzZSB0ZXN0cyBpbmRpY2F0ZSB0aGF0IHRoZSBjb25uZWN0aW5nIFNNVFAgY2xpZW50IGlz IG5vdA0KICAgYXV0aG9yaXplZCB0byB0cmFuc21pdCBlLW1haWwgbWVzc2FnZXMgb24gYmVoYWxm IG9mIHRoZSBTVUJNSVRURVINCiAgIGRvbWFpbiwgdGhlIHJlY2VpdmluZyBTTVRQIHNlcnZlciBT SE9VTEQgcmVqZWN0IHRoZSBtZXNzYWdlIGFuZCB3aGVuDQogICByZWplY3RpbmcgTVVTVCB1c2Ug IjU1MCA1LjcuMSBTdWJtaXR0ZXIgbm90IGFsbG93ZWQuIg0KDQogICBJZiB0aGUgcmVjZWl2aW5n IFNNVFAgc2VydmVyIGFsbG93cyB0aGUgY29ubmVjdGluZyBTTVRQIGNsaWVudCB0bw0KICAgdHJh bnNtaXQgbWVzc2FnZSBkYXRhLCB0aGVuIHRoZSBzZXJ2ZXIgU0hPVUxEIGRldGVybWluZSB0aGUg cHVycG9ydGVkDQogICByZXNwb25zaWJsZSBhZGRyZXNzIG9mIHRoZSBtZXNzYWdlIGJ5IGV4YW1p bmluZyB0aGUgUkZDIDI4MjIgbWVzc2FnZQ0KICAgaGVhZGVycyBhcyBkZXNjcmliZWQgaW4gW1BS QV0uICBJZiB0aGlzIHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzDQogICBkb2VzIG5vdCBt YXRjaCB0aGUgYWRkcmVzcyBhcHBlYXJpbmcgaW4gdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIsIHRo ZQ0KICAgcmVjZWl2aW5nIFNNVFAgc2VydmVyIE1VU1QgcmVqZWN0IHRoZSBtZXNzYWdlIGFuZCB3 aGVuIHJlamVjdGluZyBNVVNUDQogICB1c2UgIjU1MCA1LjcuMSBTdWJtaXR0ZXIgZG9lcyBub3Qg bWF0Y2ggaGVhZGVyLiINCg0KICAgSWYgbm8gcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3Mg aXMgZm91bmQgYWNjb3JkaW5nIHRvIHRoZQ0KICAgcHJvY2VkdXJlIGRlZmluZWQgaW4gW1BSQV0s IHRoZSBTTVRQIHNlcnZlciBTSE9VTEQgcmVqZWN0IHRoZSBtZXNzYWdlDQogICBhbmQgd2hlbiBy ZWplY3RpbmcgTVVTVCB1c2UgIjU1NCA1LjcuNyBDYW5ub3QgdmVyaWZ5IHN1Ym1pdHRlcg0KICAg YWRkcmVzcy4iDQoNCiAgIFZlcmlmeWluZyBNVEFzIGFyZSBzdHJvbmdseSB1cmdlZCB0byB2YWxp ZGF0ZSB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlcg0KICAgYWdhaW5zdCB0aGUgUkZDIDI4MjIgaGVh ZGVyczsgb3RoZXJ3aXNlLCBhbiBhdHRhY2tlciBjYW4gdHJpdmlhbGx5DQogICBkZWZlYXQgdGhl IGFsZ29yaXRobS4NCg0KDQoNCkFsbG1hbiwgS2F0eiAgICAgICAgICAgRXhwaXJlcyAtIEZlYnJ1 YXJ5IDIwMDUgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQ IFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBFeHRlbnNpb24gICAgICBBdWd1c3QgMjAwNA0KDQoNCiAg IE5vdGUgdGhhdCB0aGUgcHJlc2VuY2Ugb2YgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIgb24gdGhl IE1BSUwgY29tbWFuZA0KICAgTVVTVCBOT1QgY2hhbmdlIHRoZSBlZmZlY3RpdmUgcmV2ZXJzZS1w YXRoIG9mIGEgbWVzc2FnZS4gIEFueQ0KICAgZGVsaXZlcnkgc3RhdHVzIG5vdGlmaWNhdGlvbnMg bXVzdCBiZSBzZW50IHRvIHRoZSByZXZlcnNlLXBhdGgsIGlmDQogICBvbmUgZXhpc3RzLCBhcyBw ZXIgc2VjdGlvbiAzLjcgb2YgW1NNVFBdIHJlZ2FyZGxlc3Mgb2YgdGhlIHByZXNlbmNlDQogICBv ZiBhIFNVQk1JVFRFUiBwYXJhbWV0ZXIuICBJZiB0aGUgcmV2ZXJzZS1wYXRoIGlzIG51bGwsIGRl bGl2ZXJ5DQogICBzdGF0dXMgbm90aWZpY2F0aW9ucyBNVVNUIE5PVCBiZSBzZW50IHRvIHRoZSBT VUJNSVRURVIgYWRkcmVzcy4NCg0KNC4zIFRyYW5zbWl0dGluZyB0byBhIE5vbi1TVUJNSVRURVIg QXdhcmUgU01UUCBTZXJ2ZXINCg0KICAgTm90d2l0aHN0YW5kaW5nIHRoZSBwcm92aXNpb25zIG9m IHNlY3Rpb24gNC4xIGFib3ZlLCB3aGVuIGFuIE1UQQ0KICAgdHJhbnNtaXRzIGEgbWVzc2FnZSB0 byBhbm90aGVyIE1UQSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgdGhlDQogICBTVUJNSVRURVIgZXh0 ZW5zaW9uLCB0aGUgZm9yd2FyZGluZyBNVEEgTVVTVCB0cmFuc21pdCB0aGUgbWVzc2FnZQ0KICAg d2l0aG91dCB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlci4gIFRoaXMgc2hvdWxkIGludm9sdmUgbm8g aW5mb3JtYXRpb24NCiAgIGxvc3MsIHNpbmNlIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyIGlzIHJl cXVpcmVkIHRvIGNvbnRhaW4NCiAgIGluZm9ybWF0aW9uIGRlcml2ZWQgZnJvbSB0aGUgbWVzc2Fn ZSBoZWFkZXJzLg0KDQoNCjUuIEV4YW1wbGVzDQoNCiAgIFRoaXMgc2VjdGlvbiBwcm92aWRlcyBl eGFtcGxlcyBvZiBob3cgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIgd291bGQNCiAgIGJlIHVzZWQu ICBUaGUgZm9sbG93aW5nIGRyYW1hdGlzIHBlcnNvbmFlIGFwcGVhciBpbiB0aGUgZXhhbXBsZXM6 DQoNCiAgIGFsaWNlQGV4YW1wbGUuY29tOiB0aGUgb3JpZ2luYWwgc2VuZGVyIG9mIGVhY2ggZS1t YWlsIG1lc3NhZ2UuDQoNCiAgIGJvYkBjb21wYW55LmNvbS5leGFtcGxlOiB0aGUgZmluYWwgcmVj aXBpZW50IG9mIGVhY2ggZS1tYWlsLg0KDQogICBib2JAYWxtYW1hdGVyLmVkdS5leGFtcGxlOiBh biBlbWFpbCBhZGRyZXNzIHVzZWQgYnkgQm9iIHdoaWNoIGhlIGhhcw0KICAgY29uZmlndXJlZCB0 byBmb3J3YXJkIG1haWwgdG8gaGlzIG9mZmljZSBhY2NvdW50IGF0DQogICBib2JAY29tcGFueS5j b20uZXhhbXBsZS4NCg0KICAgYWxpY2VAbW9iaWxlLm5ldC5leGFtcGxlOiBhbiBlLW1haWwgYWNj b3VudCBwcm92aWRlZCB0byBBbGljZSBieSBoZXINCiAgIG1vYmlsZSBlLW1haWwgbmV0d29yayBj YXJyaWVyLg0KDQo1LjEgTWFpbCBTdWJtaXNzaW9uDQoNCiAgIFVuZGVyIG5vcm1hbCBjaXJjdW1z dGFuY2VzLCBBbGljZSB3b3VsZCBjb25maWd1cmUgaGVyIE1VQSB0byBzdWJtaXQNCiAgIGhlciBt ZXNzYWdlIHRvIHRoZSBtYWlsIHN5c3RlbSB1c2luZyB0aGUgU1VCTUlUIHByb3RvY29sIFtTVUJN SVRdLg0KICAgVGhlIE1VQSB3b3VsZCB0cmFuc21pdCB0aGUgbWVzc2FnZSB3aXRob3V0IHRoZSBT VUJNSVRURVIgcGFyYW1ldGVyLg0KICAgVGhlIFNVQk1JVCBzZXJ2ZXIgd291bGQgdmFsaWRhdGUg dGhhdCB0aGUgTVVBIGlzIGFsbG93ZWQgdG8gc3VibWl0IGENCiAgIG1lc3NhZ2UgdGhyb3VnaCBz b21lIGV4dGVybmFsIHNjaGVtZSwgcGVyaGFwcyBTTVRQIEF1dGhlbnRpY2F0aW9uDQogICBbU01U UEFVVEhdLiAgVW5kZXIgbW9zdCBjaXJjdW1zdGFuY2VzIHRoaXMgd291bGQgbG9vayBsaWtlIGEg bm9ybWFsLA0KICAgYXV0aGVudGljYXRlZCBTTVRQIHRyYW5zYWN0aW9uLiAgVGhlIFNVQk1JVCBz ZXJ2ZXIgd291bGQgZXh0cmFjdCBoZXINCiAgIG5hbWUgZnJvbSB0aGUgUkZDIDI4MjIgaGVhZGVy cyBmb3IgdXNlIGluIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVycyBvZg0KICAgc3Vic2VxdWVudCB0 cmFuc21pc3Npb25zIG9mIHRoZSBtZXNzYWdlLg0KDQo1LjIgTWFpbCBGb3J3YXJkaW5nDQoNCiAg IFdoZW4gQWxpY2Ugc2VuZHMgYSBtZXNzYWdlIHRvIEJvYiBhdCBoaXMgYWxtYW1hdGVyLmVkdS5l eGFtcGxlDQogICBhY2NvdW50LCB0aGUgU01UUCBzZXNzaW9uIGZyb20gaGVyIFNVQk1JVCBzZXJ2 ZXIgbWlnaHQgbG9vayBzb21ldGhpbmcNCiAgIGxpa2UgdGhpczoNCg0KQWxsbWFuLCBLYXR6ICAg ICAgICAgICBFeHBpcmVzIC0gRmVicnVhcnkgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDZdDQoM DQogICAgICAgICAgICAgICAgIFNNVFAgUmVzcG9uc2libGUgU3VibWl0dGVyIEV4dGVuc2lvbiAg ICAgIEF1Z3VzdCAyMDA0DQoNCg0KDQoNCiAgICAgIFM6IDIyMCBhbG1hbWF0ZXIuZWR1LmV4YW1w bGUgRVNNVFAgc2VydmVyIHJlYWR5DQogICAgICBDOiBFSExPIGV4YW1wbGUuY29tDQogICAgICBT OiAyNTAtYWxtYW1hdGVyLmVkdS5leGFtcGxlDQogICAgICBTOiAyNTAtRFNODQogICAgICBTOiAy NTAtQVVUSA0KICAgICAgUzogMjUwLVNVQk1JVFRFUg0KICAgICAgUzogMjUwIFNJWkUNCiAgICAg IEM6IE1BSUwgRlJPTTo8YWxpY2VAZXhhbXBsZS5jb20+IFNVQk1JVFRFUj1hbGljZUBleGFtcGxl LmNvbQ0KICAgICAgUzogMjUwIDxhbGljZUBleGFtcGxlLmNvbT4gc2VuZGVyIG9rDQogICAgICBD OiBSQ1BUIFRPOjxib2JAYWxtYW1hdGVyLmVkdS5leGFtcGxlPg0KICAgICAgUzogMjUwIDxib2JA YWxtYW1hdGVyLmVkdS5leGFtcGxlPiByZWNpcGllbnQgb2sNCiAgICAgIEM6IERBVEENCiAgICAg IFM6IDM1NCBva2F5LCBzZW5kIG1lc3NhZ2UNCiAgICAgIEM6IChtZXNzYWdlIGJvZHkgZ29lcyBo ZXJlKQ0KICAgICAgQzogLg0KICAgICAgUzogMjUwIG1lc3NhZ2UgYWNjZXB0ZWQNCiAgICAgIEM6 IFFVSVQNCiAgICAgIFM6IDIyMSBnb29kYnllDQoNCiAgIFRoZSBhbG1hbWF0ZXIuZWR1LmV4YW1w bGUgTVRBIG11c3Qgbm93IGZvcndhcmQgdGhpcyBtZXNzYWdlIHRvDQogICBib2JAY29tcGFueS5j b20uZXhhbXBsZS4gIEFsdGhvdWdoIHRoZSBvcmlnaW5hbCBzZW5kZXIgb2YgdGhlIG1lc3NhZ2UN CiAgIGlzIGFsaWNlQGV4YW1wbGUuY29tLCBBbGljZSBpcyBub3QgcmVzcG9uc2libGUgZm9yIHRo aXMgbW9zdCByZWNlbnQNCiAgIHJldHJhbnNtaXNzaW9uIG9mIHRoZSBtZXNzYWdlLiAgVGhhdCBy b2xlIGlzIGZpbGxlZCBieQ0KICAgYm9iQGFsbWFtYXRlci5lZHUuZXhhbXBsZSB3aG8gZXN0YWJs aXNoZWQgdGhlIGZvcndhcmRpbmcgb2YgbWFpbCB0bw0KICAgYm9iQGNvbXBhbnkuY29tLmV4YW1w bGUuICBUaGVyZWZvcmUsIHRoZSBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUgTVRBDQogICBkZXRlcm1p bmVzIGEgbmV3IHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzIGZvciB0aGUgbWVzc2FnZSwN CiAgIG5hbWVseSBib2JAYWxtYW1hdGVyLmVkdS5leGFtcGxlLCBhbmQgc2V0cyB0aGUgU1VCTUlU VEVSIHBhcmFtZXRlcg0KICAgYWNjb3JkaW5nbHkuICBUaGUgZm9yd2FyZGluZyBNVEEgYWxzbyBp bnNlcnRzIGEgUmVzZW50LUZyb20gaGVhZGVyIGluDQogICB0aGUgbWVzc2FnZSBib2R5IHRvIGVu c3VyZSB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3MgZGVyaXZlZA0KICAgZnJvbSB0 aGUgUkZDIDI4MjIgaGVhZGVycyBtYXRjaGVzIHRoZSBTVUJNSVRURVIgYWRkcmVzcy4NCg0KICAg ICAgUzogMjIwIGNvbXBhbnkuY29tLmV4YW1wbGUgRVNNVFAgc2VydmVyIHJlYWR5DQogICAgICBD OiBFSExPIGFsbWFtYXRlci5lZHUuZXhhbXBsZQ0KICAgICAgUzogMjUwLWNvbXBhbnkuY29tLmV4 YW1wbGUNCiAgICAgIFM6IDI1MC1EU04NCiAgICAgIFM6IDI1MC1BVVRIDQogICAgICBTOiAyNTAt U1VCTUlUVEVSDQogICAgICBTOiAyNTAgU0laRQ0KICAgICAgQzogTUFJTCBGUk9NOjxhbGljZUBl eGFtcGxlLmNvbT4NCiAgICAgICAgICAgICAgU1VCTUlUVEVSPWJvYkBhbG1hbWF0ZXIuZWR1LmV4 YW1wbGUNCiAgICAgIFM6IDI1MCA8YWxpY2VAZXhhbXBsZS5jb20+IHNlbmRlciBvaw0KICAgICAg QzogUkNQVCBUTzo8Ym9iQGNvbXBhbnkuY29tLmV4YW1wbGU+DQogICAgICBTOiAyNTAgPGJvYkBj b21wYW55LmNvbS5leGFtcGxlPiByZWNpcGllbnQgb2sNCiAgICAgIEM6IERBVEENCiAgICAgIFM6 IDM1NCBva2F5LCBzZW5kIG1lc3NhZ2UNCiAgICAgIEM6IFJlc2VudC1Gcm9tOiBib2JAYWxtYW1h dGVyLmVkdS5leGFtcGxlDQogICAgICBDOiBSZWNlaXZlZCBCeTogLi4uDQogICAgICBDOiAobWVz c2FnZSBib2R5IGdvZXMgaGVyZSkNCg0KQWxsbWFuLCBLYXR6ICAgICAgICAgICBFeHBpcmVzIC0g RmVicnVhcnkgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQogICAgICAgICAgICAgICAg IFNNVFAgUmVzcG9uc2libGUgU3VibWl0dGVyIEV4dGVuc2lvbiAgICAgIEF1Z3VzdCAyMDA0DQoN Cg0KICAgICAgQzogLg0KICAgICAgUzogMjUwIG1lc3NhZ2UgYWNjZXB0ZWQNCiAgICAgIEM6IFFV SVQNCiAgICAgIFM6IDIyMSBnb29kYnllDQoNCjUuMyBNb2JpbGUgVXNlcg0KDQogICBBbGljZSBp cyBhdCB0aGUgYWlycG9ydCBhbmQgdXNlcyBoZXIgbW9iaWxlIGUtbWFpbCBkZXZpY2UgdG8gc2Vu ZCBhDQogICBtZXNzYWdlIHRvIEJvYi4gIFRoZSBtZXNzYWdlIHRyYXZlbHMgdGhyb3VnaCB0aGUg Y2FycmllciBuZXR3b3JrDQogICBwcm92aWRlZCBieSBtb2JpbGUubmV0LmV4YW1wbGUsIGJ1dCBB bGljZSB1c2VzIGhlciBleGFtcGxlLmNvbQ0KICAgYWRkcmVzcyBvbiB0aGUgRnJvbSBsaW5lIG9m IGFsbCBoZXIgbWVzc2FnZXMgc28gdGhhdCByZXBsaWVzIGdvIHRvDQogICBoZXIgb2ZmaWNlIG1h aWxib3guDQoNCiAgIEhlcmUgaXMgYW4gZXhhbXBsZSBvZiB0aGUgU01UUCBzZXNzaW9uIGJldHdl ZW4gdGhlIE1UQXMgYXQNCiAgIGNvbnNvbGlkYXRlZG1lc3Nhbmdlci5uZXQgYW5kIGFsbWFtYXRl ci5lZHUuZXhhbXBsZS4NCg0KICAgICAgUzogMjIwIGFsbWFtYXRlci5lZHUuZXhhbXBsZSBFU01U UCBzZXJ2ZXIgcmVhZHkNCiAgICAgIEM6IEVITE8gbW9iaWxlLm5ldC5leGFtcGxlDQogICAgICBT OiAyNTAtYWxtYW1hdGVyLmVkdS5leGFtcGxlDQogICAgICBTOiAyNTAtRFNODQogICAgICBTOiAy NTAtQVVUSA0KICAgICAgUzogMjUwLVNVQk1JVFRFUg0KICAgICAgUzogMjUwIFNJWkUNCiAgICAg IEM6IE1BSUwgRlJPTTo8YWxpY2VAZXhhbXBsZS5jb20+DQogICAgICAgICAgICAgIFNVQk1JVFRF Uj1hbGljZUBtb2JpbGUubmV0LmV4YW1wbGUNCiAgICAgIFM6IDI1MCA8YWxpY2VAZXhhbXBsZS5j b20+IHNlbmRlciBvaw0KICAgICAgQzogUkNQVCBUTzo8Ym9iQGFsbWFtYXRlci5lZHUuZXhhbXBs ZT4NCiAgICAgIFM6IDI1MCA8Ym9iQGFsbWFtYXRlci5lZHUuZXhhbXBsZT4gcmVjaXBpZW50IG9r DQogICAgICBDOiBEQVRBDQogICAgICBTOiAzNTQgb2theSwgc2VuZCBtZXNzYWdlDQogICAgICBD OiBTZW5kZXI6IGFsaWNlQG1vYmlsZS5uZXQuZXhhbXBsZQ0KICAgICAgQzogUmVjZWl2ZWQgQnk6 IC4uLg0KICAgICAgQzogKG1lc3NhZ2UgYm9keSBnb2VzIGhlcmUpDQogICAgICBDOiAuDQogICAg ICBTOiAyNTAgbWVzc2FnZSBhY2NlcHRlZA0KICAgICAgQzogUVVJVA0KICAgICAgUzogMjIxIGdv b2RieWUNCg0KICAgTm90ZSB0aGF0IG1vYmlsZS5uZXQuZXhhbXBsZSB1c2VzIHRoZSBTVUJNSVRU RVIgcGFyYW1ldGVyIHRvDQogICBkZXNpZ25hdGUgYWxpY2VAbW9iaWxlLm5ldC5leGFtcGxlIGFz IHRoZSByZXNwb25zaWJsZSBzdWJtaXR0ZXIgZm9yDQogICB0aGlzIG1lc3NhZ2UuICBGdXJ0aGVy IHRoaXMgTVRBIGFsc28gaW5zZXJ0cyBhIFNlbmRlciBoZWFkZXIgdG8NCiAgIGVuc3VyZSB0aGUg cHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3MgZGVyaXZlZCBmcm9tIHRoZSBSRkMgMjgyMg0K ICAgaGVhZGVycyBtYXRjaGVzIHRoZSBTVUJNSVRURVIgYWRkcmVzcy4NCg0KICAgTGlrZXdpc2Us IGNvbnZlbnRpb25hbCBJU1BzIG1heSBhbHNvIGNob29zZSB0byB1c2UgdGhlIFNVQk1JVFRFUg0K ICAgcGFyYW1ldGVyIHRvIGRlc2lnbmF0ZSBhcyB0aGUgcmVzcG9uc2libGUgc3VibWl0dGVyIHRo ZSB1c2VyJ3MNCiAgIGFkZHJlc3Mgb24gdGhlIElTUCdzIG5ldHdvcmsgaWYgdGhhdCBhZGRyZXNz IGlzIGRpZmZlcmVudCBmcm9tIHRoZQ0KICAgTUFJTCBGUk9NIGFkZHJlc3MuDQoNCg0KDQpBbGxt YW4sIEthdHogICAgICAgICAgIEV4cGlyZXMgLSBGZWJydWFyeSAyMDA1ICAgICAgICAgICAgICAg W1BhZ2UgOF0NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIg RXh0ZW5zaW9uICAgICAgQXVndXN0IDIwMDQNCg0KDQogICBXaGVuIHRoZSBtZXNzYWdlIGlzIHN1 YnNlcXVlbnRseSBmb3J3YXJkZWQgYnkgdGhlDQogICBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUgTVRB LCB0aGF0IE1UQSB3aWxsIHJlcGxhY2UgdGhlIFNVQk1JVFRFUg0KICAgcGFyYW1ldGVyIHdpdGgg Ym9iQGFsbWFtYXRlci5lZHUuZXhhbXBsZSBhcyBpbiBzZWN0aW9uIDUuMiBhbmQgYWRkDQogICBp dHMgb3duIFJlc2VudC1Gcm9tIGhlYWRlci4NCg0KNS40IEd1ZXN0IEUtbWFpbCBTZXJ2aWNlDQoN CiAgIFdoaWxlIG9uIGEgYnVzaW5lc3MgdHJpcCwgQWxpY2UgdXNlcyB0aGUgYnJvYWRiYW5kIGFj Y2VzcyBmYWNpbGl0aWVzDQogICBwcm92aWRlZCBieSB0aGUgRXhlbXBsYXIgSG90ZWwgdG8gY29u bmVjdCB0byB0aGUgSW50ZXJuZXQgYW5kIHNlbmQgZS0NCiAgIG1haWwuICBUaGUgaG90ZWwgcm91 dGVzIGFsbCBvdXRib3VuZCBlLW1haWwgdGhyb3VnaCBpdHMgb3duIFNNVFANCiAgIHNlcnZlciwg ZW1haWwuaG90ZWwuY29tLmV4YW1wbGUuDQoNCiAgIFRoZSBTTVRQIHNlc3Npb24gZm9yIEFsaWNl J3MgbWVzc2FnZSB0byBCb2IgZnJvbSB0aGUgRXhlbXBsYXIgSG90ZWwNCiAgIHdvdWxkIGxvb2sg bGlrZSB0aGlzOg0KDQogICAgICBTOiAyMjAgYWxtYW1hdGVyLmVkdS5leGFtcGxlIEVTTVRQIHNl cnZlciByZWFkeQ0KICAgICAgQzogRUhMTyBlbWFpbC5ob3RlbC5jb20uZXhhbXBsZQ0KICAgICAg UzogMjUwLWFsbWFtYXRlci5lZHUuZXhhbXBsZQ0KICAgICAgUzogMjUwLURTTg0KICAgICAgUzog MjUwLUFVVEgNCiAgICAgIFM6IDI1MC1TVUJNSVRURVINCiAgICAgIFM6IDI1MCBTSVpFDQogICAg ICBDOiBNQUlMIEZST006PGFsaWNlQGV4YW1wbGUuY29tPg0KICAgICAgICAgICAgICBTVUJNSVRU RVI9Z3Vlc3Quc2VydmljZXNAZW1haWwuaG90ZWwuY29tLmV4YW1wbGUNCiAgICAgIFM6IDI1MCA8 YWxpY2VAZXhhbXBsZS5jb20+IHNlbmRlciBvaw0KICAgICAgQzogUkNQVCBUTzo8Ym9iQGFsbWFt YXRlci5lZHUuZXhhbXBsZT4NCiAgICAgIFM6IDI1MCA8Ym9iQGFsbWFtYXRlci5lZHUuZXhhbXBs ZT4gcmVjaXBpZW50IG9rDQogICAgICBDOiBEQVRBDQogICAgICBTOiAzNTQgb2theSwgc2VuZCBt ZXNzYWdlDQogICAgICBDOiBSZXNlbnQtRnJvbTogZ3Vlc3Quc2VydmljZXNAZW1haWwuaG90ZWwu Y29tLmV4YW1wbGUNCiAgICAgIEM6IFJlY2VpdmVkIEJ5OiAuLi4NCiAgICAgIEM6IChtZXNzYWdl IGJvZHkgZ29lcyBoZXJlKQ0KICAgICAgQzogLg0KICAgICAgUzogMjUwIG1lc3NhZ2UgYWNjZXB0 ZWQNCiAgICAgIEM6IFFVSVQNCiAgICAgIFM6IDIyMSBnb29kYnllDQoNCiAgIE5vdGUgdGhhdCBl bWFpbC5ob3RlbC5jb20uZXhhbXBsZSB1c2VzIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyIHRvDQog ICBkZXNpZ25hdGUgYSBnZW5lcmljIGFjY291bnQgZ3Vlc3Quc2VydmljZXNAZW1haWwuaG90ZWwu Y29tLmV4YW1wbGUgYXMNCiAgIHRoZSByZXNwb25zaWJsZSBzdWJtaXR0ZXIgYWRkcmVzcyBmb3Ig dGhpcyBtZXNzYWdlLiAgQSBnZW5lcmljDQogICBhY2NvdW50IGlzIHVzZWQgc2luY2UgQWxpY2Ug aGVyc2VsZiBkb2VzIG5vdCBoYXZlIGFuIGFjY291bnQgYXQgdGhhdA0KICAgZG9tYWluLiAgRnVy dGhlciB0aGlzIGNsaWVudCBhbHNvIGluc2VydHMgYSBSZXNlbnQtRnJvbSBoZWFkZXIgdG8NCiAg IGVuc3VyZSB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3MgZGVyaXZlZCBmcm9tIHRo ZSBSRkMgMjgyMg0KICAgaGVhZGVycyB3aXRoIHRoZSBTVUJNSVRURVIgYWRkcmVzcy4NCg0KICAg QXMgYmVmb3JlLCB3aGVuIHRoZSBtZXNzYWdlIGlzIHN1YnNlcXVlbnRseSBmb3J3YXJkZWQgYnkg dGhlDQogICBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUgTVRBLCB0aGF0IE1UQSB3aWxsIHJlcGxhY2Ug dGhlIFNVQk1JVFRFUg0KICAgcGFyYW1ldGVyIHdpdGggYm9iQGFsbWFtYXRlci5lZHUuZXhhbXBs ZSBhcyBpbiBzZWN0aW9uIDUuMiBhbmQgYWRkDQogICBpdHMgb3duIFJlc2VudC1Gcm9tIGhlYWRl ci4NCg0KDQpBbGxtYW4sIEthdHogICAgICAgICAgIEV4cGlyZXMgLSBGZWJydWFyeSAyMDA1ICAg ICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25zaWJs ZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICAgQXVndXN0IDIwMDQNCg0KDQoNCjUuNSBTVUJNSVRU RVIgVXNlZCBvbiBhIE5vbi1EZWxpdmVyeSBSZXBvcnQNCg0KICAgQWxpY2Ugc2VuZHMgYW4gaW5j b3JyZWN0bHkgYWRkcmVzc2VkIGUtbWFpbCBtZXNzYWdlIGFuZCByZWNlaXZlcyBhDQogICBub24t ZGVsaXZlcnkgcmVwb3J0IGZyb20gYSBTVUJNSVRURVItY29tcGxpYW50IHNlcnZlci4NCg0KICAg ICAgUzogMjIwIGV4YW1wbGUuY29tIEVTTVRQIHNlcnZlciByZWFkeQ0KICAgICAgQzogRUhMTyBh bG1hbWF0ZXIuZWR1LmV4YW1wbGUNCiAgICAgIFM6IDI1MC1leGFtcGxlLmNvbQ0KICAgICAgUzog MjUwLURTTg0KICAgICAgUzogMjUwLUFVVEgNCiAgICAgIFM6IDI1MC1TVUJNSVRURVINCiAgICAg IFM6IDI1MCBTSVpFDQogICAgICBDOiBNQUlMIEZST006PD4gU1VCTUlUVEVSPW1haWxlci1kYWVt b25AYWxtYW1hdGVyLmVkdS5leGFtcGxlDQogICAgICBTOiAyNTAgT0sNCiAgICAgIEM6IFJDUFQg VE86PGFsaWNlQGV4YW1wbGUuY29tPg0KICAgICAgUzogMjUwIE9LDQogICAgICBDOiBEQVRBDQog ICAgICBTOiAzNTQgT0ssIHNlbmQgbWVzc2FnZQ0KICAgICAgQzogKG1lc3NhZ2UgYm9keSBnb2Vz IGhlcmUpDQogICAgICBDOiAuDQogICAgICBTOiAyNTAgbWVzc2FnZSBhY2NlcHRlZA0KICAgICAg QzogUVVJVA0KICAgICAgUzogMjIxIGdvb2RieWUNCg0KDQo2LiBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucw0KDQogICBUaGlzIGV4dGVuc2lvbiBwcm92aWRlcyBhbiBvcHRpbWl6YXRpb24gdG8gYWxs b3cgYW4gU01UUCBjbGllbnQgdG8NCiAgIGlkZW50aWZ5IHRoZSByZXNwb25zaWJsZSBzdWJtaXR0 ZXIgb2YgYW4gZS1tYWlsIG1lc3NhZ2UgaW4gdGhlIFNNVFANCiAgIHByb3RvY29sLCBhbmQgdG8g ZW5hYmxlIFNNVFAgc2VydmVycyB0byBwZXJmb3JtIGVmZmljaWVudCB2YWxpZGF0aW9uDQogICBv ZiB0aGF0IGlkZW50aXR5IGJlZm9yZSB0aGUgbWVzc2FnZSBjb250ZW50cyBhcmUgdHJhbnNtaXR0 ZWQuDQoNCiAgIEl0IGlzLCBob3dldmVyLCBxdWl0ZSBwb3NzaWJsZSBmb3IgYW4gYXR0YWNrZXIg dG8gZm9yZ2UgdGhlIHZhbHVlIG9mDQogICB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlci4gIEZ1cnRo ZXJtb3JlLCBpdCBpcyBwb3NzaWJsZSBmb3IgYW4gYXR0YWNrZXINCiAgIHRvIHRyYW5zbWl0IGFu IGUtbWFpbCBtZXNzYWdlIHdob3NlIFNVQk1JVFRFUiBwYXJhbWV0ZXIgZG9lcyBub3QNCiAgIG1h dGNoIHRoZSBwdXJwb3J0ZWQgcmVzcG9uc2libGUgYWRkcmVzcyBvZiB0aGUgbWVzc2FnZSBhcyBk ZXJpdmVkDQogICBmcm9tIHRoZSBSRkMgMjgyMiBoZWFkZXJzLiAgVGhlcmVmb3JlIHRoZSBwcmVz ZW5jZSBvZiB0aGUgU1VCTUlUVEVSDQogICBwYXJhbWV0ZXIgcHJvdmlkZXMsIGJ5IGl0c2VsZiwg bm8gYXNzdXJhbmNlIG9mIHRoZSBhdXRoZW50aWNpdHkgb2YNCiAgIHRoZSBtZXNzYWdlIG9yIHRo ZSByZXNwb25zaWJsZSBzdWJtaXR0ZXIuICBSYXRoZXIsIHRoZSBTVUJNSVRURVINCiAgIHBhcmFt ZXRlciBpcyBpbnRlbmRlZCB0byBwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gcmVj ZWl2aW5nDQogICBlLW1haWwgc3lzdGVtcyB0byBlbmFibGUgdGhlbiB0byBlZmZpY2llbnRseSBk ZXRlcm1pbmUgdGhlIHZhbGlkaXR5DQogICBvZiB0aGUgcmVzcG9uc2libGUgc3VibWl0dGVyLCBh bmQgc3BlY2lmaWNhbGx5LCB3aGV0aGVyIHRoZSBTTVRQDQogICBjbGllbnQgaXMgYXV0aG9yaXpl ZCB0byB0cmFuc21pdCBlLW1haWwgb24gYmVoYWxmIG9mIHRoZSBwdXJwb3J0ZWQNCiAgIHJlc3Bv bnNpYmxlIHN1Ym1pdHRlcidzIGRvbWFpbi4gIFNlY3Rpb24gNC4yIGRlc2NyaWJlcyBob3cgcmVj ZWl2aW5nDQogICBlLW1haWwgc3lzdGVtcyBzaG91bGQgcHJvY2VzcyB0aGUgU1VCTUlUVEVSIHBh cmFtZXRlci4NCg0KDQoNCg0KDQpBbGxtYW4sIEthdHogICAgICAgICAgIEV4cGlyZXMgLSBGZWJy dWFyeSAyMDA1ICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwNCiAgICAgICAgICAgICAgICAgU01U UCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICAgQXVndXN0IDIwMDQNCg0KDQoN CjcuIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgSUFOQSBpcyBoZXJlYnkgcmVxdWVzdGVkIHRv IHJlZ2lzdGVyIHRoZSBTVUJNSVRURVIgU01UUCBzZXJ2aWNlDQogICBleHRlbnNpb24uDQoNCg0K OC4gUmVmZXJlbmNlcw0KDQo4LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgIFtBQk5GXSAg ICAgICAgIENyb2NrZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3lu dGF4DQogICAgICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgMjIzNCwg Tm92ZW1iZXIgMTk5Ny4NCg0KICAgIFtEU05dICAgICAgICAgIE1vb3JlLCBLLiwgIlNpbXBsZSBN YWlsIFRyYW5zZmVyIFByb3RvY29sIChTTVRQKQ0KICAgICAgICAgICAgICAgICAgIFNlcnZpY2Ug RXh0ZW5zaW9uIGZvciBEZWxpdmVyeSBTdGF0dXMgTm90aWZpY2F0aW9ucw0KICAgICAgICAgICAg ICAgICAgIChEU05zKSIsIFJGQyAzNDYxLCBKYW51YXJ5IDIwMDMuDQoNCiAgICBbS0VZV09SRFNd ICAgICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUN CiAgICAgICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5 LCBNYXJjaCAxOTk3Lg0KDQogICAgW01TRy1GT1JNQVRdICAgUmVzbmljaywgUC4sIEVkLiwgIklu dGVybmV0IE1lc3NhZ2UgRm9ybWF0IiwgUkZDDQogICAgICAgICAgICAgICAgICAgMjgyMiwgQXBy aWwgMjAwMS4NCg0KICAgIFtQUkFdICAgICAgICAgIEx5b24sIEouLCAiUHVycG9ydGVkIFJlc3Bv bnNpYmxlIEFkZHJlc3MgaW4gRS1tYWlsDQogICAgICAgICAgICAgICAgICAgTWVzc2FnZXMiLCBk cmFmdC1pZXRmLW1hcmlkLXByYS0wMCwgQXVndXN0IDIwMDQuDQogICAgICAgICAgICAgICAgICAg V29yayBpbiBwcm9ncmVzcy4NCg0KICAgIFtTRU5ERVItSURdICAgIEx5b24sIEouIGFuZCBNZW5n IFdlbmcgV29uZywgIlNlbmRlciBJRDoNCiAgICAgICAgICAgICAgICAgICBBdXRoZW50aWNhdGlu ZyBFLW1haWwiLCBkcmFmdC1pZXRmLW1hcmlkLWNvcmUtMDMsDQogICAgICAgICAgICAgICAgICAg QXVndXN0IDIwMDQuICBXb3JrIGluIHByb2dyZXNzLg0KDQogICAgW1NVQk1JVF0gICAgICAgR2Vs bGVucywgUi4gYW5kIEouIEtsZW5zaW4sICJNZXNzYWdlIFN1Ym1pc3Npb24iLCBSRkMNCiAgICAg ICAgICAgICAgICAgICAyNDc2LCBEZWNlbWJlciAxOTk4Lg0KDQogICAgW1NURF0gICAgICAgICAg QnJhZG5lciwgUy4sICJJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIGluIElFVEYNCiAgICAg ICAgICAgICAgICAgICBUZWNobm9sb2d5IiwgQkNQIDc5LCBSRkMgMzY2OCwgRmVicnVhcnkgMjAw NC4NCg0KICAgIFtTTVRQXSAgICAgICAgIEtsZW5zaW4sIEouLCAiU2ltcGxlIE1haWwgVHJhbnNm ZXIgUHJvdG9jb2wiLCBSRkMNCiAgICAgICAgICAgICAgICAgICAyODIxLCBBcHJpbCAyMDAxLg0K DQogICAgW1NNVFBBVVRIXSAgICAgTWV5ZXJzLCBKLiwgIlNNVFAgU2VydmljZSBFeHRlbnNpb24g Zm9yDQogICAgICAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24iLCBSRkMgMjU1NCwgTWFyY2gg MTk5OS4NCg0KOC4yIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgTm9uZS4NCg0KDQoNCg0K QWxsbWFuLCBLYXR6ICAgICAgICAgICBFeHBpcmVzIC0gRmVicnVhcnkgMjAwNSAgICAgICAgICAg ICAgW1BhZ2UgMTFdDQoMDQogICAgICAgICAgICAgICAgIFNNVFAgUmVzcG9uc2libGUgU3VibWl0 dGVyIEV4dGVuc2lvbiAgICAgIEF1Z3VzdCAyMDA0DQoNCg0KDQo5LiBBY2tub3dsZWRnbWVudHMN Cg0KICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayB0aGUgcGFydGljaXBhbnRzIG9m IHRoZSBNQVJJRCB3b3JraW5nDQogICBncm91cCBhbmQgdGhlIGZvbGxvd2luZyBpbmRpdmlkdWFs cyBmb3IgdGhlaXIgY29tbWVudHMgYW5kDQogICBzdWdnZXN0aW9ucywgd2hpY2ggZ3JlYXRseSBp bXByb3ZlZCB0aGlzIGRvY3VtZW50Og0KDQogICAgIFJvYmVydCBBdGtpbnNvbiwgU2ltb24gQXR0 d2VsbCwgUm95IEJhZGFtaSwgR3JlZyBDb25ub3IsIERhdmUNCiAgICAgQ3JvY2tlciwgTWF0dGhl dyBFbHZleSwgVG9ueSBGaW5jaCwgTmVkIEZyZWVkLCBNYXJrIExlbnRjem5lciwgSmltDQogICAg IEx5b24sIEJydWNlIE1jTWlsbGFuLCBTYW0gTmVlbHksIERhcnlsIE9kbmVydCwgTWFyZ2FyZXQg T2xzb24sIFBldGUNCiAgICAgUmVzbmljaywgSGVjdG9yIFNhbnRvcywgTmljayBTaGVsbmVzcywg UmFuZCBXYWNrZXIsIE1lbmcgV2VuZyBXb25nDQoNCg0KMTAuIEF1dGhvcnMnIEFkZHJlc3Nlcw0K DQogICBFcmljIEFsbG1hbg0KICAgU2VuZG1haWwsIEluYy4NCiAgIDY0MjUgQ2hyaXN0aWUgQXZl LCBTdWl0ZSA0MDANCiAgIEVtZXJ5dmlsbGUsIENBIDk0NjA4DQogICBVU0ENCg0KICAgRS1tYWls OiBlcmljQHNlbmRtYWlsLmNvbQ0KDQogICBIYXJyeSBLYXR6DQogICBNaWNyb3NvZnQgQ29ycC4N CiAgIDEgTWljcm9zb2Z0IFdheQ0KICAgUmVkbW9uZCwgV0EgOTgwNTINCiAgIFVTQQ0KDQogICBF LW1haWw6IGhrYXR6QG1pY3Jvc29mdC5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCkFsbG1hbiwgS2F0eiAgICAgICAgICAgRXhwaXJlcyAtIEZlYnJ1YXJ5IDIw MDUgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3Bv bnNpYmxlIFN1Ym1pdHRlciBFeHRlbnNpb24gICAgICBBdWd1c3QgMjAwNA0KDQoNCjExLiBDaGFu Z2UgSGlzdG9yeQ0KDQogICBUaGUgZm9sbG93aW5nIGNoYW5nZXMgd2VyZSBtYWRlIHRvIHRoaXMg ZG9jdW1lbnQgaW4gdGhlIC0wMyByZXZpc2lvbjoNCg0KICAgLSBpbiAxLCBhbWVuZGVkIHdvcmRp bmcgYWJvdXQgdGhlIGFkdmFudGFnZXMgb2YgYmFzaW5nIHZhbGlkYXRpb24gb24NCiAgICAgUkZD IDI4MjIgaGVhZGVycy4NCiAgIC0gaW4gNC4xLCBhbWVuZGVkIHdvcmRpbmcgdG8gdXNlICJudWxs IHJldmVyc2UtcGF0aCIgdG8gY29uZm9ybSB3aXRoDQogICAgIFJGQyAyODIxIHRlcm1pbm9sb2d5 Lg0KICAgLSBpbiA0LjEsIG1hZGUgU1VCTUlUVEVSIGEgTVVTVCBvbiBhbGwgbWVzc2FnZXMgZm9y IGNvbmZvcm1hbmNlLg0KICAgLSBpbiA0LjIsIGNoYW5nZWQgU0hPVUxEIHJlamVjdCB0byBNVVNU IHJlamVjdCB3aGVuIFNVQk1JVFRFUiB2YWx1ZQ0KICAgICBkb2VzIG5vdCBtYXRjaCBQUkEgdmFs dWUgZGVyaXZlZCBmcm9tIGhlYWRlcnMuDQogICAtIGluIDQuMiwgYWRkZWQgYSBwYXJhZ3JhcGgg bm90aW5nIHRoYXQgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIgaXMNCiAgICAgbm90IHRvIGJlIHVz ZWQgYXMgYSByZXZlcnNlLXBhdGggYWRkcmVzcy4NCiAgIC0gYWRkZWQgNS41LCBleGFtcGxlIG9m IFNVQk1JVFRFUiB1c2FnZSB3aGVuIHJldmVyc2UgcGF0aCBpcyBudWxsLg0KICAgLSBjaGFuZ2Vk IHNldmVyYWwgcmVmZXJlbmNlcyBmcm9tIFtTRU5ERVItSURdIHRvIFtQUkFdIHRvIHJlZmxlY3QN CiAgICAgY3JlYXRpb24gb2Ygc2VwYXJhdGUgW1BSQV0gZG9jdW1lbnQuDQogICAtIG1pbm9yIHdv cmRpbmcgY2hhbmdlcyBhbmQgY29ycmVjdGlvbnMgdGhyb3VnaG91dC4NCg0KICAgVGhlIGZvbGxv d2luZyBjaGFuZ2VzIHdlcmUgbWFkZSB0byB0aGlzIGRvY3VtZW50IGluIHRoZSAtMDIgcmV2aXNp b246DQoNCiAgIC0gb24gdGl0bGUgcGFnZSwgdXBkYXRlZCB0aGUgaW50ZWxsZWN0dWFsIHByb3Bl cnR5IGRlY2xhcmF0aW9uIHRvIGJlDQogICAgIGNvbnNpc3RlbnQgd2l0aCBSRkMgMzY2OC4NCiAg IC0gaW4gMSwgcmV3b3JrZWQgdGV4dCByZW1vdmluZyByZWZlcmVuY2VzIHRvIHZhcmlvdXMgYW50 aS1zcG9vZmluZw0KICAgICBwcm9wb3NhbHMgYW5kIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24g b2Ygc2V2ZXJhbCB0ZXJtcyB1c2VkDQogICAgIGhlcmVpbi4NCiAgIC0gaW4gNCwgcmVtb3ZlZCBy ZWR1bmRhbnQgdGV4dCBmcm9tIHRoZSBmaXJzdCBwYXJhZ3JhcGgNCiAgIC0gaW4gNC4xLCBzdHJl bmd0aGVuZWQgdGhlIGNvbmZvcm1hbmNlIHJlcXVpcmVtZW50cyBhbmQgYWRkZWQgdGhlDQogICAg IHJlY29tbWVuZGF0aW9uIGZvciBpbmNsdXNpb24gb2YgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIg ZXZlbiB3aGVuDQogICAgIHRoZSBNQUlMIEZST00gYWRkcmVzcyBpcyBpZGVudGljYWwgdG8gdGhl IHB1cnBvcnRlZCByZXNwb25zaWJsZQ0KICAgICBhZGRyZXNzLg0KICAgLSBpbiA0LjEsIHJlbW92 ZWQgd29yZGluZyBhYm91dCBtYWtpbmcgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXINCiAgICAgbWFu ZGF0b3J5IGF0IHNvbWUgZnV0dXJlIHRpbWUuDQogICAtIGluIDQuMSwgbW92ZWQgdGhlIHByb2Nl ZHVyYWwgZGVzY3JpcHRpb25zIGZvciBpbml0aWFsIG1lc3NhZ2UNCiAgICAgc3VibWlzc2lvbiBh bmQgc3Vic2VxdWVudCBtZXNzYWdlIHJldHJhbnNtaXNzaW9uIHRvIHRoZSBub24tDQogICAgIG5v cm1hdGl2ZSBFeGFtcGxlcyBzZWN0aW9uLg0KICAgLSBpbiA0LjIsIHJlbW92ZWQgdGhlIHdvcmRp bmcgYWJvdXQgcHJvY2VkdXJlcyB0byBiZSB1c2VkIGF0IHNvbWUNCiAgICAgZnV0dXJlIHRpbWUg d2hlbiB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciBiZWNvbWVzIG1hbmRhdG9yeQ0KICAgLSBpbiA0 LjIsIHNpZ25pZmljYW50IHJld29yZGluZyB0byBzaW1wbGlmeSBhbmQgY2xhcmlmeSB0aGUNCiAg ICAgdmVyaWZpY2F0aW9uIHByb2Nlc3MgYW5kIGVycm9yIG1lc3NhZ2VzLg0KICAgLSBpbiA0LjMs IGNsYXJpZmllZCB0aGUgd29yZGluZyB0byBpbmNsdWRlIGFsbCBjYXNlcyBvZiBtZXNzYWdlDQog ICAgIHRyYW5zbWlzc2lvbiB0byBhIG5vbi1TVUJNSVRURVIgYXdhcmUgc2VydmVyLg0KICAgLSBp biA1LCBjaGFuZ2VkIGV4YW1wbGUgYWRkcmVzc2VzIHRvIGJlIGNvbXBsaWFudCB3aXRoIFJGQyAy NjA2DQogICAtIGluIDYsIHJld29yZGluZyBhbmQgZm9jdXMgb24gc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgc3BlY2lmaWMgdG8NCiAgICAgdGhpcyBwcm9wb3NhbA0KICAgLSBhZGRlZCA3LCBJQU5B IENvbnNpZGVyYXRpb25zDQogICAtIGluIDgsIHJlbW92ZWQgdW5yZWZlcmVuY2VkIGluZm9ybWF0 aXZlIHJlZmVyZW5jZXMNCiAgIC0gbWlub3Igd29yZGluZyBjaGFuZ2VzIHRocm91Z2hvdXQuDQoN Cg0KDQoNCkFsbG1hbiwgS2F0eiAgICAgICAgICAgRXhwaXJlcyAtIEZlYnJ1YXJ5IDIwMDUgICAg ICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3BvbnNpYmxl IFN1Ym1pdHRlciBFeHRlbnNpb24gICAgICBBdWd1c3QgMjAwNA0KDQoNCjEyLiBGdWxsIENvcHly aWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAo MjAwNCkuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRoZSByaWdodHMsIGxpY2Vu c2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCBhbmQNCiAgIGV4Y2VwdCBh cyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMu DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGFyZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9S LCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQg QlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQNCiAgIEVO R0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1Ig SU1QTElFRCwNCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRI QVQgVEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5H RSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJ TElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KICAgSW50ZWxsZWN0 dWFsIFByb3BlcnR5DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0 aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmln aHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQNCiAgIHRvIHBlcnRhaW4g dG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQN CiAgIGluIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1 bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9y IGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBl ZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZvcm1hdGlvbg0KICAgb24gdGhl IHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBi ZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJUFIgZGlz Y2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBhc3N1cmFu Y2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFu DQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Np b24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVu dGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBm cm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRv IGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBh dGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBt YXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAg IHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElF VEYgYXQgaWV0Zi0NCiAgIGlwckBpZXRmLm9yZy4NCg0KDQpBY2tub3dsZWRnZW1lbnQNCg0KICAg RnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVk IGJ5IHRoZQ0KICAgSW50ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KDQoNCg0KDQpBbGxtYW4sIEth dHogICAgICAgICAgIEV4cGlyZXMgLSBGZWJydWFyeSAyMDA1ICAgICAgICAgICAgICBbUGFnZSAx NF0NCgw= ------_=_NextPart_001_01C4818F.858ACFC3-- From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 20:29: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 UAA27564 for ; Fri, 13 Aug 2004 20:29: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 i7E0FmZg077097; Fri, 13 Aug 2004 17:15:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7E0Fm0Z077096; Fri, 13 Aug 2004 17:15:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts36-srv.bellnexxia.net (tomts36.bellnexxia.net [209.226.175.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E0Fld0077090 for ; Fri, 13 Aug 2004 17:15:47 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040814001537.VHRX25796.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 13 Aug 2004 20:15:37 -0400 From: "John Glube" To: "'Harry Katz'" , "'Meng Weng Wong'" , "'Mark Lentczner'" , "'Andrew W. Donoho'" , "'Carl S. Gutekunst'" Cc: "'IETF MARID WG'" Subject: RE: What Meng said Date: Fri, 13 Aug 2004 20:15:06 -0400 Message-ID: <009701c48193$c5c2a560$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: <9C0060D6-ED59-11D8-93BF-000A9566A350@DDG.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 i7E0Fmd0077091 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Harry, If one goes to: http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.asp x A wizard has been set up to assist folks in publishing what is called an 'E-mail policy document' which can be used by people who have implemented Sender-ID I found this link by going to: http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx (It is referenced under related links.) If you run through the wizard, at the last page, you will find the following statement: Your E-Mail Policy Document must be published in DNS records of type TXT in the subdomain "_ep" under your domain. Consult the documentation of your DNS administration tools for further details on publishing this. It is my understanding: * the marid protocol for SPF (to be renamed Sender-ID) does not require publishing the 'E-Mail Policy Document' in the subdomain "_ep." * this is a carry over from the Caller-ID protocol. * with the merger of SPF and Sender-ID this requirement was dropped With the media drive now underway to get the word out about Sender-ID: * if people go to the SPF site they will receive one instruction for publishing an Sender Policy Framework in DNS records of type TXT; * if people go to the anti-spamtools.org site, people are going to be lead to believe they have to publish their 'E-Mail Policy Document' in DNS records of type TXT in the subdomain "_ep." With the ongoing issue of a change in version string and whether you have to publish one or two records, this raises concerns. I am not wanting to suggest any malice on anyone's part. I suspect what happened is that someone in setting up the wizard simply read the wrong document. If you scroll down the page at: http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx you will note that the: >Sender ID Draft Specification: MTA Authentication Records >in DNS" is the version dated June 23, 2004 which is now out of date. Can we get this rectified so that the wizard is based on the most recent version of the protocol? Otherwise I suspect people are going to be publishing the wrong records in the wrong place. John P.S. I also note the following additional statements on this page: http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx concerning the wizard. >Note: This tool is in beta, pending IETF approval. SPF >records created with this tool will require later revisions. >To check for the SPF record in incoming mail, your ISP or >system administrator will need to update to Sender >ID–compliant software to check for the Purported >Responsible Address (PRA) of incoming mail. >If you are a software developer and are interested in >implementing the PRA check in your software, please review >the terms of the Caller ID for E-Mail implementation >license agreement before you begin. Please note that >Microsoft does not require a license agreement for >individuals, companies, or ISPs who wish only to publish >their Sender ID SPF text records. I simply reference this material in passing. 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.734 / Virus Database: 488 - Release Date: 04/08/2004 From owner-ietf-mxcomp@mail.imc.org Fri Aug 13 21:56: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 VAA01935 for ; Fri, 13 Aug 2004 21:56: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 i7E1Umq7081982; Fri, 13 Aug 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 i7E1UmO3081980; Fri, 13 Aug 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 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 i7E1UhWr081963 for ; Fri, 13 Aug 2004 18:30: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 ED579414B7; Fri, 13 Aug 2004 18:30:45 -0700 (PDT) Subject: RE: Does marid-submitter-02 really make sense? From: Douglas Otis To: Mark Shewmaker Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092436440.15747.1376.camel@localhost.localdomain> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> <1092361125.7627.196.camel@ddev.mail-abuse.org> <1092368581.3295.1289.camel@localhost.localdomain> <1092419820.8257.100.camel@ddev.mail-abuse.org> <1092436440.15747.1376.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1092447044.8318.170.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 13 Aug 2004 18:30:44 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-13 at 15:34, Mark Shewmaker wrote: > On Fri, 2004-08-13 at 13:57, Douglas Otis wrote: > > On Thu, 2004-08-12 at 20:43, Mark Shewmaker wrote: > > > Or they'll go out of business. > > > > There is a high cost for spam where much of this is seen by the network > > provider. Taking away tools to curtail this abuse is not a good > > solution and can drive providers out of business. > > What tools to curtail abuse am I taking away? > > If a business loses money because their customers realize that they > can't trust that mail claiming to be most recently (re)sent into the > mail by them really was, then whether that distrust built up because > they didn't publish spf records or whether it built up because people > realized that the spf records they did publish could not be > trusted--either way their customers will leave. > > How is that taking away tools to curtail abuse? By transparently redirecting outbound SMTP connections, when a client is sending large volumes of mail not accepted because of invalid recipient names, as example, this will appear in their SMTP logs on the provider's machine forwarding this mail. This is also effective in catching Trojans that may also exist on their networks. This is an effective tool used to help abate abuse. It would seem the best solution for MTA servers sharing multiple domains would be to NOT publish any SPF or Sender-ID records. This would protect clients that might be harmed by repudiation services. I have yet to see such cautionary statements about publishing records when clients share common servers of differing domains. Although SPF could help reduce some of the spoof address bounces, Sender-ID will not. Neither SPF nor Sender-ID allows an effective means to abate abuse. Transparent redirection of the SMTP protocol does this effectively however. If the trade-off is for less spam or fewer options of which email address someone may use, I'll opt for less spam. It is folly to insist all mail servers will map on a one-to-one basis to domains just to suit Sender-ID repudiations. > > > Sorry--if my reputation system makes me give a poor reputation to > > > someone because they're using a shared MTA that allows cross-customer > > > forgeries, then my reputation system is doing it's job. > > > > Explain that in court. > > I describe my thoughts on how I figure out what I trust and don't trust, > and your response is that I'll have to explain it in court. > > And you still don't understand why I call this a thought crime? You claimed this identity could be submitted to a repudiation service. You also expect, if this allowed spam, you'd want to have that identity blocked in the future. By not assessing the channel, instead of the Sender-ID identity, grievous errors become possible. > > The provider guarding against abuse does not > > examine or change the content of the mail, they look for protocol > > generated errors. > > Well, I for one won't trust mail from mail servers run with such a > mindset as compared with mail from mail servers that have what is in my > opinion a more enlightened mindset. > > I can't imagine that in 5 years people would continue to find such > behavior as you claim as fact to be acceptable. I expect that mail > servers that don't validate the content of outgoing email (protecting > against cross-customer forgeries among other things) will tend to cause > such mails and their purported sending domains to be rated poorly, (when > the domain gives pass results to mail from those servers.) This is imposing a principle upon mail that does not currently exist. Evangelizing this scheme as some type of solution to abate abuse is troubling, when the opposite is true. It does not protect the RFC2822 >From in many cases, most of which will remain beyond the understanding of the mail consumer. The promise of checking these identities is also troubling with these many cases where such checks are meaningless, but never clarified. Although promoters of the Sender-ID scheme are savvy about the inability of this to curtail spam, this feature is always suggested to be the next step. The fact that this scheme does not provide a foundation for this next step is important, as most expect spam abatement was the initial motivation. Asking people to abandon methods that control spam while not allowing an alternative seems irresponsible. > > > If someone else can spoof trustworthy@trustworthy.com, then I hope my > > > reputation systems will assign a poor reputation to the trustworthy.com > > > domain, because any claims of anyone to be from there aren't, well, > > > trustworthy. > > > > The question should be, do you blame the mail system allowing mail to > > share MTA servers as designed, or do you blame repudiation services for > > not considering such cases. > > The problem is that trustworthy.com told me I could trust an untrustable > MTA. > > Trustworthy.com could go to a more trustworthy MSP, or they could try to > convince their MSP to disallow cross-customer forgeries. It seems folly to trust the RFC2822 headers without some stronger means of ensuring such assertions. SMTP does not offer a means to evaluate the security of the channel, nor does Sender-ID. Sender-ID makes fundamentally invalid assumptions such headers can be trusted. It would be better to authenticate the mail channel and added this identity to that of the RFC2822 From. This would provide far more clarity as to what is being trusted. You are not trusting the domain that originates the mail, you are trusting the last link in the chain providing the mail. Sender-ID seems willing to ignore this reality, and allow false assumptions about what can and cannot be checked. There can be special cases where such could be better assured, but this can not be generally applied, as Sender-ID suggests. > > The fact that trustworthy@trustworthy.com tells me to trust that a > > > message really comes from him if it comes through a specific IP still > > > doesn't mean I should trust such claims if I know that that specific IP > > > itself isn't trustworthy. > > > > Mail providers MUST NOT use Sender-ID when they can not ensure a > > ONE-TO-ONE relationship between Domain and Server. The draft should > > make this warning very clear, but it does not. > > I see no problem with a zillion domains having a single server as an > outbound MTA if that single server doesn't allow cross-customer > forgeries. You make this sound easy. This would not be one Sender-ID record per client, it would be a Sender-ID per message that must be read. It may take as much as 200 seconds to process per spec. At 10 seconds per message, that could increase equipment cost as much as 20 fold. The 20 second limit per record may put those in Europe and Asia at risk when on a different continent. Sender-ID records must always be closed for such protection, but open lists are allowed. What should happen to mail that does not have a Sender-ID record on these servers? Forgery protection then demands RFC2822 headers be examined and processed for the PRA, if there are records. This means every provider much sign a contract with Microsoft for this to happen. I saw nothing where terms of this contract will not change. It does prevent transfer of this contract however, which could be a problem when the service changes hands. Most MUAs allow setting the MAIL FROM parameter. Why not use that? If those phishing or spoofing use a Resent-From header, it is no worse than using the MAIL FROM. Always make the EHLO domain and MAIL FROM visible. At least this does reduce the spoof mail bounce problem and ensures everyone is checking the same parameter. It will also make spoofed mail stand out like a sore thumb with or without Sender-ID or SPF records. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Aug 14 02:12:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24218 for ; Sat, 14 Aug 2004 02:12:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E5rZXN019127; Fri, 13 Aug 2004 22:53: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 i7E5rZK3019126; Fri, 13 Aug 2004 22:53:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E5rXs1019021 for ; Fri, 13 Aug 2004 22:53:34 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7E5rXl2024069 for ; Sat, 14 Aug 2004 06:53:33 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7E5rXia024068; Sat, 14 Aug 2004 06:53:33 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Does marid-submitter-02 really make sense? References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> <1092361125.7627.196.camel@ddev.mail-abuse.org> <1092368581.3295.1289.camel@localhost.localdomain> <1092419820.8257.100.camel@ddev.mail-abuse.org> <1092436440.15747.1376.camel@localhost.localdomain> <1092447044.8318.170.camel@ddev.mail-abuse.org> From: Graham Murray Date: Sat, 14 Aug 2004 06:53:32 +0100 In-Reply-To: <1092447044.8318.170.camel@ddev.mail-abuse.org> (Douglas Otis's message of "Fri, 13 Aug 2004 18:30:44 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis writes: > It would seem the best solution for MTA servers sharing multiple domains > would be to NOT publish any SPF or Sender-ID records. This would > protect clients that might be harmed by repudiation services. I have > yet to see such cautionary statements about publishing records when > clients share common servers of differing domains. > > Although SPF could help reduce some of the spoof address bounces, > Sender-ID will not. Neither SPF nor Sender-ID allows an effective means > to abate abuse. Transparent redirection of the SMTP protocol does this > effectively however. If the trade-off is for less spam or fewer options > of which email address someone may use, I'll opt for less spam. It is > folly to insist all mail servers will map on a one-to-one basis to > domains just to suit Sender-ID repudiations. When an MTA serves multiple domains, either all of the email is originated on the MTA and all of the domains are under common ownership - which is possible but I suspect uncommon. In which case the problem is internal to the running of that system and outside the scope of this WG. Or, the emails are passed to the MTA, or MSA on the same system, by SMTP clients on other systems. Therefore, could (and should not) the shared MTA perform checks to ensure that the submitting system is authorised to send mail for the domain in the PRA of submitted email. Could the shared MTA not set up a 'private' (internal either to the MTA or to the origanisation running the MTA) DNS containing SPF, Sender-id or Domain-key records to indicate which systems are authorised to submit email (to the shared MTA) on behalf of each domain? Or, even easier especially where mail is submitted from dynamic IP addresses, require SMTP AUTH and have a separate authorisation 'user' for each domain. From owner-ietf-mxcomp@mail.imc.org Sat Aug 14 02:50: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 CAA27791 for ; Sat, 14 Aug 2004 02:50:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E6c8cV035833; Fri, 13 Aug 2004 23:38: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 i7E6c88o035832; Fri, 13 Aug 2004 23:38:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E6c7gE035808 for ; Fri, 13 Aug 2004 23:38:07 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7E6bu77005657 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 14 Aug 2004 02:37:57 -0400 Subject: RE: Does marid-submitter-02 really make sense? From: Mark Shewmaker To: Douglas Otis Cc: Shevek , MARID , Harry Katz In-Reply-To: <1092447044.8318.170.camel@ddev.mail-abuse.org> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> <1092361125.7627.196.camel@ddev.mail-abuse.org> <1092368581.3295.1289.camel@localhost.localdomain> <1092419820.8257.100.camel@ddev.mail-abuse.org> <1092436440.15747.1376.camel@localhost.localdomain> <1092447044.8318.170.camel@ddev.mail-abuse.org> Content-Type: text/plain Message-Id: <1092465698.18780.1427.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 14 Aug 2004 02:41:38 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Sat, 14 Aug 2004 02:37:58 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-13 at 21:30, Douglas Otis wrote: > On Fri, 2004-08-13 at 15:34, Mark Shewmaker wrote: > > What tools to curtail abuse am I taking away? > > By transparently redirecting outbound SMTP connections, when a client is > sending large volumes of mail not accepted because of invalid recipient > names, as example, this will appear in their SMTP logs on the provider's > machine forwarding this mail. This is also effective in catching > Trojans that may also exist on their networks. This is an effective > tool used to help abate abuse. And again, how am I taking that away? > It would seem the best solution for MTA servers sharing multiple domains > would be to NOT publish any SPF or Sender-ID records. This would > protect clients that might be harmed by repudiation services. You want MSPs to protect their customers by effectively muzzling their ability to publish SPF or Sender-ID records. How paternalistic. (If the MSP doesn't publish spf/senderID records, then their customers have nothing to reliably redirect: to.) Anyway, this still is unrelated to curtailing abuse, if by abuse you mean body header forgery, and your example confuses ISP mail service provider with non-ISP mail service providers. > I have yet to see such cautionary statements about publishing records when > clients share common servers of differing domains. It was discussed to death on spf-discuss, generally with the conclusion that people who are worried about this can suggest better wording on the various wizards and documents. I'm sure this is a problem that solves itself. Even if howtos aren't worded well, when people start publishing records saying others should trust non-trustworthy MTAs, customers will start demanding more secure MTAs. > Neither SPF nor Sender-ID allows an effective means to abate abuse. Please use a less generic word that "abuse" so it's easier to understand exactly what sort of abuse you're referring to. > It is folly to insist all mail servers will map on a one-to-one basis to > domains just to suit Sender-ID repudiations. You are the one insisting that that is the intent. > > > > Sorry--if my reputation system makes me give a poor reputation to > > > > someone because they're using a shared MTA that allows cross-customer > > > > forgeries, then my reputation system is doing it's job. > > > > > > Explain that in court. > > > > I describe my thoughts on how I figure out what I trust and don't trust, > > and your response is that I'll have to explain it in court. > > > > And you still don't understand why I call this a thought crime? > > You claimed this identity could be submitted to a repudiation service. > You also expect, if this allowed spam, you'd want to have that identity > blocked in the future. By not assessing the channel, instead of the > Sender-ID identity, grievous errors become possible. It's not an error--If a domain publishes a faulty/untrustworthy authentication record, I consider them an untrustworthy domain. > > I can't imagine that in 5 years people would continue to find such > > behavior as you claim as fact to be acceptable. I expect that mail > > servers that don't validate the content of outgoing email (protecting > > against cross-customer forgeries among other things) will tend to cause > > such mails and their purported sending domains to be rated poorly, (when > > the domain gives pass results to mail from those servers.) > > This is imposing a principle upon mail that does not currently exist. > Evangelizing this scheme as some type of solution to abate abuse is > troubling, when the opposite is true. It does not protect the RFC2822 > >From in many cases, most of which will remain beyond the understanding > of the mail consumer. For one, sender_agents can solve the bit of protecting the 2822 From:. And as for the other complaints, by definition pushing MTAs to disallow forgeries abates abuse of those MTAs. By definition having MTAs do virus checks on outbound mail abates abuse. If we weren't willing to change our expectations of what an MTA should do, we'd still have open relays everywhere. > What should happen to mail that does not have a Sender-ID record on > these servers? I imagine people will assign less trust mail purporting to come from those domains, given that such mail can be easily forged. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Sat Aug 14 06:30: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 GAA05958 for ; Sat, 14 Aug 2004 06:30: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 i7EADUrS010125; Sat, 14 Aug 2004 03: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 i7EADUnu010124; Sat, 14 Aug 2004 03:13:30 -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 i7EADSb5010075 for ; Sat, 14 Aug 2004 03:13:29 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BvvXO-0007ac-00 for ; Sat, 14 Aug 2004 12:13:24 +0200 Received: from 62.80.58.10 ([62.80.58.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Aug 2004 12:13:22 +0200 Received: from nobody by 62.80.58.10 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Aug 2004 12:13:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Changes for protocol-01 Date: Sat, 14 Aug 2004 12:09:04 +0200 Organization: Lines: 11 Message-ID: <411DE4C0.50BE@xyzzy.claranet.de> References: <2AAE79DE-ED79-11D8-850F-000393A56BB6@glyphic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.10 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: > * Added back %{p} macro that was removed in last rev BTW, %{t} is defined to be a "timestamp in UTC epoch seconds notation" and only used in exp= explanations. That's meant to be human readable (as error message copied into a bounce), so why not use a ISO 8601 timestamp ? Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sat Aug 14 11:07: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 LAA18277 for ; Sat, 14 Aug 2004 11:07: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 i7EEp0lv041140; Sat, 14 Aug 2004 07:51:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EEp0Iq041139; Sat, 14 Aug 2004 07:51: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 i7EEoxdq041130 for ; Sat, 14 Aug 2004 07:50:59 -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 7B18D4149B; Sat, 14 Aug 2004 07:51:02 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 14 Aug 2004 07:51:02 -0700 (PDT) Message-ID: <3053.64.142.13.68.1092495062.squirrel@harry.mail-abuse.org> In-Reply-To: References: <1092141740.19690.855.camel@localhost.localdomain><1092162895.25379.104.camel@ddev.mail-abuse.org><1092204280.19686.954.camel@localhost.localdomain><1092243820.5943.180.camel@ddev.mail-abuse.org><1092310765.3295.1043.camel@localhost.localdomain><1092330547.7445.101.camel@ddev.mail-abuse.org><1092351580.19686.1199.camel@localhost.localdomain><1092361125.7627.196.camel@ddev.mail-abuse.org><1092368581.3295.1289.camel@localhost.localdomain><1092419820.8257.100.camel@ddev.mail-abuse.org><1092436440.15747.1376.camel@localhost.localdomain><1092447044.8318.170.camel@ddev.mail-abuse.org> Date: Sat, 14 Aug 2004 07:51:02 -0700 (PDT) Subject: Re: Does marid-submitter-02 really make sense? From: "Douglas Otis" To: "Graham Murray" Cc: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Graham Murray writes: > Douglas Otis writes: > >> It would seem the best solution for MTA servers sharing multiple domains >> would be to NOT publish any SPF or Sender-ID records. This would >> protect clients that might be harmed by repudiation services. I have >> yet to see such cautionary statements about publishing records when >> clients share common servers of differing domains. >> >> Although SPF could help reduce some of the spoof address bounces, >> Sender-ID will not. Neither SPF nor Sender-ID allows an effective means >> to abate abuse. Transparent redirection of the SMTP protocol does this >> effectively however. If the trade-off is for less spam or fewer options >> of which email address someone may use, I'll opt for less spam. It is >> folly to insist all mail servers will map on a one-to-one basis to >> domains just to suit Sender-ID repudiations. > > When an MTA serves multiple domains, either all of the email is > originated on the MTA and all of the domains are under common > ownership - which is possible but I suspect uncommon. In which case > the problem is internal to the running of that system and outside the > scope of this WG. Or, the emails are passed to the MTA, or MSA on the > same system, by SMTP clients on other systems. Therefore, could (and > should not) the shared MTA perform checks to ensure that the > submitting system is authorised to send mail for the domain in the PRA > of submitted email. Could the shared MTA not set up a 'private' > (internal either to the MTA or to the origanisation running the MTA) > DNS containing SPF, Sender-id or Domain-key records to indicate which > systems are authorised to submit email (to the shared MTA) on behalf > of each domain? Or, even easier especially where mail is submitted > from dynamic IP addresses, require SMTP AUTH and have a separate > authorisation 'user' for each domain. Which domain is to be isolated by the provider? Now, in addition to the onerous limitations of the closed Sender-ID records for domains the customer may employ, (closed as this shared mode then requires) you want the provider to place a more severe restriction of a single domain regardless of the Sender-ID record? Either providers decide to endure the expensive overhead and check each message's Sender-ID record and sign contracts with Microsoft, or do nothing. Either way, there is no indication what was done nor that the MTA is shared. If some identity then becomes unfairly indicated to a repudiation checker, who is at fault? The message will likely say "Message blocked by company 'X' repudiaton services." Will company 'X' claim provider 'Y' MUST use Sender-ID? In other words, 'Y' MUST sign contracts with Microsoft or they become a party to the suit? I don't see how Company 'X' is protected assuming the world is using Sender-ID, especially when everyone is prohibited from using Sender-ID unless a contract is signed. Even if this were a free technology, there is still no method to check if the message had been checked at every shared point nor the related safety of an open record. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Aug 14 11: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 LAA19020 for ; Sat, 14 Aug 2004 11: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 i7EFFQBO043173; Sat, 14 Aug 2004 08:15:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EFFQav043172; Sat, 14 Aug 2004 08:15:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EFFNId043165 for ; Sat, 14 Aug 2004 08:15: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 350CC132DD7; Sat, 14 Aug 2004 11:19:28 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 137336B5; Sat, 14 Aug 2004 11:15:23 -0400 (EDT) Date: Sat, 14 Aug 2004 11:15:23 -0400 From: Meng Weng Wong To: Frank Ellermann Cc: ietf-mxcomp@imc.org Subject: Re: Changes for protocol-01 Message-ID: <20040814151523.GJ28401@dumbo.pobox.com> References: <2AAE79DE-ED79-11D8-850F-000393A56BB6@glyphic.com> <411DE4C0.50BE@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411DE4C0.50BE@xyzzy.claranet.de> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Aug 14, 2004 at 12:09:04PM +0200, Frank Ellermann wrote: | | Mark Lentczner wrote: | | > * Added back %{p} macro that was removed in last rev | | BTW, %{t} is defined to be a "timestamp in UTC epoch seconds | notation" and only used in exp= explanations. That's meant | to be human readable (as error message copied into a bounce), | so why not use a ISO 8601 timestamp ? | it's not meant to be human readable; it's meant to give a hint to the explanation CGI. for example, the cgi could read the time and bring up a custom response that says "sorry, our mail system was misconfigured last sunday and that is why you got the error message, please ignore it." From owner-ietf-mxcomp@mail.imc.org Sat Aug 14 12:03: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 MAA20118 for ; Sat, 14 Aug 2004 12:03: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 i7EFmxBK045851; Sat, 14 Aug 2004 08:48:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EFmx0i045850; Sat, 14 Aug 2004 08:48: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 i7EFmx1E045836 for ; Sat, 14 Aug 2004 08:48:59 -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 EDCD64149B; Sat, 14 Aug 2004 08:48:56 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 14 Aug 2004 08:48:56 -0700 (PDT) Message-ID: <3076.64.142.13.68.1092498536.squirrel@harry.mail-abuse.org> In-Reply-To: <1092465698.18780.1427.camel@localhost.localdomain> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> <1092361125.7627.196.camel@ddev.mail-abuse.org> <1092368581.3295.1289.camel@localhost.localdomain> <1092419820.8257.100.camel@ddev.mail-abuse.org> <1092436440.15747.1376.camel@localhost.localdomain> <1092447044.8318.170.camel@ddev.mail-abuse.org> <1092465698.18780.1427.camel@localhost.localdomain> Date: Sat, 14 Aug 2004 08:48:56 -0700 (PDT) Subject: RE: Does marid-submitter-02 really make sense? From: "Douglas Otis" To: "Mark Shewmaker" Cc: "Shevek" , "MARID" , "Harry Katz" 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 "Mark Shewmaker" writes: > On Fri, 2004-08-13 at 21:30, Douglas Otis wrote: >> On Fri, 2004-08-13 at 15:34, Mark Shewmaker wrote: >> > What tools to curtail abuse am I taking away? >> >> By transparently redirecting outbound SMTP connections, when a client is >> sending large volumes of mail not accepted because of invalid recipient >> names, as example, this will appear in their SMTP logs on the provider's >> machine forwarding this mail. This is also effective in catching >> Trojans that may also exist on their networks. This is an effective >> tool used to help abate abuse. > > And again, how am I taking that away? This lightweight tool stops working when it must examine each message content to find the PRA and potentially do hundreds of DNS lookups to verify the domain. Reading mail content may even run afoul of privacy concerns. Of course, changing these tools will require they sign a contact with Microsoft. And what about "open" records? Should "open" records never be used? >> It would seem the best solution for MTA servers sharing multiple domains >> would be to NOT publish any SPF or Sender-ID records. This would >> protect clients that might be harmed by repudiation services. > > You want MSPs to protect their customers by effectively muzzling their > ability to publish SPF or Sender-ID records. How paternalistic. Sender-ID removes a freedom to use a return mailbox address and requires a contract with Microsoft. Those that refuse to accept these new restrictions are paternalistic? > (If the MSP doesn't publish spf/senderID records, then their customers > have nothing to reliably redirect: to.) > > Anyway, this still is unrelated to curtailing abuse, if by abuse you > mean body header forgery, and your example confuses ISP mail service > provider with non-ISP mail service providers. You are confusing what is being curtailed with Sender-ID. You can not claim all message header forgeries can be detected. Even evidence of a verified Sender-ID identity sending a billion sexual aid remedy ads can not be assured to have been sent by this identity. Because of the potential for Sender-ID abuse, it could be well advised not to publish these records. >> I have yet to see such cautionary statements about publishing records >> when clients share common servers of differing domains. > > It was discussed to death on spf-discuss, generally with the conclusion > that people who are worried about this can suggest better wording on the > various wizards and documents. > > I'm sure this is a problem that solves itself. Even if howtos aren't > worded well, when people start publishing records saying others should > trust non-trustworthy MTAs, customers will start demanding more secure > MTAs. It would seem such advice should be found in the draft. >> Neither SPF nor Sender-ID allows an effective means to abate abuse. > > Please use a less generic word that "abuse" so it's easier to understand > exactly what sort of abuse you're referring to. We all know abuse when we see it. : ) You wish to claim Sender-ID has an ability to detect forged headers, but even curtailing this area of abuse is over-stated. Worse, it makes repudiation based upon this identity perilous. >> It is folly to insist all mail servers will map on a one-to-one basis to >> domains just to suit Sender-ID repudiations. > > You are the one insisting that that is the intent. Either everyone publishes "closed" lists and every MTA in the path of the mail checks for Sender-ID, or (as that checking can never be confirmed) every domain must send from their own servers. >> You claimed this identity could be submitted to a repudiation service. >> You also expect, if this allowed spam, you'd want to have that identity >> blocked in the future. By not assessing the channel, instead of the >> Sender-ID identity, grievous errors become possible. > > It's not an error--If a domain publishes a faulty/untrustworthy > authentication record, I consider them an untrustworthy domain. Again, this process of checking within the mail channel may not be in the senders control. The repudiation service should not make this assumption either. If there is a problem with the integrity of Sender-ID checks, who is at fault? You wish to claim the sender is always at fault. Sender-ID checks are done by the recipient however. As mail is often relayed, how can the sender be held accountable for those taking advantage of security problems later in the mail channel? >> This is imposing a principle upon mail that does not currently exist. >> Evangelizing this scheme as some type of solution to abate abuse is >> troubling, when the opposite is true. It does not protect the RFC2822 >> From in many cases, most of which will remain beyond the understanding >> of the mail consumer. > > For one, sender_agents can solve the bit of protecting the 2822 From:. > > And as for the other complaints, by definition pushing MTAs to disallow > forgeries abates abuse of those MTAs. By definition having MTAs do > virus checks on outbound mail abates abuse. > > If we weren't willing to change our expectations of what an MTA should > do, we'd still have open relays everywhere. Open relays were stopped by policy enforcement. This is something that can be tested by a third-party. The same is true for open-proxies. Saying that an MTA must not send a virus is an evolving problem where having a history by way of name would help with respect to the channel. Allowing the channel to assume a few million identities, as with Sender-ID, does not allow even a go slow 'if new' method of control. >> What should happen to mail that does not have a Sender-ID record on >> these servers? > > I imagine people will assign less trust mail purporting to come from > those domains, given that such mail can be easily forged. This would however allow the sender a means to avoid Sender-ID repudiation abuse. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Sat Aug 14 12:18: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 MAA20657 for ; Sat, 14 Aug 2004 12:18: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 i7EG50Z2046863; Sat, 14 Aug 2004 09:05:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EG50nF046862; Sat, 14 Aug 2004 09:05:00 -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 i7EG4vL5046849 for ; Sat, 14 Aug 2004 09:04:57 -0700 (PDT) (envelope-from millenix@zemos.net) Received: from fda.zemos.net (millenix-fda.no-ip.org[68.39.78.137]) by comcast.net (sccrmhc13) with ESMTP id <2004081416045101600qqmd3e>; Sat, 14 Aug 2004 16:04:51 +0000 Received: from localhost (fda [127.0.0.1]) by fda.zemos.net (Postfix) with ESMTP id A201B18696; Sat, 14 Aug 2004 12:04:48 -0400 (EDT) Received: from fda.zemos.net ([127.0.0.1]) by localhost (fda.zemos.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20064-02; Sat, 14 Aug 2004 12:04:48 -0400 (EDT) Received: from [10.0.0.2] (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id B4E4418694; Sat, 14 Aug 2004 12:04:47 -0400 (EDT) Message-ID: <411E3821.9070001@zemos.net> Date: Sat, 14 Aug 2004 12:04:49 -0400 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040810 Debian/1.7.2-2 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Dean Anderson Cc: "'IETF MARID WG'" Subject: Re: Analysis of SPF benefits for reduced filtering References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at fda.zemos.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dean Anderson wrote: > On Tue, 10 Aug 2004, Rand Wacker wrote: > >>On Tue, 10 Aug 2004, Dean Anderson wrote: >> >>>It has been reported that AOL is already using SPF to give reduced >>>filtering to SPF-using domains. Is this a good idea? >> >>Incorrect, see http://postmaster.aol.com/spf/: >>>AOL will begin using SPF records to maintain our whitelist in the near >>>future. If you want to remain on AOL's whitelist, you will need to >>>establish an SPF record for your domain as AOL will begin to query >>>whitelisted IP addresses from a domain's SPF record shortly. Without an >>>SPF record, your whitelist entries may expire. > > What do you mean by "establish an SPF record"? This just means putting an > SPF record in for your domain right? Is there something AOL-specific that > must go in this record? It means exactly what it says: publishing a TXT record with the magic number 'v=spf1', that complies with the draft SPF specs on spf.pobox.com. There are no AOL-specific modifiers or mechanisms in SPF. >>And you are right, giving *preferred* treatment for successful >>authentication (without other tools like a whitelist) is a bad thing to >>do. > > Ok, but if you already have a whitelist, what's the point of having SPF? AOL maintains a list of domains that have indicated to AOL that they are bulk mailers, and are willing to comply with AOL's rules for bulk mailers. One of those rules is that if AOL gets too many 'this is spam' complaints about messages from a domain on the list, that domain is removed from the list. Currently, AOL maintains a private list of IPs of these senders, entered by hand by the senders, which they call their 'whitelist'. AOL wants to replace a private, proprietary list with a distributed list accessible to anyone. It seems to me that this would be beneficial to other ISPs competing with AOL, because they would gain access to a large portion of the data AOL has collected. > One can easily use DJB's rbldns for a DNS whitelist, with practically the > same Sendmail/etc rule as a DNS blacklist. There's only a trivial config > difference between DNS whitelisting and DNS blacklisting. > > If you use SPF to maintain your whitelist, then anyone who creates an SPF > record will get whitelisted. Do you mean that only certain domains will be > whitelisted? If so, then it seems to me that SPF is just a proprietary > protocol for AOL to maintain its whitelist, and a way for AOL to > discourage outsourcing. Neither of these things seem to be in the > interests of the IETF or the internet community. Only domains that ask to be whitelisted by AOL get whitelisted. They must currently enter their outgoing MTA data into AOL's database by hand. AOL is moving from a proprietary database accessible only to them to a standardized, public, distributed database of senders. This puts the rest of the email-receiving world closer to even footing with AOL. SPF publication appears to be a new ADDITIONAL requirement to enter and stay on the whitelist. If anything, it replaces the manual entry of MTA IP addresses, which means less work for legitimate senders of all stripes. As for discouraging outsourcing, SPF makes it pretty easy to list outsourcers, via the include mechanism. > That said, you need more than just a whitelist. If you subject any email > to less filtering, and it is known from which domains you do that with, > you will encourage abusers to conduct abuse from those domains, and your > users will get more junk. Whitelisting has to be done carefully, and its > more of a response to abusive blacklists by selectively rejecting the > blacklist than a rational response to spam. If those 'known whitelisted' domains all use SPF, then how will abusers conduct abuse from those domains? > We also whitelists, but only around particular filter flaws: One of things > we do is count each occurance of an IP address in headers. Too bulky, and > messages with that IP address get queued instead of delivered. This test > has to be disabled for common addresses (192.168/16, 172.16/14, and 10/8) > as well as our own mailservers and those of large ISPs. This only modifies > _this_ particular test, and only because _this_ test is invalid if there > is genuinely a lot of email from a particular IP address. But I would not > want to whitelist just any domain that has an SPF record. That would be > bad. You can do whatever you like on your mail servers. AOL is telling the world of email administrators that if they want their mail to continue to be delivered to AOL, they must publish SPF records. They are not lowering any barrier, they are raising another one. > But I have some doubts about the overall validity of that bulkiness test. > If the test were valid, it might in fact be helpful if Large ISPs did > identify their outbound servers. However, finding out this information is > not hard, if only you monitor your mail queues. It hardly seems worth the > trouble of an IETF protocol. And if an ISP suddenly brings a new MTA infrastructure online, they should wait until individual administrators see it being rejected in their logs and enter it by hand? Senders should bear the burden of identifying themselves. You seem to indicate that every domain that runs an MX should take responsibility for identifying legitimate sources independently, without the benefit of information that those senders can publish, and that other ISPs have already gathered. >>Subjecting /un-authenticated/ messages to increased scrutiny might be >>justified to do though (as Microsoft has announced they will start >>doing). > > I'd like to draw your attention to relativity: > Subjecting /un-authenticated/ messages to _more_scrutiny_ is the same as > subjecting authenticated messages to _less_scrutiny_ How about authenticated messages are treated exactly as all messages currently are, while unauthenticated messages receive more scrutiny than all messages receive at present? Regards, Philip Miller From owner-ietf-mxcomp@mail.imc.org Sat Aug 14 17:59: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 RAA03437 for ; Sat, 14 Aug 2004 17:59: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 i7ELdSo2069029; Sat, 14 Aug 2004 14:39:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ELdSPO069028; Sat, 14 Aug 2004 14:39:28 -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 i7ELdPMX069019 for ; Sat, 14 Aug 2004 14:39:27 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 30371 invoked from network); 14 Aug 2004 21:41:06 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 14 Aug 2004 21:41:06 -0000 In-Reply-To: <20040813065604.GI28401@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <69DF0558-EE3A-11D8-8640-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: Mark Lentczner , IETF MARID WG From: Margaret Olson Subject: Re: What Meng said Date: Sat, 14 Aug 2004 17:39:25 -0400 To: Meng Weng Wong 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 Here's how I'm interpreting the practical implications of this, please tell me if I'm just misunderstanding you: If I want my record to be evaluated based on the PRA algorithm then I MUST use SUBMITTER If I want my record to be evaluated based on MAIL FROM then I MUST NOT use SUBMITTER and my PRA MUST be the same as the MAIL FROM. How does this work when the receiving side doesn't understand SUBMITTER? Margaret. On Aug 13, 2004, at 2:56 AM, Meng Weng Wong wrote: > > I agree with everything Mark says, so I must have > communicated my position poorly :) > > If I could have one more chance to explain my thinking, > let's cut to the chase: > > On Wed, Aug 11, 2004 at 02:38:38PM -0700, Mark Lentczner wrote: > | else client supplies just Mail From { > | r2 = check MAIL FROM against its Sender-ID record (hoping it will > | be same as PRA) > | > | accept body of message > | extract PRA from headers > | if PRA == MAIL FROM { exit with r2 } > | > | r3 = check PRA against its Sender-ID record > | exit with r3 > | } > > I agree that this is how Sender ID should work. > > My question is: can you reject if the r2 result is FAIL? > > I think you can. Here's why. > > The forwarding scenario is, of course, our weak link. > > Under SPF Classic, noncompliant forwarders who didn't do SRS > could expect to get their mail rejected. > > Under Sender ID, noncompliant forwarders who don't prepend a > Resent-From header could expect to get their mail rejected. > > Under Sender ID, noncompliant forwarders who don't offer a > SUBMITTER parameter could expect to get their mail rejected. > > In all cases, noncompliant forwarders get their mail > rejected. > > Therefore, immediately rejecting after MAIL if (the > SUBMITTER value is not provided and r2 is FAIL), is no worse > than continuing to accept the message and extracting the > PRA, because the PRA can be expected to fail anyway if it's > forwarding. > > This means that we *can* safely assume, > in the absence of SUBMITTER, that MAIL-FROM == PRA, > whether or not we think the sender is omitting it because > 1) they are not Sender-ID aware, or > 2) they are aware and Mail-From == PRA. > > If we do this, then the essential requirements of the SPF > Classic community are respected in Sender ID. > > I do not think this course of action harms the essential > requirements of Caller ID so why not make both sides happy? > > Back to the algorithm: > > | else client supplies just Mail From { > | r2 = check MAIL FROM against its Sender-ID record (hoping it will > | be same as PRA) > > so, if the r2 is FAIL, reject. if the r2 is PASS, proceed. > > | accept body of message > | extract PRA from headers > | if PRA == MAIL FROM { exit with r2 } > | > | r3 = check PRA against its Sender-ID record > | exit with r3 > | } > > the important requirement for me is being able to, when > SUBMITTER is absent, reject based on a MAIL FROM fail > result, and being able to, when SUBMITTER is absent, accept > based on a MAIL FROM pass result. > > If course if SUBMITTER is provided that overrides the > return-path, but i really would like to be able to avoid > going into the headers upon FAIL. > > If the result is a PASS then going into the headers is fine > by me; we would then check that the PRA either matches the > MAIL FROM or passes an SPF check directly. > > (non-SUBMITTER compliant VERP mailing lists with Sender: > owner-listname are a good case where PRA != MAIL-FROM but > spf_check(PRA) == PASS == spf_check(MAIL-FROM)). > > perhaps some data can tell whether such an algorithm would > be more or less prone to error in the field. > > From owner-ietf-mxcomp@mail.imc.org Sat Aug 14 22:56:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14233 for ; Sat, 14 Aug 2004 22: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 i7F2RpTf085714; Sat, 14 Aug 2004 19:27: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 i7F2RpH6085713; Sat, 14 Aug 2004 19:27: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 i7F2RoIH085703 for ; Sat, 14 Aug 2004 19:27:51 -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 i7F2Roll015168 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 14 Aug 2004 22:27:52 -0400 Date: Sat, 14 Aug 2004 22:27:50 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Philip Miller cc: "'IETF MARID WG'" Subject: Re: Analysis of SPF benefits for reduced filtering In-Reply-To: <411E3821.9070001@zemos.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, 14 Aug 2004, Philip Miller wrote: > Dean Anderson wrote: > > On Tue, 10 Aug 2004, Rand Wacker wrote: > > > >>On Tue, 10 Aug 2004, Dean Anderson wrote: > >> > >>>It has been reported that AOL is already using SPF to give reduced > >>>filtering to SPF-using domains. Is this a good idea? > >> > >>Incorrect, see http://postmaster.aol.com/spf/: > >>>AOL will begin using SPF records to maintain our whitelist in the near > >>>future. If you want to remain on AOL's whitelist, you will need to > >>>establish an SPF record for your domain as AOL will begin to query > >>>whitelisted IP addresses from a domain's SPF record shortly. Without an > >>>SPF record, your whitelist entries may expire. > > > > What do you mean by "establish an SPF record"? This just means putting an > > SPF record in for your domain right? Is there something AOL-specific that > > must go in this record? > > It means exactly what it says: publishing a TXT record with the magic number 'v=spf1', > that complies with the draft SPF specs on spf.pobox.com. There are no AOL-specific > modifiers or mechanisms in SPF. Ok, that's what I thought. > >>And you are right, giving *preferred* treatment for successful > >>authentication (without other tools like a whitelist) is a bad thing to > >>do. > > > > Ok, but if you already have a whitelist, what's the point of having SPF? > > AOL maintains a list of domains that have indicated to AOL that they are > bulk mailers, and are willing to comply with AOL's rules for bulk > mailers. One of those rules is that if AOL gets too many 'this is spam' > complaints about messages from a domain on the list, that domain is > removed from the list. Currently, AOL maintains a private list of IPs of > these senders, entered by hand by the senders, which they call their > 'whitelist'. AOL wants to replace a private, proprietary list with a > distributed list accessible to anyone. Others also already do this, but don't need a special protocol to implement it. Further, it is still a proprietary, AOL-specific whitelist. > It seems to me that this would be beneficial to other ISPs competing > with AOL, because they would gain access to a large portion of the data > AOL has collected. I don't see how this puts anyone else on an equal footing. Its rather like the "standards" published by Microsoft. Microsoft makes the same claims about those standards, too. But we know that in fact they benefit Microsoft. > > One can easily use DJB's rbldns for a DNS whitelist, with practically the > > same Sendmail/etc rule as a DNS blacklist. There's only a trivial config > > difference between DNS whitelisting and DNS blacklisting. > > > > If you use SPF to maintain your whitelist, then anyone who creates an SPF > > record will get whitelisted. Do you mean that only certain domains will be > > whitelisted? If so, then it seems to me that SPF is just a proprietary > > protocol for AOL to maintain its whitelist, and a way for AOL to > > discourage outsourcing. Neither of these things seem to be in the > > interests of the IETF or the internet community. > > Only domains that ask to be whitelisted by AOL get whitelisted. They must currently enter > their outgoing MTA data into AOL's database by hand. AOL is moving from a proprietary > database accessible only to them to a standardized, public, distributed database of > senders. This puts the rest of the email-receiving world closer to even footing with AOL. I think its not public (the whitelist). Only _some_ domains that use SPF will have privileges. This is just a whitelist. > SPF publication appears to be a new ADDITIONAL requirement to enter and stay on the > whitelist. If anything, it replaces the manual entry of MTA IP addresses, which means less > work for legitimate senders of all stripes. > > As for discouraging outsourcing, SPF makes it pretty easy to list outsourcers, via the > include mechanism. Its also pretty easy to deny outsourcers, via refusing to use the include mechanism. This is my main objection. Outsourcing isn't something that AOL or anyone else can be allowed to have any control over. Giving such control to AOL or others is an actual harm. The rest of my objections about failure to work, failure to stop spam, etc aren't actual harms, they just mean the SPF effort is a waste of time. Your waste of time doesn't ordinarilly harm anyone, except in this case, as above. > > That said, you need more than just a whitelist. If you subject any email > > to less filtering, and it is known from which domains you do that with, > > you will encourage abusers to conduct abuse from those domains, and your > > users will get more junk. Whitelisting has to be done carefully, and its > > more of a response to abusive blacklists by selectively rejecting the > > blacklist than a rational response to spam. > > If those 'known whitelisted' domains all use SPF, then how will abusers > conduct abuse from those domains? That's easy. They conduct abuse the same as they do now: They can either forge other users at that whitelisted domain, or they can use disposable accounts at the whitelisted domain, or they can steal accounts from the whitelisted domain. Your misconception here is well-known and unfortunately common. The is misconception that somehow the abusers can't choose to use the relays of the ISP they are using. But of course they can, and of course the ISP's relays offer the same benefits as open relays. But in fact, most abuse doesn't use the ISP's relays, nor does it use open relays. At present, most abuse connects directly. But that's just a rather arbitrary choice made by the abuser. They can always choose to use the ISP's relays, and they always have 3 basic choices of how to abuse the ISP's domain. They connect directly at present merely because its easier than figuring out the correct ISP relays. What your misconception boils down to is the assumption that abusers don't make some arbitrary choices about how to send email and can't adapt. This has been common to every failed anti-spam technique. > > We also whitelists, but only around particular filter flaws: One of things > > we do is count each occurance of an IP address in headers. Too bulky, and > > messages with that IP address get queued instead of delivered. This test > > has to be disabled for common addresses (192.168/16, 172.16/14, and 10/8) > > as well as our own mailservers and those of large ISPs. This only modifies > > _this_ particular test, and only because _this_ test is invalid if there > > is genuinely a lot of email from a particular IP address. But I would not > > want to whitelist just any domain that has an SPF record. That would be > > bad. > > You can do whatever you like on your mail servers. AOL is telling the world of email > administrators that if they want their mail to continue to be delivered to AOL, they must > publish SPF records. They are not lowering any barrier, they are raising another one. First, they aren't actually doing that. They are just 'maintaining a whitelist'. Second, they aren't ever likely to do that, for exactly the same reason they don't require the foolish in-addr check. Not everyone will have the records, and AOL won't be able to refuse email because of that. All they can do is choose to lessen the filtering applied to those with SPF records. That's a lowering of the barrier. Oh, and they will also be able to interfere with outsourcing. Interference could come in the form of outright refusal or extortion of fees, service interference through "unfortunately" unreliable records, etc. > > But I have some doubts about the overall validity of that bulkiness test. > > If the test were valid, it might in fact be helpful if Large ISPs did > > identify their outbound servers. However, finding out this information is > > not hard, if only you monitor your mail queues. It hardly seems worth the > > trouble of an IETF protocol. > > And if an ISP suddenly brings a new MTA infrastructure online, they should wait until > individual administrators see it being rejected in their logs and enter it by hand? > Senders should bear the burden of identifying themselves. Not senders: recipients. The recipients monitor their logs and when they see a bulky sender IP, they check it out. The reason that this might not be helpful is that abusers can adapt their sending pattern so as not to appear bulky. Thus, such a check might not be valid. > You seem to indicate that every domain that runs an MX should take > responsibility for identifying legitimate sources independently, without > the benefit of information that those senders can publish, and that > other ISPs have already gathered. Yep. The reciever can't just trust the sender isn't sending spam. Non-abuser can publish information. Abusers can publish the same information. Imagine a Bank that asked its customers for their credit rating. > >>Subjecting /un-authenticated/ messages to increased scrutiny might be > >>justified to do though (as Microsoft has announced they will start > >>doing). > > > > I'd like to draw your attention to relativity: > > Subjecting /un-authenticated/ messages to _more_scrutiny_ is the same as > > subjecting authenticated messages to _less_scrutiny_ > > How about authenticated messages are treated exactly as all messages currently are, while > unauthenticated messages receive more scrutiny than all messages receive at present? Same thing. Abusers can "authenticate" themselves, and get less scrutiny. There is no reason to conclude that MSN will have less abusers with SPF than without SPF. In fact, once the word is out that MSN is subjected to less scrutiny, abusers will seek out MSN accounts. This means that AOL gets more spam and MSN gets more abusers. Good plan. Then maybe MSN and AOL will then halt services, and abusers won't be smart enough to go to other providers.... --Dean From owner-ietf-mxcomp@mail.imc.org Sun Aug 15 13:32: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 NAA09392 for ; Sun, 15 Aug 2004 13:32: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 i7FH9Ejj055523; Sun, 15 Aug 2004 10:09: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 i7FH9EjW055522; Sun, 15 Aug 2004 10:09:14 -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 i7FH9D2Y055514 for ; Sun, 15 Aug 2004 10:09:13 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040815170913.FJPI25796.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd>; Sun, 15 Aug 2004 13:09:13 -0400 From: "John Glube" To: "'Margaret Olson'" , "'Meng Weng Wong'" Cc: "'Mark Lentczner'" , "'Dave Crocker'" , "'IETF MARID WG'" Subject: RE: What Meng said Date: Sun, 15 Aug 2004 13:11:10 -0400 Message-ID: <004901c482ea$dcf999c0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <69DF0558-EE3A-11D8-8640-000A95BC6A7E@margaretolson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7FH9D2Y055517 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Margaret Olson wrote on August 14, 2004 at 5:39 PM >Here's how I'm interpreting the practical implications of this, >please tell me if I'm just misunderstanding you: >If I want my record to be evaluated based on the PRA algorithm >then I MUST use SUBMITTER >If I want my record to be evaluated based on MAIL FROM then I >MUST NOT use SUBMITTER and my PRA MUST be the same as the MAIL >FROM. >How does this work when the receiving side doesn't understand >SUBMITTER? Okay, let me venture forth ... and kick the ball a bit further down the field and ask some additional questions: * Based on the newest drafts, is it correct to state that Sender-ID will only read the spf/pra02 version string. * Prudent senders will therefore have to publish a v=spf1 version string in the TXT record and spf/pra02 in the DNS RR type SPF2. * Will Submitter compliant Senders only use Sender, or will you want to include SMTP Mail From in case the receiver can't read Submitter and is only using SPF? * Would the best practice be to have the domain in Sender and SMTP mail from the same? * What about CSV? Should prudent senders also be publishing the version string for CSV? How will Submitter compliant senders relate to receivers for example who are using CSV and SPF, but not Sender-ID for licensing reasons? I raise these questions as: * The WG has apparently decided to go down the consecutive as opposed to the concurrent path. * This means each protocol will use its own version string, as opposed to one version string serving all protocols. * We are now confronted which inter-operability issues, so making things even more complex. * These are questions which need to be answered. In my view, while it is all very nice to say: * Sender-ID will only read sender-id records and CSV will only read CSV records, We need to ensure a sender can transmit to someone who is relying on any one or more of: SPF, (Even if SPF is not a formal protocol, it exists in the wild and unfortunately the most recent Sender-ID protocol version does not to the best of my understanding give even the minimal compromise that Meng was asking for to carry the SPF community forward with Sender-ID. Therefore, please don't be surprised if ultimately many in the SPF open source community simply respond by rejecting Sender-ID.), Sender-ID and CSV, (which don't yet exist in the wild to any significant extent), Otherwise we will end up with a mess. Thanks John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Sun Aug 15 14:56: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 OAA13214 for ; Sun, 15 Aug 2004 14:56: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 i7FIcjJE062669; Sun, 15 Aug 2004 11:38: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 i7FIcj4I062668; Sun, 15 Aug 2004 11:38:45 -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 i7FIcitH062633 for ; Sun, 15 Aug 2004 11:38:45 -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 1BwPtu-000IYF-00; Sun, 15 Aug 2004 19:38:38 +0100 Message-ID: <013801c482f6$bf421040$0200000a@ringo> From: "Chris Haynes" To: "Margaret Olson" Cc: "Mark Lentczner" , "Meng Weng Wong" , "IETF MARID WG" References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <69DF0558-EE3A-11D8-8640-000A95BC6A7E@margaretolson.com> Subject: Re: What Meng said Date: Sun, 15 Aug 2004 19:36:12 +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 Forgive me for suggesting a clarification to one of your assertions. Your assertion " If I want my record to be evaluated based on MAIL FROM then I MUST NOT use SUBMITTER and my PRA MUST be the same as the MAIL FROM." implies that Sender-ID contains a distinct process for evaluating MAIL-FROM (as in SPF). I believe this not to be the case. In an off-list communication Mark Lentczner pointed out that: "The MAIL-FROM domain check is only a speculative optimization. If it doesn't match PRA, it isn't used." As I understand it, if there is no SUBMITTER, the domain of a MAIL-FROM is used as the domain from which the record is extracted, but the way in which this record is then processed is as if this were the PRA-derived domain. When the PRA later becomes available, its domain is compared with that derived from the MAIL-FROM. If they are different, the record and any provisional test results derived from the MAIL-FROM are discarded, and the record for the domain identified by the PRA is now collected and tested. In other words that is no sense in which any record is ever "evaluated based on MAIL-FROM"; the tests / algorithms applied will always be those associated with the PRA. The optimization derived from using MAIL-FROM is the opportunity to fetch and start testing the record, in the hope that, when the PRA is eventually determined, the correct record is found to have been used. No definitive tests are concluded at 2821-time, the information derived from MAIL-FROM can never result in a decision at 2821-time to reject the message, so the SMTP DATA phase and PRA establishment will always take place. If the domain of MAIL-FROM is different from that of the PRA, its record has no functional impact whatsoever on the evaluation of the message - which is, I trust, a fair re-phrasing of Mark's observation. If SUBMITTER is used, it is possible to reject some messages at 2821-time (see section 4.2 of draft submitter-03.txt) and thereby save the bandwidth / time of the DATA phase - so I can see no benefit whatsoever in a client deliberately omitting the SUBMITTER when the receiver is prepared to accept it. Chris Haynes "Margaret Olson" asked on Saturday, August 14, 2004 10:39 PM: > > Here's how I'm interpreting the practical implications of this, please > tell me if I'm just misunderstanding you: > > If I want my record to be evaluated based on the PRA algorithm then I > MUST use SUBMITTER > If I want my record to be evaluated based on MAIL FROM then I MUST NOT > use SUBMITTER and my PRA MUST be the same as the MAIL FROM. > > How does this work when the receiving side doesn't understand SUBMITTER? > > Margaret. > > On Aug 13, 2004, at 2:56 AM, Meng Weng Wong wrote: > > > > > I agree with everything Mark says, so I must have > > communicated my position poorly :) > > > > If I could have one more chance to explain my thinking, > > let's cut to the chase: > > > > On Wed, Aug 11, 2004 at 02:38:38PM -0700, Mark Lentczner wrote: > > | else client supplies just Mail From { > > | r2 = check MAIL FROM against its Sender-ID record (hoping it will > > | be same as PRA) > > | > > | accept body of message > > | extract PRA from headers > > | if PRA == MAIL FROM { exit with r2 } > > | > > | r3 = check PRA against its Sender-ID record > > | exit with r3 > > | } > > > > I agree that this is how Sender ID should work. > > > > My question is: can you reject if the r2 result is FAIL? > > > > I think you can. Here's why. > > > > The forwarding scenario is, of course, our weak link. > > > > Under SPF Classic, noncompliant forwarders who didn't do SRS > > could expect to get their mail rejected. > > > > Under Sender ID, noncompliant forwarders who don't prepend a > > Resent-From header could expect to get their mail rejected. > > > > Under Sender ID, noncompliant forwarders who don't offer a > > SUBMITTER parameter could expect to get their mail rejected. > > > > In all cases, noncompliant forwarders get their mail > > rejected. > > > > Therefore, immediately rejecting after MAIL if (the > > SUBMITTER value is not provided and r2 is FAIL), is no worse > > than continuing to accept the message and extracting the > > PRA, because the PRA can be expected to fail anyway if it's > > forwarding. > > > > This means that we *can* safely assume, > > in the absence of SUBMITTER, that MAIL-FROM == PRA, > > whether or not we think the sender is omitting it because > > 1) they are not Sender-ID aware, or > > 2) they are aware and Mail-From == PRA. > > > > If we do this, then the essential requirements of the SPF > > Classic community are respected in Sender ID. > > > > I do not think this course of action harms the essential > > requirements of Caller ID so why not make both sides happy? > > > > Back to the algorithm: > > > > | else client supplies just Mail From { > > | r2 = check MAIL FROM against its Sender-ID record (hoping it will > > | be same as PRA) > > > > so, if the r2 is FAIL, reject. if the r2 is PASS, proceed. > > > > | accept body of message > > | extract PRA from headers > > | if PRA == MAIL FROM { exit with r2 } > > | > > | r3 = check PRA against its Sender-ID record > > | exit with r3 > > | } > > > > the important requirement for me is being able to, when > > SUBMITTER is absent, reject based on a MAIL FROM fail > > result, and being able to, when SUBMITTER is absent, accept > > based on a MAIL FROM pass result. > > > > If course if SUBMITTER is provided that overrides the > > return-path, but i really would like to be able to avoid > > going into the headers upon FAIL. > > > > If the result is a PASS then going into the headers is fine > > by me; we would then check that the PRA either matches the > > MAIL FROM or passes an SPF check directly. > > > > (non-SUBMITTER compliant VERP mailing lists with Sender: > > owner-listname are a good case where PRA != MAIL-FROM but > > spf_check(PRA) == PASS == spf_check(MAIL-FROM)). > > > > perhaps some data can tell whether such an algorithm would > > be more or less prone to error in the field. > > > > > > > From owner-ietf-mxcomp@mail.imc.org Sun Aug 15 19:14: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 TAA26318 for ; Sun, 15 Aug 2004 19:14: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 i7FMtAZZ080903; Sun, 15 Aug 2004 15:55: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 i7FMtACq080902; Sun, 15 Aug 2004 15:55:10 -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 i7FMt9l1080891 for ; Sun, 15 Aug 2004 15:55:10 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id BD7C4E0585; Sun, 15 Aug 2004 18:55:12 -0400 (EDT) Date: Sun, 15 Aug 2004 18:55:12 -0400 From: John Leslie To: John Glube Cc: ietf-mxcomp@imc.org Subject: Re: What Meng said Message-ID: <20040815225512.GA50011@verdi> References: <69DF0558-EE3A-11D8-8640-000A95BC6A7E@margaretolson.com> <004901c482ea$dcf999c0$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004901c482ea$dcf999c0$6c62fea9@ibmrkydk2ufvdd> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Glube wrote: > > * Based on the newest drafts, is it correct to state that > Sender-ID will only read the spf/pra02 version string. Except for the spelling, which is "v=spf2.0/pra", yes. > * Prudent senders will therefore have to publish a v=spf1 > version string in the TXT record and spf/pra02 in the DNS > RR type SPF2. I have no opinion on whether spf1 check_host() will ever read something other than TXT records; but this is a likely scenario, yes. > * Will Submitter compliant Senders only use Sender, or will > you want to include SMTP Mail From in case the receiver > can't read Submitter and is only using SPF? These seem to me to be quite separate issues; but no doubt some will. > * Would the best practice be to have the domain in Sender > and SMTP mail from the same? I have no opinion. > * What about CSV? There, I _have_ an opinion. ;^) > Should prudent senders also be publishing the version > string for CSV? So far, I've been telling people to stay tuned: I'm not yet sure whether the format of CSV publishing in draft-ietf-marid-csv-csa-01.txt will be the final output of this Working Group. But once we agree on the final format, yes, operators of MTAs should IMHO be publishing CSV as well as Sender-ID. CSV will verify that the MTA is specifically authorized to act as a SMTP client, in such a manner that reputation services can closely track whether the domain publishing CSV record(s) has policies and practices which minimize email problems such as spam and viruses; and reputation reports can quickly reflect both problems and their resolutions. So, IMHO, anyone wishing to publish Sender-ID records _should_ also be publishing CSV (once we've agreed upon it, of course). > How will Submitter compliant senders relate to receivers > for example who are using CSV and SPF, but not Sender-ID > for licensing reasons? At first blush, I'd assume they'll simply continue publishing CSV and "v=spf1". (It's nearly certain there _will_ be such receivers.) > I raise these questions as: > > * The WG has apparently decided to go down the consecutive > as opposed to the concurrent path. This is clearly what the Chairs are asking us to do. > * This means each protocol will use its own version string, > as opposed to one version string serving all protocols. That seems hard to avoid... > * We are now confronted which inter-operability issues, so > making things even more complex. IMHO, inter-operability is probably easiest this way. > * These are questions which need to be answered. I really don't think the answers I've given are controversial. What is controversial is that we find ourselves complicating the task of publishing MARID-appropriate DNS records (which is quite contrary to the original aim of SPF). > In my view, while it is all very nice to say: > > * Sender-ID will only read sender-id records and CSV will > only read CSV records, > > We need to ensure a sender can transmit to someone who is > relying on any one or more of: > > SPF, ... > Sender-ID and CSV, ... > > Otherwise we will end up with a mess. The current path, with three different records being published, is fully workable; and IMHO is nothing to be ashamed of as Working Group output. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Sun Aug 15 22:19:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10800 for ; Sun, 15 Aug 2004 22: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 i7G202ai097612; Sun, 15 Aug 2004 19:00:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7G202q1097611; Sun, 15 Aug 2004 19:00:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G1xxw7097587 for ; Sun, 15 Aug 2004 18:59:59 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040816020004.SCJN18869.tomts5-srv.bellnexxia.net@ibmrkydk2ufvdd>; Sun, 15 Aug 2004 22:00:04 -0400 From: "John Glube" To: "'John Leslie'" Cc: Subject: RE: What Meng said Date: Sun, 15 Aug 2004 22:01:59 -0400 Message-ID: <005001c48335$048d2200$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20040815225512.GA50011@verdi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7G1xxw7097590 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit John, I appreciate your taking the time to confirm and in some cases clarify my understandings. One follow up question. You wrote: >What is controversial is that we find ourselves >complicating the task of publishing MARID-appropriate DNS >records (which is quite contrary to the original aim of >SPF). If we accept the position of separate DNS records for each protocol, can you elaborate on the controversy as you see it? I am not wanting to put you on the spot. So let me outline the situation as I see it and then perhaps you could provide corrections, comments and so forth. Here goes: Prior to the present draft of the Marid protocol, marid - appropriate DNS records were published using v=spf1 in the DNS IN TXT file. (My apologies if I have not stated this correctly.) A receiving MTA could either with or without Submitter: * Use these DNS records to run an SPF check, although not specified in the Marid core protocol; * If a negative result was returned, reject the message and send a rejection notice in accordance with the SPF protocol; This could be done at the DATA stage, so arguably saving bandwidth? * If a pass or neutral result was returned, proceed to 'swallow' the message and run a Marid core check. This gave the receiving MTA the benefit of SPF, along with PRA checks. Under the present draft of the Marid protocol, marid - appropriate DNS records should be published using v=spf2.0/pra in the DNS RR type SPF2 file, although the protocol does allow for TXT type records in the SPF2 file. However, by changing the version string, although the receiving MTA may decide to extract the domain in SMTP mail from and run a check against the SPF record in the DNS IN TXT file, if the domain has not published an SPF record, because it is not required: * Have we lost the potential optimization which was previously available? * Does the optimization suggested by Chris in his note to Margaret, based on his offline discussion with Mark fully replace this earlier optimization? http://www.imc.org/ietf-mxcomp/mail-archive/msg03299.html (There is a bad pun in there, but I'll skip it.) It seems it could, but only if the domain extracted from the SMTP mail from is the same as the purported responsible domain as identified in the marid appropriate DNS records? Is this the controversy you speak about, or is it something else? I apologize if my questions are putting anyone on the spot. I simply want to ensure the understandings are clear, so that receivers can optimize their results and prudent senders can accommodate this objective. I appreciate your taking time to respond. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Sun Aug 15 22:26: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 WAA14708 for ; Sun, 15 Aug 2004 22:26:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G22K0P098027; Sun, 15 Aug 2004 19:02: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 i7G22K7u098026; Sun, 15 Aug 2004 19:02:20 -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 i7G22KR6097895 for ; Sun, 15 Aug 2004 19:02:20 -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 861CF4083 for ; Sun, 15 Aug 2004 19:02:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040815225512.GA50011@verdi> References: <69DF0558-EE3A-11D8-8640-000A95BC6A7E@margaretolson.com> <004901c482ea$dcf999c0$6c62fea9@ibmrkydk2ufvdd> <20040815225512.GA50011@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4DE41C8E-EF28-11D8-A96D-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: What Meng said Date: Sun, 15 Aug 2004 19:02:19 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> * Based on the newest drafts, is it correct to state that >> Sender-ID will only read the spf/pra02 version string. > > Except for the spelling, which is "v=spf2.0/pra", yes. Actually, "spf2.0/pra" -- we dropped the "v=". - Mark From owner-ietf-mxcomp@mail.imc.org Sun Aug 15 23:48:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19483 for ; Sun, 15 Aug 2004 23:48:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G3ViN0007599; Sun, 15 Aug 2004 20:31:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7G3ViWR007598; Sun, 15 Aug 2004 20:31:44 -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 i7G3VhQq007587 for ; Sun, 15 Aug 2004 20:31:43 -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 8BBC3132D71; Sun, 15 Aug 2004 23:36:09 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 7311B580; Sun, 15 Aug 2004 23:31:46 -0400 (EDT) Date: Sun, 15 Aug 2004 23:31:46 -0400 From: Meng Weng Wong To: Mark Shewmaker Cc: MARID Subject: sender_agents Message-ID: <20040816033146.GK28401@dumbo.pobox.com> References: <1092141740.19690.855.camel@localhost.localdomain> <1092162895.25379.104.camel@ddev.mail-abuse.org> <1092204280.19686.954.camel@localhost.localdomain> <1092243820.5943.180.camel@ddev.mail-abuse.org> <1092310765.3295.1043.camel@localhost.localdomain> <1092330547.7445.101.camel@ddev.mail-abuse.org> <1092351580.19686.1199.camel@localhost.localdomain> <1092361125.7627.196.camel@ddev.mail-abuse.org> <1092368581.3295.1289.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1092368581.3295.1289.camel@localhost.localdomain> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 12, 2004 at 11:43:01PM -0400, Mark Shewmaker wrote: | > Something like Identified Internet Mail would help. I don't know what | > you mean by sender-agents. Do you mean a Certificate Authority? | | It's a modifier I've been pushing for a few months as a way to get | SenderID to fully address the phishing problem, to little avail | unfortunately. | | (I'm frustrated at my inability to stir up interest so far, as IMHO | sender_agents would make SenderID *FAR* more useful.) | | See: http://www.imc.org/ietf-mxcomp/mail-archive/msg03112.html I think sender_agents is a fine idea, but because it can be implemented as an optional extensionl, you might want to write up a draft that describes the modifier and see how people like it. From owner-ietf-mxcomp@mail.imc.org Sun Aug 15 23:49:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19519 for ; Sun, 15 Aug 2004 23:49:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G3brDQ008023; Sun, 15 Aug 2004 20: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 i7G3br7i008022; Sun, 15 Aug 2004 20:37: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 i7G3bqLh008016 for ; Sun, 15 Aug 2004 20:37: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 91C85132D71; Sun, 15 Aug 2004 23:42:21 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 8291960E; Sun, 15 Aug 2004 23:37:58 -0400 (EDT) Date: Sun, 15 Aug 2004 23:37:58 -0400 From: Meng Weng Wong To: Ryan Malayter Cc: MARID Subject: Reputation systems Message-ID: <20040816033758.GL28401@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 12, 2004 at 09:54:14AM -0500, Ryan Malayter wrote: | | Has anyone ever seen an effective "reputation system for reputation | systems"? I've seen a few statistical comparisons of DNSBLs, but they | all seem to ignore the most significant item when it comes to spam | filtering: the false-positive percentage. Of course, you have to have a | person manually evaluating whether or not each message *is* spam to get | this data, so perhaps that's why. I believe the generally accepted guide to DNSBLs and their ilk is at http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html | Such "reputation system grading" is probably something that is going to | be even more necessary as SPF/MARID grow in popularity. People will need | to know which reputation systems they can trust, right? I am working with a number of industry leaders on developing a rottentomatoes for domain-based reputation and accreditation system. My initial thoughts are documented at http:/spf.pobox.com/aspen.html. Things have moved fast since I wrote that document. Cloudmark has announced http://rating.cloudmark.com/senderid/ (a domain-name-based reputation service) and Verisign has announced its VDL (a first approximation to domain-name-based accreditation). In addition there is Gossip: http://www.sufficiently-advanced.net/ So it looks like it's going to happen. The ultimate communities-based "consensual subjectivity" spam scoring systems will probably end up with an Amazon-like "recipients like you thought this message was spam". The privacy implications are left as an exercise for the reader :) From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 04: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 EAA17646 for ; Mon, 16 Aug 2004 04: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 i7G7w20Y057699; Mon, 16 Aug 2004 00:58:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7G7w2GZ057698; Mon, 16 Aug 2004 00:58:02 -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 i7G7w1Fe057687 for ; Mon, 16 Aug 2004 00:58:02 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59318) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp (Exim 4.34) id 1BwcNT-00073b-PD (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Mon, 16 Aug 2004 08:57:59 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BwcNT-0006fY-O8 for ietf-mxcomp@imc.org; Mon, 16 Aug 2004 08:57:59 +0100 Date: Mon, 16 Aug 2004 08:57:59 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: Using Sender-ID as an inefficient CSV 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 observations about Sender-ID: (1) It screws up forwarding, which is very popular at sites like mine. (2) Although it appears to authenticate email addresses, it actually authenticates domains (since the local part is ignored). (3) Although it appears to authenticate domains, it actually authenticates MTAs (since anyone authorized to use an MTA can send email "from" any domain which uses that MTA). The easiest way to fix a site to avoid complaints from users resulting from Sender-ID rejections is to add before the usual Received: line at the start of the message Resent-Sender: mailer-daemon@outgoing.mail.relay Of course outgoing.mail.relay is exactly what CSV authenticates. 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 Mon Aug 16 06:57: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 GAA26252 for ; Mon, 16 Aug 2004 06:57:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GAT8Su091525; Mon, 16 Aug 2004 03:29:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GAT8Me091524; Mon, 16 Aug 2004 03:29:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost4.mail.uk.easynet.net (smarthost4.mail.uk.easynet.net [212.135.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GAT7T4091517 for ; Mon, 16 Aug 2004 03:29:07 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost4.mail.uk.easynet.net with smtp (Exim 4.10) id 1Bwejh-0002gm-00; Mon, 16 Aug 2004 11:29:05 +0100 Message-ID: <02c401c4837b$88cf7590$0200000a@ringo> From: "Chris Haynes" To: "Meng Weng Wong" Cc: "IETF MARID WG" References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> Subject: Re: What Meng said Date: Mon, 16 Aug 2004 11:26: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 Meng, Please may I ask a brutally simple question. I think it is generally agreed that where MAIL-FROM == PRA any decision is based on the PRA. My question below applies only to those messages in which the domain of the MAIL-FROM is different from the domain of the PRA. Where, in the collection of drafts issued on Friday, does Sender-ID refer to the rejection of a message as a result of evaluating the record associated with its MAIL-FROM domain? Chris Haynes At Friday, August 13, 2004 7:56 AM "Meng Weng Wong" said > > I agree with everything Mark says, so I must have > communicated my position poorly :) > > If I could have one more chance to explain my thinking, > let's cut to the chase: > > On Wed, Aug 11, 2004 at 02:38:38PM -0700, Mark Lentczner wrote: > | else client supplies just Mail From { > | r2 = check MAIL FROM against its Sender-ID record (hoping it will > | be same as PRA) > | > | accept body of message > | extract PRA from headers > | if PRA == MAIL FROM { exit with r2 } > | > | r3 = check PRA against its Sender-ID record > | exit with r3 > | } > > I agree that this is how Sender ID should work. > > My question is: can you reject if the r2 result is FAIL? > > I think you can. Here's why. > > The forwarding scenario is, of course, our weak link. > > Under SPF Classic, noncompliant forwarders who didn't do SRS > could expect to get their mail rejected. > > Under Sender ID, noncompliant forwarders who don't prepend a > Resent-From header could expect to get their mail rejected. > > Under Sender ID, noncompliant forwarders who don't offer a > SUBMITTER parameter could expect to get their mail rejected. > > In all cases, noncompliant forwarders get their mail > rejected. > > Therefore, immediately rejecting after MAIL if (the > SUBMITTER value is not provided and r2 is FAIL), is no worse > than continuing to accept the message and extracting the > PRA, because the PRA can be expected to fail anyway if it's > forwarding. > > This means that we *can* safely assume, > in the absence of SUBMITTER, that MAIL-FROM == PRA, > whether or not we think the sender is omitting it because > 1) they are not Sender-ID aware, or > 2) they are aware and Mail-From == PRA. > > If we do this, then the essential requirements of the SPF > Classic community are respected in Sender ID. > > I do not think this course of action harms the essential > requirements of Caller ID so why not make both sides happy? > > Back to the algorithm: > > | else client supplies just Mail From { > | r2 = check MAIL FROM against its Sender-ID record (hoping it will > | be same as PRA) > > so, if the r2 is FAIL, reject. if the r2 is PASS, proceed. > > | accept body of message > | extract PRA from headers > | if PRA == MAIL FROM { exit with r2 } > | > | r3 = check PRA against its Sender-ID record > | exit with r3 > | } > > the important requirement for me is being able to, when > SUBMITTER is absent, reject based on a MAIL FROM fail > result, and being able to, when SUBMITTER is absent, accept > based on a MAIL FROM pass result. > > If course if SUBMITTER is provided that overrides the > return-path, but i really would like to be able to avoid > going into the headers upon FAIL. > > If the result is a PASS then going into the headers is fine > by me; we would then check that the PRA either matches the > MAIL FROM or passes an SPF check directly. > > (non-SUBMITTER compliant VERP mailing lists with Sender: > owner-listname are a good case where PRA != MAIL-FROM but > spf_check(PRA) == PASS == spf_check(MAIL-FROM)). > > perhaps some data can tell whether such an algorithm would > be more or less prone to error in the field. > > > From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 13:21:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16312 for ; Mon, 16 Aug 2004 13:21: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 i7GGq6Cm074414; Mon, 16 Aug 2004 09:52:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GGq6X3074413; Mon, 16 Aug 2004 09:52:06 -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.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GGq5VI074406 for ; Mon, 16 Aug 2004 09:52:05 -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); Mon, 16 Aug 2004 09:52:07 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 16 Aug 2004 09:52:07 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Aug 2004 09:52:07 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 09:52:05 -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: What Meng said Date: Mon, 16 Aug 2004 09:52:06 -0700 Message-ID: Thread-Topic: What Meng said Thread-Index: AcSBk+1idAJQ911tSaSUHRE/feBHjwCHTLnQ From: "Harry Katz" To: "John Glube" , "Meng Weng Wong" , "Mark Lentczner" , "Andrew W. Donoho" , "Carl S. Gutekunst" Cc: "IETF MARID WG" X-OriginalArrivalTime: 16 Aug 2004 16:52:05.0407 (UTC) FILETIME=[5C4AC2F0:01C483B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7GGq5VI074407 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit My apologies for the confusion. You are correct that there are some hold-overs from Caller-ID on that wizard, including the use of an _ep subdomain. The text of the wizard does need to be updated. We'll get this corrected ASAP. > -----Original Message----- > From: John Glube [mailto:jbglube@sympatico.ca] > Sent: Friday, August 13, 2004 5:15 PM > To: Harry Katz; 'Meng Weng Wong'; 'Mark Lentczner'; 'Andrew > W. Donoho'; 'Carl S. Gutekunst' > Cc: 'IETF MARID WG' > Subject: RE: What Meng said > > Harry, > > If one goes to: > > http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.asp > x > > A wizard has been set up to assist folks in publishing what > is called an 'E-mail policy document' which can be used by > people who have implemented Sender-ID > > I found this link by going to: > > http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx > > (It is referenced under related links.) > > If you run through the wizard, at the last page, you will > find the following statement: > > Your E-Mail Policy Document must be published in DNS records > of type TXT in the subdomain "_ep" under your domain. Consult > the documentation of your DNS administration tools for > further details on publishing this. > > It is my understanding: > > * the marid protocol for SPF (to be renamed Sender-ID) does > not require publishing the 'E-Mail Policy Document' in the > subdomain "_ep." > > * this is a carry over from the Caller-ID protocol. > > * with the merger of SPF and Sender-ID this requirement was dropped > > With the media drive now underway to get the word out about > Sender-ID: > > * if people go to the SPF site they will receive one > instruction for publishing an Sender Policy Framework in DNS > records of type TXT; > > * if people go to the anti-spamtools.org site, people are > going to be lead to believe they have to publish their > 'E-Mail Policy Document' in DNS records of type TXT in the > subdomain "_ep." > > With the ongoing issue of a change in version string and > whether you have to publish one or two records, this raises concerns. > > I am not wanting to suggest any malice on anyone's part. > > I suspect what happened is that someone in setting up the > wizard simply read the wrong document. > > If you scroll down the page at: > > http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx > > you will note that the: > > >Sender ID Draft Specification: MTA Authentication Records in DNS" > > is the version dated June 23, 2004 which is now out of date. > > Can we get this rectified so that the wizard is based on the > most recent version of the protocol? > > Otherwise I suspect people are going to be publishing the > wrong records in the wrong place. > > John > > P.S. I also note the following additional statements on this page: > > http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx > > concerning the wizard. > > >Note: This tool is in beta, pending IETF approval. SPF > records created > >with this tool will require later revisions. > > >To check for the SPF record in incoming mail, your ISP or system > >administrator will need to update to Sender ID-compliant software to > >check for the Purported Responsible Address (PRA) of incoming mail. > > >If you are a software developer and are interested in > implementing the > >PRA check in your software, please review the terms of the Caller ID > >for E-Mail implementation license agreement before you begin. Please > >note that Microsoft does not require a license agreement for > >individuals, companies, or ISPs who wish only to publish > their Sender > >ID SPF text records. > > I simply reference this material in passing. > > 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.734 / Virus Database: 488 - Release Date: 04/08/2004 > > > From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 13:30: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 NAA16664 for ; Mon, 16 Aug 2004 13:30: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 i7GHBgDS075958; Mon, 16 Aug 2004 10:11: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 i7GHBgpD075957; Mon, 16 Aug 2004 10:11:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GHBfHX075944 for ; Mon, 16 Aug 2004 10:11:41 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reputation systems Date: Mon, 16 Aug 2004 12:11:37 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02B04BF6@cliff.bai.org> Thread-Topic: Reputation systems thread-index: AcSDQm0a/x4UcxcSTiq4yAnvmMVDrQAbelQg From: "Ryan Malayter" To: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7GHBfHX075951 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Meng Weng Wong] >I believe the generally accepted guide to DNSBLs and their >ilk is at >http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html I've seen that page, but as I mentioned, there's no analysis of the false-positive ratio. A very high false-postive rate, in my experience, is what makes IP-based blacklisting unworkable. Yes, a good blacklist stops a lot of spam, but it also stops a significant amount of ham. We got a lot of false positives with the SpamCop list, and other BLs are bound to be worse. I guess I'll have to try to do this analysis on my own. Someone wrote a SpamBayes tokeinzer module that adds tokens for blacklist membership; this will automate the process for me if I get it working. Regards, -- Ryan Malayter Bank Administration Institute Chicago, Illinois, USA ========================= All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 13:47: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 NAA17554 for ; Mon, 16 Aug 2004 13:47: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 i7GHSfHW077168; Mon, 16 Aug 2004 10:28: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 i7GHSf62077167; Mon, 16 Aug 2004 10:28:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7GHSdpc077159 for ; Mon, 16 Aug 2004 10:28:40 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 8CA981A6B9; Mon, 16 Aug 2004 19:28:42 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 7BF271A6BF for ; Mon, 16 Aug 2004 19:28:40 +0200 (CEST) Message-Id: Date: Mon, 16 Aug 2004 19:28:57 +0200 From: Arnt Gulbrandsen To: Ryan Malayter Subject: Re: Reputation systems Cc: MARID References: <792DE28E91F6EA42B4663AE761C41C2A02B04BF6@cliff.bai.org> In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02B04BF6@cliff.bai.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ryan Malayter writes: > We got a lot of false positives with the SpamCop list, (That echoes my experience while I used the SC list.) > and other BLs are bound to be worse. Why? Arnt From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 14:04:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18717 for ; Mon, 16 Aug 2004 14:04:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GHRBP6077072; Mon, 16 Aug 2004 10:27:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GHRBlu077071; Mon, 16 Aug 2004 10:27:11 -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 i7GHRAES077065 for ; Mon, 16 Aug 2004 10:27:10 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58845) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp (Exim 4.34) id 1BwlGH-00030R-6C (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Mon, 16 Aug 2004 18:27:09 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BwlGG-0004UL-W2 for ietf-mxcomp@imc.org; Mon, 16 Aug 2004 18:27:09 +0100 Date: Mon, 16 Aug 2004 18:27:08 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: MARID Subject: RE: Reputation systems In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02B04BF6@cliff.bai.org> Message-ID: References: <792DE28E91F6EA42B4663AE761C41C2A02B04BF6@cliff.bai.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 16 Aug 2004, Ryan Malayter wrote: > > I've seen that page, but as I mentioned, there's no analysis of the > false-positive ratio. A very high false-postive rate, in my experience, > is what makes IP-based blacklisting unworkable. Yes, a good blacklist > stops a lot of spam, but it also stops a significant amount of ham. > We got a lot of false positives with the SpamCop list, and other BLs are > bound to be worse. The SpamCop list is one of the worst for false positives. We get very few complaints from using the MAPS RBL+ and the Spamhaus SBL-XBL, and they are both quite effective (accounting for about half of our SMTP-time rejections). The following graph is fairly interesting: http://canvas.csi.cam.ac.uk/stats/ppsw/img/dnsbl.15.gif The y axis is in messages per second. A week ago I swapped the order of the blacklists in my configuration so that the RBL+ is checked first. 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 Mon Aug 16 15:25: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 PAA25175 for ; Mon, 16 Aug 2004 15:25: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 i7GJ0HWv085720; Mon, 16 Aug 2004 12:00: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 i7GJ0HAp085719; Mon, 16 Aug 2004 12:00:17 -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 i7GJ0FAb085704 for ; Mon, 16 Aug 2004 12:00:16 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 78559E0611; Mon, 16 Aug 2004 15:00:19 -0400 (EDT) Date: Mon, 16 Aug 2004 15:00:19 -0400 From: John Leslie To: John Glube Cc: "'John Leslie'" , ietf-mxcomp@imc.org Subject: Re: What Meng said Message-ID: <20040816190019.GC50011@verdi> References: <20040815225512.GA50011@verdi> <005001c48335$048d2200$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005001c48335$048d2200$6c62fea9@ibmrkydk2ufvdd> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Glube wrote: > "'John Leslie'" [wrrte:] > >> What is controversial is that we find ourselves >> complicating the task of publishing MARID-appropriate DNS >> records (which is quite contrary to the original aim of >> SPF). > > If we accept the position of separate DNS records for each > protocol, can you elaborate on the controversy as you see > it? The controversy is pretty quiet actually; but the pain level is obvious. Any number of people would like to avoid the MARID WG recommending publication of multiple records. > Prior to the present draft of the Marid protocol, marid - > appropriate DNS records were published using v=spf1 in the > DNS IN TXT file. > > A receiving MTA could either with or without Submitter: > > * Use these DNS records to run an SPF check, although not > specified in the Marid core protocol; > > * If a negative result was returned, reject the message and > send a rejection notice in accordance with the SPF protocol; > > This could be done at the DATA stage, so arguably saving > bandwidth? I'd rather not get into that argument. Regardless of bandwidth savings, an error returned during the SMTP connection is "better" because it's more likely to reach a responsible party. > * If a pass or neutral result was returned, proceed to > 'swallow' the message and run a Marid core check. > > This gave the receiving MTA the benefit of SPF, along with > PRA checks. > > Under the present draft of the Marid protocol, marid - > appropriate DNS records should be published using > v=spf2.0/pra in the DNS RR type SPF2 file, although the ^^^^^^^^^^^^ Mark already corrected me on that: there is in fact no "v=". > protocol does allow for TXT type records in the SPF2 file. Yes, it should be understood that SPF2 is a "text" type, and most domains will publish TXT RRs as well as SPF2. > However, by changing the version string, although the > receiving MTA may decide to extract the domain in SMTP mail > from and run a check against the SPF record in the DNS IN > TXT file, if the domain has not published an SPF record, > because it is not required: > > * Have we lost the potential optimization which was > previously available? I'm not clear what "optimization" you mean, but we've probably lost it. > * Does the optimization suggested by Chris in his note to > Margaret, based on his offline discussion with Mark fully > replace this earlier optimization? I'm not sure I understand what you refer to here. The obvious sentence is: ] ] The optimization derived from using MAIL-FROM is the opportunity to ] fetch and start testing the record, in the hope that, when the PRA ] is eventually determined, the correct record is found to have been ] used. This seems to imply that sender-ID checks could be run against the MAIL-FROM when there is no submitter _before_ accepting the DATA. I don't believe this is recommended in any of the current MARID I-Ds (though it isn't actually prohibited). The potential for saving any appreciable bandwidth escapes me, unless we're talking about serious tar-pitting, which IMHO is quite out of scope for MARID discussions. Somebody may have an opinion on whether this replaces the earlier optimization, but I certainly don't. > It seems it could, but only if the domain extracted from > the SMTP mail from is the same as the purported responsible > domain as identified in the marid appropriate DNS records? It's more restrictive than that actually. Only if the PRA turns out to be exactly the same as the MAIL-FROM are you on safe ground. (There is some hand-waving about cacheing SPF2 results if no macros are involved...) > Is this the controversy you speak about, or is it something > else? No, this is not what I spoke of. The visible part of the iceberg of controversy is the numerous occasions where the CSV folks have been asked why the SPF record isn't "good enough" to serve the function of the CSV SRV record. Also, there has been _extensive_ discussion of whether we actually need to change the version string when moving from SPF to caller-ID. That's the controversy I refer to. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 15:39: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 PAA26405 for ; Mon, 16 Aug 2004 15:39: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 i7GJJDod087197; Mon, 16 Aug 2004 12:19: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 i7GJJDZe087196; Mon, 16 Aug 2004 12:19:13 -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 i7GJJCGd087190 for ; Mon, 16 Aug 2004 12:19:13 -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 PAA24671; Mon, 16 Aug 2004 15:19:14 -0400 (EDT) Message-Id: <200408161919.PAA24671@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-03.txt Date: Mon, 16 Aug 2004 15:19:13 -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-03.txt Pages : 14 Date : 2004-8-16 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-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-submitter-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-submitter-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-16153646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-submitter-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-submitter-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-16153646.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 15:39: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 PAA26421 for ; Mon, 16 Aug 2004 15:39: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 i7GJJIBP087209; Mon, 16 Aug 2004 12:19: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 i7GJJHud087208; Mon, 16 Aug 2004 12:19:17 -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 i7GJJGDq087201 for ; Mon, 16 Aug 2004 12:19:17 -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 PAA24682; Mon, 16 Aug 2004 15:19:18 -0400 (EDT) Message-Id: <200408161919.PAA24682@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-01.txt Date: Mon, 16 Aug 2004 15:19:18 -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 Sender-ID Record: Format and Interpretation Author(s) : M. Wong, M. Lentczner Filename : draft-ietf-marid-protocol-01.txt Pages : 41 Date : 2004-8-16 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-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-protocol-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-protocol-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-8-16153653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-16153653.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 16:41:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07463 for ; Mon, 16 Aug 2004 16:41: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 i7GKAr9Z090605; Mon, 16 Aug 2004 13:10: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 i7GKArhX090604; Mon, 16 Aug 2004 13:10:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GKArae090594 for ; Mon, 16 Aug 2004 13:10:53 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1Bwnoi-000A3e-00 for ietf-mxcomp@imc.org; Mon, 16 Aug 2004 21:10:52 +0100 Message-ID: <00c001c483cc$d0aef330$0200000a@ringo> From: "Chris Haynes" To: References: <20040815225512.GA50011@verdi> <005001c48335$048d2200$6c62fea9@ibmrkydk2ufvdd> <20040816190019.GC50011@verdi> Subject: Re: What Meng said Date: Mon, 16 Aug 2004 21:08:34 +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 "John Leslie" commented: > > John Glube wrote: > > "'John Leslie'" [wrrte:] > > > > > > * Have we lost the potential optimization which was > > previously available? > > I'm not clear what "optimization" you mean, but we've probably > lost it. > > > * Does the optimization suggested by Chris in his note to > > Margaret, based on his offline discussion with Mark fully > > replace this earlier optimization? > > I'm not sure I understand what you refer to here. The obvious > sentence is: > ] > ] The optimization derived from using MAIL-FROM is the opportunity to > ] fetch and start testing the record, in the hope that, when the PRA > ] is eventually determined, the correct record is found to have been > ] used. The wording above is my understanding / interpretation of the optimisation described by Mark Lentczner in his pseudo-code in http://www.imc.org/ietf-mxcomp/mail-archive/msg03230.html and which is applicable when no SUBMITTER has been used. Inspect carefully his use of test 'r2' and note that this test result cannot be acted upon until after the PRA is available and the initial 'guess' has been proved correct. > > This seems to imply that sender-ID checks could be run against > the MAIL-FROM when there is no submitter _before_ accepting the DATA. > I don't believe this is recommended in any of the current MARID I-Ds > (though it isn't actually prohibited). > > The potential for saving any appreciable bandwidth escapes me, > unless we're talking about serious tar-pitting, which IMHO is quite > out of scope for MARID discussions. All I believe it can save is time - the record can be being fetched from DNS and evaluated in parallel with the SMTP DATA phase. If it turns out that MAIL-FROM != PRA, bandwidth (and DNS service resource) will have been wasted, as the first test result will be discarded. > > Somebody may have an opinion on whether this replaces the earlier > optimization, but I certainly don't. As I understand it, the central reason for introducing SUBMITTER was to give Sender-ID the opportunity of matching the SPF optimisation of being able to reject some messages before the SMTP DATA phase - saving bandwidth. I presume this is what you refer to as the 'earlier optimisation'. If no SUBMITTER is used, I believe Sender-ID must always proceed to the DATA phase, as this is when the information defining the PRA is supplied. HTH Chris Haynes From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 17:12: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 RAA10131 for ; Mon, 16 Aug 2004 17:12: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 i7GKqJSC094740; Mon, 16 Aug 2004 13:52:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GKqJH9094737; Mon, 16 Aug 2004 13:52:19 -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 i7GKqIuA094723 for ; Mon, 16 Aug 2004 13:52:18 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040816205215.KRLP4758.tomts13-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 16 Aug 2004 16:52:15 -0400 From: "John Glube" To: "'John Leslie'" Cc: Subject: RE: What Meng said Date: Mon, 16 Aug 2004 16:54:07 -0400 Message-ID: <007d01c483d3$2cecc8b0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20040816190019.GC50011@verdi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7GKqIuA094731 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit From: John Leslie Sent: August 16, 2004 3:00 PM John Leslie wrote in part: >The visible part of the iceberg of controversy is the >numerous occasions where the CSV folks have been asked why >the SPF record isn't "good enough" to serve the function of >the CSV SRV record. Also, there has been _extensive_ >discussion of whether we actually need to change the version >string when moving from SPF to caller-ID. [Sender-ID] That's >the controversy I refer to. My square brackets added. What? You mean the CSV folks were accused of being a bunch of slaveens by the SPF folks for not sharing. Those uppity come from aways. Flat on the back with that:-) (I lived in Newfoundland for 18 years, affectionately known as the Rock. Canada's distinct 'English' province, being a former Dominion before 1949. Newfoundland English or Newfinese is the native tongue.) Appreciate the clarification. I am familiar with the Sender-ID change of version string controversy. I can go through the archives to review the CSV/SPF discussions. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 17:12: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 RAA10180 for ; Mon, 16 Aug 2004 17:12:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GKqJ7r094741; Mon, 16 Aug 2004 13:52:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GKqJqL094738; Mon, 16 Aug 2004 13:52:19 -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 i7GKqIEE094721 for ; Mon, 16 Aug 2004 13:52: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 2B11240D9 for ; Mon, 16 Aug 2004 13:52:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <013801c482f6$bf421040$0200000a@ringo> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <69DF0558-EE3A-11D8-8640-000A95BC6A7E@margaretolson.com> <013801c482f6$bf421040$0200000a@ringo> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2A7D7C99-EFC6-11D8-A96D-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: What Meng said Date: Mon, 16 Aug 2004 13:52:20 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 15, 2004, at 11:36 AM, Chris Haynes wrote: > If the domain of MAIL-FROM is different from that of the PRA, its > record has no > functional impact whatsoever on the evaluation of the message - which > is, I > trust, a fair re-phrasing of Mark's observation. Just to be technically precise: In general the test must be that MAIL-FROM must equal PRA, not just the domains. If, when checking the MAIL-FROM address, it is determined that the Sender-ID records for the domain of MAIL-FROM don't rely on the local-part, then merely the domains of MAIL-FROM and PRA can be compared. - Mark From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 18:42: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 SAA18630 for ; Mon, 16 Aug 2004 18:42: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 i7GMGYv4000646; Mon, 16 Aug 2004 15:16:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GMGYxd000645; Mon, 16 Aug 2004 15:16:34 -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 i7GMGWpU000636 for ; Mon, 16 Aug 2004 15:16:33 -0700 (PDT) (envelope-from sb0-06466f7331-johnl@iecc.com) Received: (qmail 28626 invoked by uid 100); 16 Aug 2004 22:16:37 -0000 Date: 16 Aug 2004 22:16:37 -0000 Message-ID: <20040816221637.28625.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: Reputation systems In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02B04BF6@cliff.bai.org> Organization: I.E.C.C., Trumansburg NY USA Cc: rmalayter@bai.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >We got a lot of false positives with the SpamCop list, and other BLs >are bound to be worse. Actually, Spamcop's list is infamous for its vast number of false positives. That's why nobody I know uses it for anything more than a fairly low-weight input into a scoring system. Try the Spamhaus SBL and XBL and you'll find very few misfires. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 19:42:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22271 for ; Mon, 16 Aug 2004 19:42: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 i7GNI416004955; Mon, 16 Aug 2004 16:18: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 i7GNI49I004954; Mon, 16 Aug 2004 16:18:04 -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 i7GNI4XX004943 for ; Mon, 16 Aug 2004 16:18:04 -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 i7GNI41m011009; Mon, 16 Aug 2004 16:18:05 -0700 In-Reply-To: <23FC8EBA-E678-11D8-8A0D-000A95CA7FAE@dbc.mtview.ca.us> References: <23FC8EBA-E678-11D8-8A0D-000A95CA7FAE@dbc.mtview.ca.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/mixed; boundary=Apple-Mail-5-574445878 Message-Id: <83445DEC-EFDA-11D8-AC49-000A95CA7FAE@dbc.mtview.ca.us> Cc: Andrew Newton , IETF MARID WG From: Marshall Rose Subject: Re: short-term milestones Date: Mon, 16 Aug 2004 16:17:59 -0700 To: Marshall Rose X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-5-574445878 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > however, we would like to draw everyone's attention to the following > actions and milestones: > > 1. the -core document will be split into two documents, one talking > about PRA, the other with everything else. completed. > 2. revised drafts (-core, -pra, -protocol, -submitter) will be > submitted to internet-drafts by friday, august 13th. > > people having suggestions, nits, new security consideration items, > etc., are urged to get them directly to the authors well before then > (like between now and this friday). protocol - http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-01.txt submitter - http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-03.txt core and pra were submitted to the internet-drafts repository, but due to a formatting error were not accepted. they should appear tomorrow. in the interim, i attach them herewith. /mtr --Apple-Mail-5-574445878 Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-marid-core-03.txt" Content-Disposition: attachment; filename=draft-ietf-marid-core-03.txt Content-Transfer-Encoding: quoted-printable =0D =0D =0D =0D MARID Working Group J. Lyon=0D= Internet Draft Microsoft Corp=0D= Document: draft-ietf-marid-core-03.txt M. Wong=0D= pobox.com=0D= Expires: February 2005 August 2004=0D= =0D =0D Sender ID: Authenticating E-Mail=0D =0D =0D Status of this Memo=0D =0D By submitting this Internet-Draft, I certify that any applicable=0D patent or other IPR claims of which I am aware have been disclosed,=0D= or will be disclosed, and any of which I become aware will be=0D disclosed, in accordance with RFC 3668.=0D =0D Internet-Drafts are working documents of the Internet Engineering=0D Task Force (IETF), its areas, and its working groups. Note that=0D other groups may also distribute working documents as Internet-=0D Drafts.=0D =0D Internet-Drafts are draft documents valid for a maximum of six months=0D= and may be updated, replaced, or obsoleted by other documents at any=0D= time. It is inappropriate to use Internet-Drafts as reference=0D material or to cite them other than a "work in progress."=0D =0D The list of current Internet-Drafts can be accessed at=0D http://www.ietf.org/1id-abstracts.html=0D =0D The list of Internet-Draft Shadow Directories can be accessed at=0D http://www.ietf.org/shadow.html=0D =0D Abstract=0D =0D Internet mail suffers from the fact that much unwanted mail is sent=0D= using spoofed addresses -- "spoofed" in this case means the address=0D= is used without the permission of the domain owner. This document=0D describes the following: mechanisms by which a domain owner can=0D publish its set of outgoing MTAs, mechanisms by which SMTP servers=0D can determine what email address is allegedly responsible for most=0D proximately introducing a message into the Internet mail system, and=0D= whether that introduction is authorized by the owner of the domain=0D contained in that email address.=0D =0D The specification is carefully tailored to ensure that the=0D overwhelming majority of legitimate emailers, remailers and mailing=0D= list operators are already compliant.=0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 1]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D Table of Contents=0D =0D 1. Introduction...................................................3=0D= 2. Problem Statement..............................................3=0D= 2.1 Positive Problem Statement.................................3=0D= 2.2 Negative Problem Statement.................................4=0D= 3. Decision Model.................................................4=0D= 4. Determining the Purported Responsible Address..................5=0D= 5. Actions Based on the Decision..................................5=0D= 5.1 Neutral or None or PermError...............................6=0D= 5.2 Pass.......................................................6=0D= 5.3 Fail.......................................................6=0D= 5.4 SoftFail...................................................6=0D= 5.5 TempError..................................................6=0D= 6. Security Considerations........................................6=0D= 6.1 DNS Attacks................................................7=0D= 6.2 TCP Attacks................................................7=0D= 6.3 Forged Sender Attacks......................................7=0D= 6.4 Address Space Hijacking....................................7=0D= 7. Implementation Guidance........................................8=0D= 7.1 Simple E-mailers...........................................8=0D= 7.2 E-Mail Forwarders..........................................8=0D= 7.3 Mailing List Servers.......................................8=0D= 7.4 Third-Party Mailers........................................9=0D= 7.5 MUA Implementers...........................................9=0D= 8. IANA Considerations............................................9=0D= 9. Acknowledgements...............................................9=0D= 10. References...................................................10=0D= 10.1 Normative References.....................................10=0D= 10.2 Informative References...................................10=0D= 11. Authors' Addresses...........................................11=0D= =0D Conventions used in this document=0D =0D The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0D= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0D= document are to be interpreted as described in [RFC2119].=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 2]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D 1. Introduction=0D =0D Today, a huge majority of unwanted email contains headers that lie=0D about the origin of the mail. This is true of most spam and=0D substantially all of the virus email that is sent.=0D =0D This document describes a mechanism such that receiving MTAs, MDAs=0D and/or MUAs can recognize mail in the above category and take=0D appropriate action. For example, an MTA might refuse to accept a=0D message, an MDA might discard a message rather than placing it into a=0D= mailbox, and an MUA might render that message in some distinctive=0D fashion.=0D =0D In order to avoid further fragmentation of the Internet email system,=0D= it is necessary that the Internet community as a whole come to a=0D consensus as to what mail senders should do to make their mail appear=0D= non-spoofed, and how mail receivers should determine whether mail is=0D= spoofed. On the other hand, it is not necessary to reach a consensus=0D= regarding the actions that various parties take once a message has=0D been determined to be spoofed. This can be done unilaterally -- one=0D= agent might decide to discard a spoofed message while another decides=0D= to add a disclaimer.=0D =0D =0D 2. Problem Statement=0D =0D 2.1 Positive Problem Statement=0D =0D Briefly stated, the mechanisms of this document allow one to answer=0D= the following question:=0D =0D When a message is transferred via SMTP between two UNRELATED parties,=0D= does the SMTP client host have permission to send mail on behalf of=0D= the mailbox that allegedly caused the most recent introduction of the=0D= message into the mail delivery system?=0D =0D As seen from the question, this mechanism applies to unrelated=0D parties: it is useful at the point where a message passes across the=0D= Internet from one organization to another. It is beyond the scope of=0D= this document to describe authentication mechanisms that can be=0D deployed within an organization.=0D =0D The mechanism of this document also seeks to authenticate the mailbox=0D= associated with the MOST RECENT introduction of a message into the=0D mail delivery system. In simple cases, this is who the mail is from.=0D= However, in the case of a third-party mailer, a forwarder or a=0D mailing list server, the address being authenticated is that of the=0D= third party, the forwarder or the mailing list.=0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 3]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D This document provides means to authenticate the DOMAIN of the=0D appropriate email address; it is not directed at the local-part. A=0D= domain owner gets to determine which SMTP clients speak on behalf of=0D= addresses within the domain; a responsible domain owner should not=0D authorize SMTP clients that will lie about local parts.=0D =0D In the long run, once the domain of the sender is authenticated, it=0D= will be possible to use that domain as part of a mechanism to=0D determine the likelihood that a given message is spam, using, for=0D example, reputation and accreditation services. (These services are=0D= not the subject of the present mechanism, but it should enable them.)=0D= =0D =0D 2.2 Negative Problem Statement=0D =0D Following are several alternate questions, which this specification=0D= makes no attempt to answer:=0D =0D 1. Is the host at a particular IP address authorized to act as an=0D SMTP client?=0D =0D 2. Is an SMTP client authorized to use a particular domain name in=0D its SMTP EHLO command?=0D =0D 3. Is an SMTP client authorized to use a particular email address in=0D= an SMTP "MAIL FROM:" command?=0D =0D 4. Was a message really authored by who it claims to be authored by?=0D= =0D =0D 3. Decision Model=0D =0D The essence of this specification is:=0D =0D Given an email message, and given an IP address from which it has=0D been (or will be) received, is the SMTP client at that IP address=0D authorized to send that email message?=0D =0D This question will usually be asked by an SMTP server as part of=0D deciding whether to accept an incoming mail message. However, this=0D= question could also be asked later by a different party. An MUA, for=0D= example, could use the result of this question to determine how to=0D file or present a message.=0D =0D =0D =0D =0D =0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 4]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D There are four steps to answering this question:=0D =0D (1) =46rom the headers of the email message, extract the "purported=0D= responsible address". This is the mailbox that the message=0D claims is responsible for the most recent introduction of the=0D message into the delivery system. This step is described in=0D detail in section 4 below. A separate specification,=0D [Submitter], describes an SMTP extension that allows an SMTP=0D server to perform this check at the time of the SMTP MAIL=0D command instead of the SMTP DATA command.=0D =0D (2) Extract the domain part of the purported responsible address.=0D Call this the "purported responsible domain".=0D =0D (3) Call the check_host function defined in [Protocol], passing the=0D= following parameters:=0D a. The IP address (either IPv4 or IPv6) from which the message=0D= is being or has been received.=0D b. The purported responsible domain from step (2) above.=0D c. The purported responsible address from step (1) above.=0D =0D The result of the check_host function is one of the values "Neutral",=0D= "Pass", "Fail", "SoftFail", "None", "TempError" or "PermError".=0D Section 5 describes how these results are used by MTAs receiving=0D messages. This specification imposes no requirements on parties=0D performing this test in other environments.=0D =0D =0D 4. Determining the Purported Responsible Address=0D =0D The purported responsible address (PRA) of a message MUST be=0D determined using the algorithm described in [PRA].=0D =0D If the Sender ID check is being performed by an MTA as part of=0D receiving an e-mail message, and the PRA algorithm cannot determine a=0D= PRA, then the message SHOULD be rejected with error "550 5.1.7=0D Missing purported Responsible Address".=0D =0D =0D 5. Actions Based on the Decision=0D =0D When the Sender ID test is used by an SMTP server as part of=0D receiving a message, the server should take the actions described by=0D= this section.=0D =0D The check_host function returns one of the following results. See=0D [Protocol] for the meaning of these results.=0D =0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 5]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D 5.1 Neutral or None or PermError=0D =0D An SMTP server receiving one of these results SHOULD NOT reject the=0D= message for this reason alone, but MAY subject the message to=0D heightened scrutiny by other anti-spam measures, and MAY reject the=0D= message as a result of this heightened scrutiny.=0D =0D 5.2 Pass=0D =0D An SMTP server receiving this result SHOULD treat the message as=0D authentic. It may accept or reject the message depending on other=0D policies.=0D =0D 5.3 Fail=0D =0D An SMTP server receiving this result SHOULD reject the message with a=0D= "550 5.7.1 Sender ID xxx - yyy" SMTP error, where "xxx" is replaced=0D= with the additional reason returned by the check_host function and=0D "yyy" is replaced with the explanation string returned by the=0D check_host function.=0D =0D 5.4 SoftFail=0D =0D An SMTP server receiving this result SHOULD NOT reject the message=0D for this reason alone, but MAY subject the message to heightened=0D scrutiny by other anti-spam measures, and MAY reject the message as a=0D= result of this heightened scrutiny. A message for which the result=0D= is "SoftFail" is less likely to be authentic than a message for which=0D= the result is "Neutral".=0D =0D 5.5 TempError=0D =0D An SMTP server receiving this result MAY reject the message with a=0D "450 4.4.3 Sender ID check is temporarily unavailable" error code.=0D Alternatively, an SMTP server receiving this result MAY accept a=0D message and optionally subject it to heightened scrutiny by other=0D anti-spam measures.=0D =0D =0D 6. Security Considerations=0D =0D This entire document describes a new mechanism for mitigating spoofed=0D= email, which is today a pervasive security problem in the Internet.=0D= =0D Assuming that this mechanism is widely deployed, the following=0D sections describe counter-attacks that could be used to defeat this=0D= mechanism.=0D =0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 6]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D 6.1 DNS Attacks=0D =0D The new mechanism is entirely dependent on DNS lookups, and is=0D therefore only as secure as DNS. An attacker bent on spoofing=0D messages could attempt to get his messages accepted by sending forged=0D= answers to DNS queries.=0D =0D An MTA could largely defeat such an attack by using a properly=0D paranoid DNS resolver. DNSSEC may ultimately provide a way to=0D completely neutralize this class of attacks.=0D =0D =0D 6.2 TCP Attacks=0D =0D This mechanism is designed to be used in conjunction with SMTP over=0D= TCP. A sufficiently resourceful attacker might be able to send TCP=0D= packets with forged from-addresses, and thus execute an entire SMTP=0D= session that appears to come from somewhere other than its true=0D origin.=0D =0D Such an attack requires guessing what TCP sequence numbers an SMTP=0D server will use. It also requires transmitting completely in the=0D blind - the attack will be unable hear any of the server's side of=0D the conversation.=0D =0D Attacks of this sort can be ameliorated if IP gateways refuse to=0D forward packets when the source address is clearly bogus.=0D =0D =0D 6.3 Forged Sender Attacks=0D =0D This mechanism chooses a purported responsible address from one of a=0D= number of message headers, and then uses that address for validation.=0D= A message with a true Resent-=46rom header (for example), but a = forged=0D =46rom header will be accepted. Since many MUAs do not display all = of=0D the headers of received messages, the message will appear to be=0D forged when displayed.=0D =0D In order to neutralize this attack, MUAs will need to start=0D displaying at least the header that was verified.=0D =0D =0D 6.4 Address Space Hijacking=0D =0D This mechanism assumes the integrity of IP address space for=0D determining whether a given client is authorized to send messages=0D from a given PRA. In addition to the TCP attack given in section=0D 6.2, a sufficiently resourceful attacker might be able to alter the=0D= IP routing structure to permit two-way communication using a=0D =0D =0D Lyon, Wong Expires - February 2005 [Page 7]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D specified IP address. It would then be possible to execute an SMTP=0D= session that appears to come from an authorized address, without the=0D= need to guess TCP sequence numbers or transmit in the blind.=0D =0D Such an attack might occur if the attacker obtained access to a=0D router which participates in external BGP routing. Such a router=0D could advertise a more specific route to a rogue SMTP client,=0D temporarily overriding the legitimate owner of the address.=0D =0D =0D 7. Implementation Guidance=0D =0D This section describes the actions that certain members of the=0D Internet email ecosystem must take to be compliant with this=0D specification.=0D =0D =0D 7.1 Simple E-mailers=0D =0D A domain that injects original email into the Internet, using its own=0D= name in =46rom headers, need do nothing to be compliant. However, = such=0D domains SHOULD publish e-mail policy records in DNS.=0D =0D =0D 7.2 E-Mail Forwarders=0D =0D A program that forwards received mail to other addresses MUST add an=0D= appropriate header that contains an email address that it is=0D authorized to use. Such programs SHOULD use the Resent-=46rom header=0D= for this purpose.=0D =0D Additionally, e-mail forwarders SHOULD publish Sender ID records for=0D= their domains, and SHOULD use MTAs for which the Sender ID check=0D yields a "pass" result.=0D =0D Some of today's forwarders already add an appropriate header=0D (although many of them use Sender rather than Resent-From.)=0D =0D =0D 7.3 Mailing List Servers=0D =0D A mailing list server MUST add an appropriate header that contains an=0D= email address that it is authorized to use. Such programs SHOULD use=0D= the Resent-=46rom header for this purpose.=0D =0D Additionally, mailing list servers SHOULD publish Sender ID records=0D= for their domains, and SHOULD use MTAs for which the Sender ID check=0D= yields a "pass" result.=0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 8]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D Most of today's mailing list software already adds an appropriate=0D header (although most of them use Sender rather than Resent-From).=0D =0D =0D 7.4 Third-Party Mailers=0D =0D A program that sends mail on behalf of another user MUST add an=0D appropriate header that contains an email address that it is=0D authorized to use. Such programs SHOULD use the Sender header for=0D this purpose.=0D =0D Additionally, third-part mailers servers SHOULD publish Sender ID=0D records for their domains, and SHOULD use MTAs for which the Sender=0D= ID check yields a "pass" result.=0D =0D Many, but not all, of today's third-party mailers are already=0D compliant.=0D =0D =0D 7.5 MUA Implementers=0D =0D When displaying a received message, an MUA SHOULD display the=0D purported responsible address as defined by this document whenever=0D that address differs from the RFC 2822 =46rom address. This display=0D= SHOULD be in addition to the RFC 2822 =46rom address.=0D =0D When a received message contains multiple headers that might be used=0D= for the purported responsible address determination, an MUA should=0D consider displaying all of them. That is, if a message contains=0D several Resent-From's, a Sender and a From, an MUA should consider=0D displaying all of them.=0D =0D =0D 8. IANA Considerations=0D =0D This document contains no actions for IANA.=0D =0D =0D 9. Acknowledgements=0D =0D Variations on the idea of using a DNS record to check the legitimacy=0D= of an email address have occurred multiple times. The earliest known=0D= work is [Vixie]; others include [RMX], [SPF] and [CallerID].=0D =0D The current document borrows heavily from each of the above, and=0D incorporates ideas proposed by many members of the MARID working=0D group. The contributions of each of the above are gratefully=0D acknowledged.=0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 9]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D =0D 10. References=0D =0D 10.1 Normative References=0D =0D [PRA] J. Lyon, "Purported Responsible Address in E-Mail=0D Messages", draft-ietf-marid-pra-00. Work in progress.=0D =0D [Protocol] M. Wong and M. Lentczner, "The SPF Record Format and Test=0D= Protocol", draft-ietf-marid-protocol-01. Work in=0D progress.=0D =0D [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate=0D Requirement Levels", RFC 2119.=0D =0D =0D 10.2 Informative References=0D =0D [CallerID] Microsoft Corporation, Caller ID for E-Mail Technical=0D Specification,=0D http://www.microsoft.com/mscorp/twc/privacy/spam_callerid=0D= .mspx.=0D =0D [RMX] H. Danisch, "The RMX DNS RR and method for lightweight=0D SMTP sender authorization", draft-danisch-dns-rr-smtp-04.=0D= Work in progress.=0D =0D [SPF] M. Lentczner and M. Wong, "Sender Policy Framework (SPF):=0D= A Convention to Describe Hosts Authorized to Send SMTP=0D Traffic", draft-mengwong-spf-01. Work in progress.=0D =0D [Submitter] E. Allman and H. Katz, "SMTP Service Extension for=0D Indicating the Responsible Submitter of an E-mail=0D Message", draft-ietf-marid-submitter-03. Work in=0D progress.=0D =0D [Vixie] Paul Vixie, "Repudiating Mail-From",=0D http://ops.ietf.org/lists/namedroppers/namedroppers.2002/=0D= msg00658.html=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 10]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D =0D 11. Authors' Addresses=0D =0D Jim Lyon=0D Microsoft Corporation=0D One Microsoft Way=0D Redmond, WA 98052=0D USA=0D jimlyon@microsoft.com=0D =0D Meng Weng Wong=0D Singapore=0D mengwong@dumbo.pobox.com=0D =0D =0D Intellectual Property Statement=0D =0D The IETF takes no position regarding the validity or scope of any=0D Intellectual Property Rights or other rights that might be claimed to=0D= pertain to the implementation or use of the technology described in=0D= this document or the extent to which any license under such rights=0D might or might not be available; nor does it represent that it has=0D made any independent effort to identify any such rights. Information=0D= on the procedures with respect to rights in RFC documents can be=0D found in BCP 78 and BCP 79.=0D =0D Copies of IPR disclosures made to the IETF Secretariat and any=0D assurances of licenses to be made available, or the result of an=0D attempt made to obtain a general license or permission for the use of=0D= such proprietary rights by implementers or users of this=0D specification can be obtained from the IETF on-line IPR repository at=0D= http://www.ietf.org/ipr.=0D =0D The IETF invites any interested party to bring to its attention any=0D= copyrights, patents or patent applications, or other proprietary=0D rights that may cover technology that may be required to implement=0D this standard. Please address the information to the IETF at ietf-=0D= ipr@ietf.org.=0D =0D =0D Disclaimer of Validity=0D =0D This document and the information contained herein are provided on an=0D= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0D= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0D ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0D= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0D INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0D WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0D =0D =0D Lyon, Wong Expires - February 2005 [Page 11]=0D =0C=0D Sender ID: Authenticating E-Mail August 2004=0D= =0D =0D =0D =0D Copyright Statement=0D =0D Copyright (C) The Internet Society (2004). This document is subject=0D= to the rights, licenses and restrictions contained in BCP 78, and=0D except as set forth therein, the authors retain all their rights.=0D =0D =0D Acknowledgment=0D =0D Funding for the RFC Editor function is currently provided by the=0D Internet Society.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Lyon, Wong Expires - February 2005 [Page 12]=0D =0C= --Apple-Mail-5-574445878 Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-marid-pra-00.txt" Content-Disposition: attachment; filename=draft-ietf-marid-pra-00.txt Content-Transfer-Encoding: quoted-printable =0D =0D =0D =0D MARID Working Group J. Lyon=0D= Internet Draft Microsoft Corp=0D= Document: draft-ietf-marid-pra-00.txt=0D Expires: February 2005 August 2004=0D= =0D =0D Purported Responsible Address in E-Mail Messages=0D =0D =0D Status of this Memo=0D =0D By submitting this Internet-Draft, I certify that any applicable=0D patent or other IPR claims of which I am aware have been disclosed,=0D= or will be disclosed, and any of which I become aware will be=0D disclosed, in accordance with RFC 3668.=0D =0D Internet-Drafts are working documents of the Internet Engineering=0D Task Force (IETF), its areas, and its working groups. Note that=0D other groups may also distribute working documents as Internet-=0D Drafts.=0D =0D Internet-Drafts are draft documents valid for a maximum of six months=0D= and may be updated, replaced, or obsoleted by other documents at any=0D= time. It is inappropriate to use Internet-Drafts as reference=0D material or to cite them other than a "work in progress."=0D =0D The list of current Internet-Drafts can be accessed at=0D http://www.ietf.org/1id-abstracts.html=0D =0D The list of Internet-Draft Shadow Directories can be accessed at=0D http://www.ietf.org/shadow.html=0D =0D Abstract=0D =0D The document defines an algorithm by which, given an e-mail message,=0D= one can extract the identity of the party that appears to have most=0D= proximately caused that message to be delivered. This identity is=0D called the "Purported Responsible Address" (PRA).=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D J. Lyon Expires - February 2005 [Page 1]=0D =0C=0D Purported Responsible Address in E-Mail Messages August 2004=0D= =0D =0D Table of Contents=0D =0D 1. Introduction...................................................2=0D= 2. Determining the Purported Responsible Address..................3=0D= 3. Security Considerations........................................4=0D= 4. IANA Considerations............................................4=0D= 5. Acknowledgements...............................................4=0D= 6. References.....................................................4=0D= 6.1 Normative References.......................................4=0D= 6.2 Informative References.....................................5=0D= 7. Author's Address...............................................5=0D= =0D Conventions used in this document=0D =0D The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0D= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0D= document are to be interpreted as described in [RFC2119].=0D =0D =0D 1. Introduction=0D =0D Most E-Mail flows relatively directly from a sender to a recipient,=0D= with a small number of Mail Transfer Agents (MTAs) in between. Some=0D= messages, however, are resent by forwarding agents, mailing list=0D servers, and other such software. These messages effectively result=0D= in two or more mail transactions: one from the sender to the=0D forwarding agent, and another from the agent to the destination.=0D =0D In some cases, messages travel through more than one of these agents.=0D= This can occur, for example, when one mailing list is subscribed to=0D= another, or when the address subscribed to a mailing list is a=0D forwarding service.=0D =0D Further complicating the situation, in some cases the party that=0D introduces a message is not the author of the message. For example,=0D= many news web sites have a "Mail this article" function that the=0D public can use to e-mail a copy of the article to a friend. In this=0D= case, the mail is "from" the person who pressed the button, but is=0D physically sent by the operator of the web site.=0D =0D This document describes an algorithm that allows one to determine who=0D= appears to have most recently caused an e-mail message to be=0D delivered. It does this by inspecting the headers in the message.=0D [RFC2822] contains a detailed specification of all of the relevant=0D headers.=0D =0D Note that the results of this algorithm are only as truthful as the=0D= headers contained in the message; if a message contains fraudulent or=0D= incorrect headers, this algorithm will yield an incorrect result.=0D =0D =0D J. Lyon Expires - February 2005 [Page 2]=0D =0C=0D Purported Responsible Address in E-Mail Messages August 2004=0D= =0D =0D For this reason, the result of the algorithm is called the "Purported=0D= Responsible Address" -- "purported" because it tells you what a=0D message claims about where it came from, but not necessarily where it=0D= actually came from.=0D =0D This document does not prescribe any particular uses for the=0D Purported Responsible Address. However, [SenderID] describes a=0D method of determining whether a particular MTA is authorized to send=0D= mail on behalf of the domain contained in the PRA.=0D =0D =0D 2. Determining the Purported Responsible Address=0D =0D The purported responsible address (PRA) of a message is determined by=0D= the following algorithm:=0D =0D 1. Locate the first non-empty Resent-Sender header in the message.=0D= If no such header is found, continue with step 2. If it is=0D preceded by a non-empty Resent-=46rom header and one or more=0D Received or Return-Path headers occur after said Resent-From=0D header and before the Resent-Sender header, continue with step=0D= 2. Otherwise, proceed to step 5.=0D =0D 2. Locate the first non-empty Resent-=46rom header in the message.=0D= If a Resent-=46rom header is found, proceed to step 5. = Otherwise,=0D continue with step 3.=0D =0D 3. Locate all the non-empty Sender headers in the message. If=0D there are no such headers, continue with step 4. If there is=0D exactly one such header, proceed to step 5. If there is more=0D than one such header, proceed to step 6.=0D =0D 4. Locate all the non-empty =46rom headers in the message. If = there=0D is exactly one such header, continue with step 5. Otherwise,=0D proceed to step 6.=0D =0D 5. A previous step has selected a single header from the message.=0D= If that header is malformed (e.g. it appears to contain multiple=0D= mailboxes, or the single mailbox is hopelessly malformed, or the=0D= single mailbox does not contain a domain name), continue with=0D step 6. Otherwise, return that single mailbox as the Purported=0D= Responsible Address.=0D =0D 6. The message is ill-formed, and it is impossible to determine a=0D= Purported Responsible Address.=0D =0D =0D Note that what constitutes a hopelessly malformed header or a=0D hopelessly malformed mailbox in step 5 above is a matter for local=0D =0D =0D J. Lyon Expires - February 2005 [Page 3]=0D =0C=0D Purported Responsible Address in E-Mail Messages August 2004=0D= =0D =0D policy. Such local policy will never cause two implementations to=0D return different PRAs. However it may cause one implementation to=0D return a PRA where another implementation does not. This will only=0D= occur when dealing with a message containing headers of questionable=0D= legality.=0D =0D Note that steps 1 and 2 above extract the Resent-Sender or Resent-=0D =46rom header from the first resent block (as defined by section = 3.6.6=0D of [RFC2822]) if any. Steps 3 and 4 above extract the Sender or From=0D= header if there are no resent blocks.=0D =0D =0D 3. Security Considerations=0D =0D The PRA, as described by this document, is extracted from message=0D headers that have historically not been verified. Thus, anyone using=0D= the PRA for any purpose MUST be aware that the headers from which is=0D= is derived might be fraudulent, malicious, malformed and/or=0D incorrect. [SenderID] describes one mechanism for validating the=0D PRA.=0D =0D =0D 4. IANA Considerations=0D =0D This document contains no actions for IANA.=0D =0D =0D 5. Acknowledgements=0D =0D The PRA concept was first published in [CallerID]. It as been=0D refined using valuable suggestions from members of the MARID working=0D= group.=0D =0D =0D 6. References=0D =0D 6.1 Normative References=0D =0D [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate=0D Requirement Levels", RFC 2119.=0D =0D [RFC2822] P. Resnick (editor), "Internet Message Format", RFC 2822.=0D= =0D =0D =0D =0D =0D =0D =0D =0D =0D J. Lyon Expires - February 2005 [Page 4]=0D =0C=0D Purported Responsible Address in E-Mail Messages August 2004=0D= =0D =0D =0D 6.2 Informative References=0D =0D [CallerID] Microsoft Corporation, Caller ID for E-Mail Technical=0D Specification,=0D http://www.microsoft.com/mscorp/twc/privacy/spam_callerid=0D= .mspx.=0D =0D [SenderID] J. Lyon and M. Wong, "Sender ID: Authenticating E-Mail",=0D= draft-ietf-marid-core-03. Work in progress.=0D =0D =0D =0D 7. Author's Address=0D =0D Jim Lyon=0D Microsoft Corporation=0D One Microsoft Way=0D Redmond, WA 98052=0D USA=0D jimlyon@microsoft.com=0D =0D =0D Intellectual Property Statement=0D =0D The IETF takes no position regarding the validity or scope of any=0D Intellectual Property Rights or other rights that might be claimed to=0D= pertain to the implementation or use of the technology described in=0D= this document or the extent to which any license under such rights=0D might or might not be available; nor does it represent that it has=0D made any independent effort to identify any such rights. Information=0D= on the procedures with respect to rights in RFC documents can be=0D found in BCP 78 and BCP 79.=0D =0D Copies of IPR disclosures made to the IETF Secretariat and any=0D assurances of licenses to be made available, or the result of an=0D attempt made to obtain a general license or permission for the use of=0D= such proprietary rights by implementers or users of this=0D specification can be obtained from the IETF on-line IPR repository at=0D= http://www.ietf.org/ipr.=0D =0D The IETF invites any interested party to bring to its attention any=0D= copyrights, patents or patent applications, or other proprietary=0D rights that may cover technology that may be required to implement=0D this standard. Please address the information to the IETF at ietf-=0D= ipr@ietf.org.=0D =0D =0D =0D =0D =0D J. Lyon Expires - February 2005 [Page 5]=0D =0C=0D Purported Responsible Address in E-Mail Messages August 2004=0D= =0D =0D =0D Disclaimer of Validity=0D =0D This document and the information contained herein are provided on an=0D= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0D= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0D ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0D= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0D INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0D WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0D =0D =0D Copyright Statement=0D =0D Copyright (C) The Internet Society (2004). This document is subject=0D= to the rights, licenses and restrictions contained in BCP 78, and=0D except as set forth therein, the authors retain all their rights.=0D =0D =0D Acknowledgment=0D =0D Funding for the RFC Editor function is currently provided by the=0D Internet Society.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D J. Lyon Expires - February 2005 [Page 6]=0D =0C= --Apple-Mail-5-574445878 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-5-574445878-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 19:55:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22861 for ; Mon, 16 Aug 2004 19:55: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 i7GNYORt005712; Mon, 16 Aug 2004 16:34:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GNYOAt005711; Mon, 16 Aug 2004 16:34:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GNYNKZ005702 for ; Mon, 16 Aug 2004 16:34:23 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reputation systems Date: Mon, 16 Aug 2004 18:34:23 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02B04CC3@cliff.bai.org> Thread-Topic: Reputation systems thread-index: AcSDtndNvGZModrbRJq9RPvAkYvmsgAMjCpw From: "Ryan Malayter" To: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7GNYNKZ005706 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Arnt Gulbrandsen] > >Ryan Malayter writes: >>We got a lot of false positives with the SpamCop list, > >(That echoes my experience while I used the SC list.) > >>and other BLs are bound to be worse. > >Why? Because SpamCop is supposedly very aggressive about automatically aging out "stale" entries, while other BLs are not. Most of the other BLs are manually maintained, and don't seem to publish their "rules" for listing as clearly as SpamCop. An "incorrect" entry in the SpamCop BL eventually drops out on its own; other lists may or may not require manual removal. (Or so I gather from reading the BL sites; not much information on the "rules" for each BL is public.) This makes me *think* SpamCop would yield fewer false positives, but I do know for sure, so want to perform tests to see if my guess is right. Regards, Ryan From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 20:53:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25596 for ; Mon, 16 Aug 2004 20:53:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H0SLaN008319; Mon, 16 Aug 2004 17:28: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 i7H0SLuf008318; Mon, 16 Aug 2004 17:28:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H0SKrN008312 for ; Mon, 16 Aug 2004 17:28:20 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7H0SGmn019178; Mon, 16 Aug 2004 17:28:16 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Aug 2004 17:28:16 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'John Levine'" , ietf-mxcomp@imc.org, asrg@ietf.org Cc: rmalayter@bai.org Subject: REDIRECt to ASRG RE: Reputation systems Date: Mon, 16 Aug 2004 17:28: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: I think that this is getting into an ASRG question. If we create a graph of false positives vs false negatives we get an L shaped curve for most filtering technologies that are parameterizable and a point for a non perameterized technology such as a blacklist. Rather than arguing this point round and round does anyone have a ready made graph with the various blacklists plotted on it so that we could make a useful comparison? There are two reasons why a list would have more false positives, the listing criteria/application thereof could be wrong or the list could be more aggressive in listing more spam sources. If List-A listed 100 addresses and 80 were wrong this would result in fewer false positives than List-B listing 1,000,000 addresses with 800 wrong. So there is a discrimination function here... > >We got a lot of false positives with the SpamCop list, and other BLs > >are bound to be worse. > > Actually, Spamcop's list is infamous for its vast number of false > positives. That's why nobody I know uses it for anything more than > a fairly low-weight input into a scoring system. > > Try the Spamhaus SBL and XBL and you'll find very few misfires. From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 21:25: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 VAA27408 for ; Mon, 16 Aug 2004 21:25:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H10mVI010167; Mon, 16 Aug 2004 18:00: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 i7H10mig010166; Mon, 16 Aug 2004 18:00:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H10lBa010160 for ; Mon, 16 Aug 2004 18:00:47 -0700 (PDT) (envelope-from sb0-0647ddf24c-johnl@iecc.com) Received: (qmail 5227 invoked from network); 17 Aug 2004 01:00:52 -0000 Received: (ofmipd 127.0.0.1); 17 Aug 2004 01:00:30 -0000 Date: 16 Aug 2004 21:00:52 -0400 Message-ID: From: "John R Levine" To: "Hallam-Baker, Phillip" Cc: "ietf-mxcomp@imc.org" , "asrg@ietf.org" , "rmalayter@bai.org" Subject: Re: REDIRECt to ASRG RE: Reputation systems In-Reply-To: References: Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree. It's quite appropriate for the ASRG IAR (identity, authentication, and reputation) subgroup, on the list iar@asrg.sp.am. > I think that this is getting into an ASRG question. > > If we create a graph of false positives vs false negatives we get > an L shaped curve for most filtering technologies that are > parameterizable and a point for a non perameterized technology > such as a blacklist. > > Rather than arguing this point round and round does anyone have > a ready made graph with the various blacklists plotted on it so > that we could make a useful comparison? > > There are two reasons why a list would have more false positives, > the listing criteria/application thereof could be wrong or the > list could be more aggressive in listing more spam sources. > > If List-A listed 100 addresses and 80 were wrong this would result > in fewer false positives than List-B listing 1,000,000 addresses > with 800 wrong. So there is a discrimination function here... Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Mon Aug 16 21:53: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 VAA29067 for ; Mon, 16 Aug 2004 21: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 i7H1RubN013322; Mon, 16 Aug 2004 18:27: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 i7H1Runa013321; Mon, 16 Aug 2004 18:27:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H1RpT5013295 for ; Mon, 16 Aug 2004 18:27:52 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BwslS-0007pf-00 for ; Tue, 17 Aug 2004 03:27:50 +0200 Received: from 212.82.251.201 ([212.82.251.201]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Aug 2004 03:27:50 +0200 Received: from nobody by 212.82.251.201 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Aug 2004 03:27:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: timestamps / 2476bis / PRA (was: Changes for protocol-01) Date: Tue, 17 Aug 2004 03:24:15 +0200 Organization: Lines: 37 Message-ID: <41215E3F.28B0@xyzzy.claranet.de> References: <2AAE79DE-ED79-11D8-850F-000393A56BB6@glyphic.com> <411DE4C0.50BE@xyzzy.claranet.de> <20040814151523.GJ28401@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.201 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: [about %{t} timestamps] > it's not meant to be human readable; it's meant to give a > hint to the explanation CGI. Okay, it's for explanations by URL, that makes sense. Maybe mention it in an example. I'd still prefer the format... | The syntax is: YYYYMMDDhhmmssZ | Example: 19990609001326.34352Z ...as in RfC 3161, but if you're sure that the CGI knows all about 20380119031407Z (RfC 2626), the timestamps should work. I'll look into the new ABNF of protocol-01 later. In the new SUBMITTER-03 bounces can still go to an unchecked MAIL FROM, so that's not yet in a state where I could consider it to be "compatible" with SPF classic. PRA-00 is almost the same algorithm as before, so it does not yet handle the common "missing Sender:" case. The "MAY" in 2476 8.1 still exists in draft-gellens-submit-bis-00.txt The PRA algorithm without a solution for the "missing Sender:" problem on the side of the PRA-aware recipient won't work. Mail providers can't publish a SPF2.0/PRA sender policy, if this doesn't work with legacy MUAs + 3rd party "MAYbe not" MSAs of their users. SYMPA lists: They have an Errors-To: matching the Return-Path: But a special Errors-To: PRA-step for SYMPA makes no sense, a general "missing Sender: derived from Return-Path:" PRA-step would work for everybody. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 06:00:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04988 for ; Tue, 17 Aug 2004 06:00:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H9PLYK090348; Tue, 17 Aug 2004 02:25: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 i7H9PLcT090347; Tue, 17 Aug 2004 02:25:21 -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 i7H9PJuT090336 for ; Tue, 17 Aug 2004 02:25:20 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59029) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1Bx0DM-0003WL-4P (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Tue, 17 Aug 2004 10:25:08 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Bx0DL-0000a6-Jk; Tue, 17 Aug 2004 10:25:07 +0100 Date: Tue, 17 Aug 2004 10:25:07 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Ryan Malayter cc: MARID Subject: RE: Reputation systems In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02B04CC3@cliff.bai.org> Message-ID: References: <792DE28E91F6EA42B4663AE761C41C2A02B04CC3@cliff.bai.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 16 Aug 2004, Ryan Malayter wrote: > > Most of the other BLs are manually maintained No, the XBL is based on a combination of blacklists that use automatic intrusion detection techniques to identify 0wned hosts. 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 Tue Aug 17 10:51:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20715 for ; Tue, 17 Aug 2004 10:51: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 i7HEPbM4048041; Tue, 17 Aug 2004 07:25: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 i7HEPbCZ048040; Tue, 17 Aug 2004 07:25:37 -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 i7HEPa05048021 for ; Tue, 17 Aug 2004 07:25: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 CEDF2132CD1; Tue, 17 Aug 2004 10:30:15 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id DEC978A2; Tue, 17 Aug 2004 10:25:35 -0400 (EDT) Date: Tue, 17 Aug 2004 10:25:35 -0400 From: Meng Weng Wong To: Chris Haynes Cc: Meng Weng Wong , IETF MARID WG Subject: Re: What Meng said Message-ID: <20040817142535.GG3243@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02c401c4837b$88cf7590$0200000a@ringo> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 16, 2004 at 11:26:39AM +0100, Chris Haynes wrote: | | Please may I ask a brutally simple question. | | My question below applies only to those messages in which the domain of the | MAIL-FROM is different from the domain of the PRA. | | Where, in the collection of drafts issued on Friday, does Sender-ID refer to the | rejection of a message as a result of evaluating the record associated with its | MAIL-FROM domain? Sender ID as currently specified doesn't do that. If people want the MAIL FROM to play a role in Sender ID, they should say so. If they do not say so, the working assumption is that nobody cares. I personally think that if the PRA lookup returns "none" or "unknown", MAIL FROM should be checked, and if that test returns "fail" then the message should be rejected. This is in line with the "unified SPF" model. The converse is the scenario where a MAIL FROM pass is returned, and a receiver arrives at a generally positive feeling about the sender; that would allow EzMLM and similar MLMs to get their mail through, and reduce the false positives that would occur on a PRA check alone. From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 11:26: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 LAA23032 for ; Tue, 17 Aug 2004 11:26:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HF3UfW055529; Tue, 17 Aug 2004 08:03: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 i7HF3Uwb055528; Tue, 17 Aug 2004 08:03:30 -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 i7HF3URr055510 for ; Tue, 17 Aug 2004 08:03:30 -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 i7HF3PxS032449 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 17 Aug 2004 08:03:26 -0700 Date: Tue, 17 Aug 2004 08:03:25 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Meng Weng Wong cc: Chris Haynes , IETF MARID WG Subject: Re: What Meng said In-Reply-To: <20040817142535.GG3243@dumbo.pobox.com> Message-ID: References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 17 Aug 2004, Meng Weng Wong wrote: > I personally think that if the PRA lookup returns "none" or > "unknown", MAIL FROM should be checked, and if that test > returns "fail" then the message should be rejected. You mean if the message has *no* From, Sender, Resent-From, or Resent-Sender headers, or if there is no SUBMITTER argument? -Rand From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 11:26: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 LAA23081 for ; Tue, 17 Aug 2004 11:26:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HF3X0s055551; Tue, 17 Aug 2004 08:03: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 i7HF3XRf055550; Tue, 17 Aug 2004 08:03: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 i7HF3XP8055544 for ; Tue, 17 Aug 2004 08:03:33 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7HF3Pj17213; Tue, 17 Aug 2004 08:03:25 -0700 Date: Tue, 17 Aug 2004 08:03:20 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1505433604.20040817080320@brandenburg.com> To: Margaret Olson CC: Shevek , IETF MARID WG Subject: Re: Does marid-submitter-02 really make sense? In-Reply-To: <5EA09902-EA03-11D8-86C5-000A95BC6A7E@margaretolson.com> References: <20040805164027.GA2443@danisch.de> <01LDAWC6X2SQ00005R@mauve.mrochek.com> <5EA09902-EA03-11D8-86C5-000A95BC6A7E@margaretolson.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> The advantage to SUBMITTER is more obvious in combination with MO> reputation and accreditation. It lets you start the MO> accreditation/reputation check early, either before accepting data or MO> in parallel with the PRA check in the headers. Maybe this has been mentioned before, but I had missed it. The idea that it permits a "parallel processing" (or, really, pre-fetching) optimization simply had not registered with me. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 11:39: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 LAA23988 for ; Tue, 17 Aug 2004 11:39: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 i7HFBJNm056843; Tue, 17 Aug 2004 08:11: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 i7HFBJNU056842; Tue, 17 Aug 2004 08:11:19 -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 i7HFBIee056832 for ; Tue, 17 Aug 2004 08:11:18 -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 EAFFA132CF7; Tue, 17 Aug 2004 11:15:54 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 5D0C65A9; Tue, 17 Aug 2004 11:11:14 -0400 (EDT) Date: Tue, 17 Aug 2004 11:11:14 -0400 From: Meng Weng Wong To: Rand Wacker Cc: Meng Weng Wong , Chris Haynes , IETF MARID WG Subject: Re: What Meng said Message-ID: <20040817151114.GH3243@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 17, 2004 at 08:03:25AM -0700, Rand Wacker wrote: | On Tue, 17 Aug 2004, Meng Weng Wong wrote: | | > I personally think that if the PRA lookup returns "none" or | > "unknown", MAIL FROM should be checked, and if that test | > returns "fail" then the message should be rejected. | | You mean if the message has *no* From, Sender, Resent-From, or | Resent-Sender headers, or if there is no SUBMITTER argument? | I mean: MAIL FROM: Resent-From: From: Given that clueless.com does not publish an SPF record, an MTA operating solely on a PRA algorithm will let the message through because the result of the PRA evaluation is "none". Given that the installed base of MUAs cannot be expected to display "Allegedly from service@citibank.com via noSPFrecord@clueless.com", for the next few years the average user will see in their MUA only From: If an MTA were allowed to do SPF checks on the MAIL FROM when the spf/PRA result is "none" or "unknown", this scenario would be defeated. Upgrading MTAs is quicker than upgrading MUAs. That shifts the spammer position to: MAIL FROM: Resent-From: From: That is a small but significant improvement: 1) it tells clueless.com that they need to set up SPF records 2) it keeps the existing SPF Classic userbase happy, and removes the need for a dual-standard deployment plan. From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 12:00: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 MAA25185 for ; Tue, 17 Aug 2004 12:00:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFPxM3059511; Tue, 17 Aug 2004 08:25: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 i7HFPxlA059510; Tue, 17 Aug 2004 08:25:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFPxQP059503 for ; Tue, 17 Aug 2004 08:25:59 -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 i7HFQ2j19089 for ; Tue, 17 Aug 2004 08:26:02 -0700 Date: Tue, 17 Aug 2004 08:25:57 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <658564310.20040817082557@brandenburg.com> To: IETF MARID WG Subject: Re: What Meng said In-Reply-To: References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@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 Rand, >> I personally think that if the PRA lookup returns "none" or >> "unknown", MAIL FROM should be checked, and if that test >> returns "fail" then the message should be rejected. RW> You mean if the message has *no* From, Sender, Resent-From, or RW> Resent-Sender headers, or if there is no SUBMITTER argument? The new PRA document makes clear that PRA derivation is based on Re-sent, Sender and From. Indeed, that is exactly what a reasonable reading of RFC2822 (and RFC822 and RFC733) should cause one to expect. What would be more than a little strange would be to impart additional "source responsibility" meaning to a return address (rfc2821.mailfrom), if re-sent,sender,from were problematic. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 12:02: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 MAA25308 for ; Tue, 17 Aug 2004 12:02: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 i7HFbpdZ061544; Tue, 17 Aug 2004 08:37: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 i7HFbp5n061542; Tue, 17 Aug 2004 08:37:51 -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 i7HFboOh061535 for ; Tue, 17 Aug 2004 08:37:50 -0700 (PDT) (envelope-from roy+dated+1095349064.535ba7@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7HFcdmv041018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Aug 2004 15:38:45 GMT (envelope-from roy+dated+1095349064.535ba7@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7HFbiTi066196 for ; Tue, 17 Aug 2004 16:37:44 +0100 (BST) (envelope-from roy+dated+1095349064.535ba7@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7HFbien066195 for ietf-mxcomp@imc.org; Tue, 17 Aug 2004 16:37:44 +0100 (BST) (envelope-from roy+dated+1095349064.535ba7@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 17 Aug 2004 16:37:43 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16674.9798.699170.553196@giles.gnomon.org.uk> Date: Tue, 17 Aug 2004 16:37:42 +0100 To: Meng Weng Wong Cc: Chris Haynes , IETF MARID WG Subject: Checking MAIL FROM (was: What Meng said) In-Reply-To: <20040817142535.GG3243@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@dumbo.pobox.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 >>>>> "Meng" == Meng Weng Wong writes: Meng> Sender ID as currently specified doesn't do that. Meng> If people want the MAIL FROM to play a role in Sender ID, Meng> they should say so. If they do not say so, the working Meng> assumption is that nobody cares. Well, FWIW I intend to continue to publish SPFv1 records along side Sender ID records for my personal domain, and will probably do likewise with my employer's domains when I start publishing records for them. If people don't wish to check the MAIL FROM (eg because there is mail forwarded into their domain through forwarders which are Sender ID compliant but not SRS-compliant, or just because they don't like SPFv1) then that's their choice. But I no reason to stop publishing the information necessary to allow MAIL FROM checks on my domains by those who wish to perform them. Meng> I personally think that if the PRA lookup returns "none" or Meng> "unknown", MAIL FROM should be checked, and if that test Meng> returns "fail" then the message should be rejected. Well, if you're only going to check the MAIL FROM when the PRA check returns has no Sender ID record, then that means I'll still have to continue publishing SPFv1 records if I want to tell the world that *all* mail with an envelope sender in my domain originates from one of my MTAs. Meng> This is in line with the "unified SPF" model. Personally I think we should leave this as "for future study". I can live with Sender ID in its current form, and reopening the 'identity' can of worms at this late stage will just delay Sender ID. Let's get Sender ID out the door, and then we can think about validating other identities. It would be relatively easy to add other identities to Sender ID in a backward-compatible way at a later date, particularly given the new versioning mechanism. -roy From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 12:23: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 MAA26246 for ; Tue, 17 Aug 2004 12:23: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 i7HFiRQh062700; Tue, 17 Aug 2004 08:44: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 i7HFiRBo062699; Tue, 17 Aug 2004 08:44:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mynah.mail.pas.earthlink.net (mynah.mail.pas.earthlink.net [207.217.120.228]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFiQtw062691 for ; Tue, 17 Aug 2004 08:44:26 -0700 (PDT) (envelope-from tripp@corp.earthlink.net) Received: from atl3-dmz.fw.earthlink.net ([199.174.117.121] helo=[10.30.102.141]) by mynah.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 4.34) id 1Bx68T-0007kN-Qb; Tue, 17 Aug 2004 08:44:29 -0700 In-Reply-To: <20040817151114.GH3243@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@dumbo.pobox.com> <20040817151114.GH3243@dumbo.pobox.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <547F48DE-F064-11D8-8B0A-000A95BDB38A@corp.earthlink.net> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Tripp Cox Subject: Re: What Meng said Date: Tue, 17 Aug 2004 11:44:31 -0400 To: Meng Weng Wong X-Mailer: Apple Mail (2.619) X-ELNK-Trace: 3507b2fe2d9b3ca5cc16ce54e02836f06b13ff5bf19aef8a4cc357cc6f751cb3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 199.174.117.121 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 17, 2004, at 11:11 AM, Meng Weng Wong wrote: > If an MTA were allowed to do SPF checks on the MAIL FROM > when the spf/PRA result is "none" or "unknown", this > scenario would be defeated. Upgrading MTAs is quicker than > upgrading MUAs. > > That shifts the spammer position to: > > MAIL FROM: > Resent-From: > From: > > That is a small but significant improvement: > > 1) it tells clueless.com that they need to set up SPF records > > 2) it keeps the existing SPF Classic userbase happy, and > removes the need for a dual-standard deployment plan. I think Meng has highlighted an incredibly important practical issue with PRA and marid-core as presently defined. I have recently been struggling to determine the ultimate utility of MARID to the service provider, without much to show for it. Consider the following postulate: A policy for authorizing a given message to be transported by a given agent cannot be sufficiently expressed by a single domain in many cases. The PRA "algorithm" is a means to derive a single pointer to an expression of policy. As such, the chances that a receiver can conclude an explicit permit/deny result is greatly diminished (i.e. the only potentially conclusive, explicit result is that the PRA points to an explicit deny policy). By considering and respecting the policies of both (or perhaps even all) domains purporting to be senders, one could apply logical equations to yield greater conclusive results (e.g. the table I provide below for applying policies to the 2821 and 2822 From domains). 2821 2822 MAIL FROM From: - - = Don't accept. + - = Don't accept. - + = Don't accept. - ?~ = Don't accept. ?~ - = Don't accept. ?~ ?~ = Inconclusive. + ?~ = Inconclusive. ?~ + = Inconclusive. + + = Accept. This could be extended to consider the policies of Sender, Resent-From, or any other purported senders. Tripp From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 12:26: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 MAA26691 for ; Tue, 17 Aug 2004 12:26: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 i7HG70JH066709; Tue, 17 Aug 2004 09:07: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 i7HG70B6066708; Tue, 17 Aug 2004 09:07:00 -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 i7HG6xXC066696 for ; Tue, 17 Aug 2004 09:06:59 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 11938 invoked from network); 17 Aug 2004 16:08:41 -0000 Received: from unknown (HELO ?192.168.254.135?) (208.198.98.24) by ns1.hoster907.com with SMTP; 17 Aug 2004 16:08:41 -0000 In-Reply-To: <20040817151114.GH3243@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@dumbo.pobox.com> <20040817151114.GH3243@dumbo.pobox.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77E164BA-F067-11D8-9D2A-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: Chris Haynes , Rand Wacker , IETF MARID WG From: Margaret Olson Subject: Re: What Meng said Date: Tue, 17 Aug 2004 12:06:59 -0400 To: Meng Weng Wong X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 17, 2004, at 11:11 AM, Meng Weng Wong wrote: > > On Tue, Aug 17, 2004 at 08:03:25AM -0700, Rand Wacker wrote: > | On Tue, 17 Aug 2004, Meng Weng Wong wrote: > | > | > I personally think that if the PRA lookup returns "none" or > | > "unknown", MAIL FROM should be checked, and if that test > | > returns "fail" then the message should be rejected. > | > | You mean if the message has *no* From, Sender, Resent-From, or > | Resent-Sender headers, or if there is no SUBMITTER argument? > | > > I mean: > > MAIL FROM: > Resent-From: > From: > > Given that clueless.com does not publish an SPF record, an > MTA operating solely on a PRA algorithm will let the message > through because the result of the PRA evaluation is "none". > > Given that the installed base of MUAs cannot be expected to > display "Allegedly from service@citibank.com via > noSPFrecord@clueless.com", for the next few years the > average user will see in their MUA only > > From: > > If an MTA were allowed to do SPF checks on the MAIL FROM > when the spf/PRA result is "none" or "unknown", this > scenario would be defeated. Upgrading MTAs is quicker than > upgrading MUAs. > > That shifts the spammer position to: > > MAIL FROM: > Resent-From: > From: > > That is a small but significant improvement: > > 1) it tells clueless.com that they need to set up SPF records > > 2) it keeps the existing SPF Classic userbase happy, and > removes the need for a dual-standard deployment plan. > So this has nothing to do with the presence or absence of the SUBMITTER parameter, but rather with the presence of a SPF v2/PRA record for the PRA domain. I'm in favor - unless I'm missing something it doesn't diminish the PRA, getting rid of dual standards is a good thing, and more net happiness in the world is also a good thing :-). Margaret. From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 12:34: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 MAA27324 for ; Tue, 17 Aug 2004 12:34: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 i7HGC4m0067720; Tue, 17 Aug 2004 09:12: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 i7HGC4Fo067719; Tue, 17 Aug 2004 09:12:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ddg.com (mail.ddg.com [66.93.83.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HGC2ge067680 for ; Tue, 17 Aug 2004 09:12:03 -0700 (PDT) (envelope-from awd@DDG.com) Received: from [66.93.83.221] (account awd HELO [192.168.1.35]) by ddg.com (CommuniGate Pro SMTP 4.2) with ESMTP id 1509130; Tue, 17 Aug 2004 11:11:58 -0500 In-Reply-To: <20040817142535.GG3243@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@dumbo.pobox.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/alternative; boundary=Apple-Mail-1-635275882 Message-Id: <24C74A00-F068-11D8-9772-000A9566A350@DDG.com> Cc: IETF MARID WG From: "Andrew W. Donoho" Subject: Re: What Meng said Date: Tue, 17 Aug 2004 11:11:49 -0500 To: Meng Weng Wong X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-1-635275882 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 17, 2004, at 09:25, Meng Weng Wong wrote: > Sender ID as currently specified doesn't do that. > > If people want the MAIL FROM to play a role in Sender ID, > they should say so. If they do not say so, the working > assumption is that nobody cares. > > I personally think that if the PRA lookup returns "none" or > "unknown", MAIL FROM should be checked, and if that test > returns "fail" then the message should be rejected. Meng, This statement does not make any sense to me. SPF is a 2821 time check. While the Sender-ID spec tries to eliminate it, Sender-ID is really a 2822 time check and it performs a different function than SPF. There is no reason that Sender-ID precludes an SPF check. In fact, if you think of the anti-spam problem as a security problem, then you want defense in depth. You want any mail to pass multiple checks. Therefore, I think many operators will check SPF before the DATA phase and Sender-ID, along with other anti-spam filters, after receipt. That is the beauty of SPF - it is simple and, hence, performs one thing well. While you made a deal to combine the two specs, that is not necessary and I think that the SPF community is uninterested in dropping a working simple protocol. They can coexist. Andrew ____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-1-635275882 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Aug 17, 2004, at 09:25, Meng Weng Wong wrote: Sender ID as currently specified doesn't do that. If people want the MAIL FROM to play a role in Sender ID, they should say so. If they do not say so, the working assumption is that nobody cares. I personally think that if the PRA lookup returns "none" or "unknown", MAIL FROM should be checked, and if that test returns "fail" then the message should be rejected. Meng, This statement does not make any sense to me. SPF is a 2821 time check. While the Sender-ID spec tries to eliminate it, Sender-ID is really a 2822 time check and it performs a different function than SPF. There is no reason that Sender-ID precludes an SPF check. In fact, if you think of the anti-spam problem as a security problem, then you want defense in depth. You want any mail to pass multiple checks. Therefore, I think many operators will check SPF before the DATA phase and Sender-ID, along with other anti-spam filters, after receipt. That is the beauty of SPF - it is simple and, hence, performs one thing well. While you made a deal to combine the two specs, that is not necessary and I think that the SPF community is uninterested in dropping a working simple protocol. They can coexist. Andrew Helvetica____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-1-635275882-- From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 12:45:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28524 for ; Tue, 17 Aug 2004 12:45:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HGOJmr070104; Tue, 17 Aug 2004 09:24: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 i7HGOJA2070103; Tue, 17 Aug 2004 09:24:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp3g.bellsouth.com (aismtp3g.bellsouth.com [139.76.165.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HGOIWU070060 for ; Tue, 17 Aug 2004 09:24:18 -0700 (PDT) (envelope-from Damon.Sauer@bellsouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp3g.bellsouth.com with ESMTP; Tue, 17 Aug 2004 12:22:54 -0400 Content-Transfer-Encoding: 7bit Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48476.710D9760" Subject: RE: What Meng said X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Tue, 17 Aug 2004 11:22:51 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB9B7D526@bremocog-55> Thread-Topic: What Meng said Thread-Index: AcSEdU+MI+m2YCTpQsyrtgE167EkjgAAPnHQ From: "Sauer, Damon" To: "Andrew W. Donoho" , "Meng Weng Wong" Cc: "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_01C48476.710D9760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Andrew. I think it will also be most useful during the transition. =20 Regards,=20 Damon Sauer=20 [Postmaster] -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Andrew W. Donoho Sent: Tuesday, August 17, 2004 12:12 PM To: Meng Weng Wong Cc: IETF MARID WG Subject: Re: What Meng said On Aug 17, 2004, at 09:25, Meng Weng Wong wrote:=20 Sender ID as currently specified doesn't do that.=20 If people want the MAIL FROM to play a role in Sender ID,=20 they should say so. If they do not say so, the working=20 assumption is that nobody cares.=20 I personally think that if the PRA lookup returns "none" or=20 "unknown", MAIL FROM should be checked, and if that test=20 returns "fail" then the message should be rejected.=20 Meng,=20 This statement does not make any sense to me. SPF is a 2821 time check. While the Sender-ID spec tries to eliminate it, Sender-ID is really a 2822 time check and it performs a different function than SPF. There is no reason that Sender-ID precludes an SPF check. In fact, if you think of the anti-spam problem as a security problem, then you want defense in depth. You want any mail to pass multiple checks. Therefore, I think many operators will check SPF before the DATA phase and Sender-ID, along with other anti-spam filters, after receipt. That is the beauty of SPF - it is simple and, hence, performs one thing well. While you made a deal to combine the two specs, that is not necessary and I think that the SPF community is uninterested in dropping a working simple protocol. They can coexist.=20 Andrew=20 ____________________________________=20 Andrew W. Donoho=20 awd@DDG.com, PGP Key ID: 0x81D0F250=20 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m)=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon, this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 113 ------_=_NextPart_001_01C48476.710D9760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree with Andrew.
I=20 think it will also be most useful during the = transition.
 

Regards, =
Damon Sauer

[Postmaster]  -----Original=20 Message-----
From: owner-ietf-mxcomp@mail.imc.org=20 [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Andrew W.=20 Donoho
Sent: Tuesday, August 17, 2004 12:12 PM
To: = Meng Weng=20 Wong
Cc: IETF MARID WG
Subject: Re: What Meng=20 said



On Aug 17, 2004, at 09:25, Meng Weng Wong wrote:
Sender ID as currently specified doesn't do that.

If people want the MAIL FROM to play a role in Sender ID, =
they should say so. If they do not say so, the working
assumption is that nobody cares.

I personally think that if the PRA lookup returns "none" or =
"unknown", MAIL FROM should be checked, and if that test
returns "fail" then the message should be rejected.=20

Meng,

This statement does not make any sense to me. SPF is a 2821 time = check.=20 While the Sender-ID spec tries to eliminate it, Sender-ID is really a = 2822=20 time check and it performs a different function than SPF. There is no = reason=20 that Sender-ID precludes an SPF check. In fact, if you think of the = anti-spam=20 problem as a security problem, then you want defense in depth. You = want any=20 mail to pass multiple checks. Therefore, I think many operators will = check SPF=20 before the DATA phase and Sender-ID, along with other anti-spam = filters, after=20 receipt. That is the beauty of SPF - it is simple and, hence, performs = one=20 thing well. While you made a deal to combine the two specs, that is = not=20 necessary and I think that the SPF community is uninterested in = dropping a=20 working simple protocol. They can coexist.

Andrew

____________________________________ =
Andrew W. Donoho
awd@DDG.com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)

=

*****

The = information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 113

 ------_=_NextPart_001_01C48476.710D9760-- From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 12: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 MAA28614 for ; Tue, 17 Aug 2004 12:46: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 i7HGQGrx070463; Tue, 17 Aug 2004 09:26:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HGQGJJ070462; Tue, 17 Aug 2004 09:26:16 -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 i7HGQF4C070455 for ; Tue, 17 Aug 2004 09:26:15 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7HGPoj24522; Tue, 17 Aug 2004 09:25:50 -0700 Date: Tue, 17 Aug 2004 09:25:46 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <17815173.20040817092546@brandenburg.com> To: Meng Weng Wong CC: Rand Wacker , Chris Haynes , IETF MARID WG Subject: Re: What Meng said In-Reply-To: <20040817151114.GH3243@dumbo.pobox.com> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@dumbo.pobox.com> <20040817151114.GH3243@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> MAIL FROM: MWW> Resent-From: MWW> From: MWW> Given that clueless.com does not publish an SPF record, an MWW> MTA operating solely on a PRA algorithm will let the message MWW> through because the result of the PRA evaluation is "none". That's not a PRA issue. You are suggesting a behavior that goes far outside of the PRA specification and is strictly within the spf/sender-id specification. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 13:15:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00636 for ; Tue, 17 Aug 2004 13:15:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HGpwGb075133; Tue, 17 Aug 2004 09:51:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HGpwmZ075132; Tue, 17 Aug 2004 09:51:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HGpvOY075108 for ; Tue, 17 Aug 2004 09:51:57 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Asrg] REDIRECt to ASRG RE: Reputation systems Date: Tue, 17 Aug 2004 11:51:59 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02B04DF4@cliff.bai.org> Thread-Topic: [Asrg] REDIRECt to ASRG RE: Reputation systems thread-index: AcSD+DGHNMfac+VqQRmsUNhy9tX79AAfiINg From: "Ryan Malayter" To: "Pete McNeil" , "Hallam-Baker, Phillip" Cc: "John Levine" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7HGpvOY075124 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Pete McNeil] > Here is a link to the analysis: > > http://www2.spamchk.com/public.html > > Hope this helps, > _M This is very useful, and most of what I was looking for, but I'd still like to see an analysis done with hand-filtered email. It does appear that "SBL" (which I assume is SpamHaus's SBL) has a very low false positive rate. However, it also blocked only about 10% of incoming spam. The XBL caught a lot more, but still less than 65% of the spam. But this better performance cost nearly 30 false positives (each of which could lead to a very irate customer for a business or government organization). The numbers seem to indicate that IP-based blacklisting is essentially useless without further content filtering. None even came close to filtering 75% of spam, and some caused hundreds or thousands of false positives. I wonder if the same poor performance will be the output of domain-name-based reputation systems after MARID's work is widely deployed. Do you have a key that explains what each of the test abbreviations are on this page? Some are obvious, others are not. Thanks, Ryan From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 13:24:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01369 for ; Tue, 17 Aug 2004 13:24:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HGvSDr076338; Tue, 17 Aug 2004 09:57: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 i7HGvRP1076337; Tue, 17 Aug 2004 09:57: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 i7HGvR3K076331 for ; Tue, 17 Aug 2004 09:57: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 i7HGvKj26984; Tue, 17 Aug 2004 09:57:20 -0700 Date: Tue, 17 Aug 2004 09:57:16 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1167722350.20040817095716@brandenburg.com> To: Tripp Cox CC: Meng Weng Wong , IETF MARID WG Subject: Re: What Meng said In-Reply-To: <547F48DE-F064-11D8-8B0A-000A95BDB38A@corp.earthlink.net> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@dumbo.pobox.com> <20040817151114.GH3243@dumbo.pobox.com> <547F48DE-F064-11D8-8B0A-000A95BDB38A@corp.earthlink.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 Tripp, TC> A policy for authorizing a given message to be transported by a given TC> agent cannot be sufficiently expressed by a single domain in many TC> cases. The PRA "algorithm" is a means to derive a single pointer to an TC> expression of policy. As such, the chances that a receiver can 1. The underlying problem that you are reacting to has to do with having the entity that is posting a message be the one to authorize the path the message follows. 2. What PRA does is to formalize a reality: there is only one entity that did the latest posting of the message. All of the other fields that might be present and refer to a poster refer to entities that are not relevant to the CURRENT transmission. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 13:56: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 NAA03593 for ; Tue, 17 Aug 2004 13:56:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HHP3e8082481; Tue, 17 Aug 2004 10:25: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 i7HHP3Cb082480; Tue, 17 Aug 2004 10:25:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HHP2jn082474 for ; Tue, 17 Aug 2004 10:25:02 -0700 (PDT) (envelope-from sb0-0647ddf24c-johnl@iecc.com) Received: (qmail 24140 invoked from network); 17 Aug 2004 17:25:05 -0000 Received: (ofmipd 127.0.0.1); 17 Aug 2004 17:24:43 -0000 Date: 17 Aug 2004 13:25:05 -0400 Message-ID: From: "John R Levine" To: "Ryan Malayter" Cc: "Pete McNeil" , "Hallam-Baker, Phillip" , "ietf-mxcomp@imc.org" , "asrg@ietf.org" Subject: RE: [Asrg] REDIRECt to ASRG RE: Reputation systems In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02B04DF4@cliff.bai.org> References: <792DE28E91F6EA42B4663AE761C41C2A02B04DF4@cliff.bai.org> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > incoming spam. The XBL caught a lot more, but still less than 65% of the > spam. But this better performance cost nearly 30 false positives (each > of which could lead to a very irate customer for a business or > government organization). 30 out of how many? People I know who use the XBL and the CBL (the main source for the XBL) tell me that the fp rate they see is very low. This includes people at big companies who depend heavily on e-mail. > The numbers seem to indicate that IP-based blacklisting is essentially > useless without further content filtering. None even came close to > filtering 75% of spam, and some caused hundreds or thousands of false > positives. I hope that doesn't come as a surprise to anyone. The advantage of DNSBLs is that they are cheap to use and can reject mail very early in the SMTP process. If you can knock out 2/3 of the spam with DNSBLs, you can avoid 2/3 of the expensive content based scoring filters. > I wonder if the same poor performance will be the output of > domain-name-based reputation systems after MARID's work is widely > deployed. The only honest answer is that nobody knows. In the forseeable future, MARID verification will only be useful to whitelist domains known to be friendly. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 14:33: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 OAA05652 for ; Tue, 17 Aug 2004 14: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 i7HIA4I8085859; Tue, 17 Aug 2004 11:10: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 i7HIA4Yr085858; Tue, 17 Aug 2004 11:10:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIA3qd085847 for ; Tue, 17 Aug 2004 11:10:03 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 17 Aug 2004 11:14:01 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7HI9wXK010878 for ; Tue, 17 Aug 2004 11:09:58 -0700 (PDT) Received: from fenton-w2k01.cisco.com (dhcp-128-107-163-140.cisco.com [128.107.163.140]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7HIi8kZ014935 for ; Tue, 17 Aug 2004 11:44:11 -0700 Message-Id: <4.3.2.7.2.20040817105437.03093708@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Aug 2004 11:11:30 -0700 To: ietf-mxcomp@imc.org From: Jim Fenton Subject: But what about accreditation/reputation? 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:"1092768251.215064"; x:"432000"; a:"rsa-sha1"; b:"0:1295"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"i2Biu2JFHH+Q0s0JpPof9GKRsPJUGki0MLJ4REY2TwMU6AbMYeR2i8570FM97" "qHV/2nNZebK5yJ9BsT6SPWFf9FAZ6B2P/AxC3lf+M4Dp1LqxWKGc1j7xtUSmb" "MUUhk498iCNo5hNlZ0UD23/ATYpFLnyTgFni77dibr4wLgCmg="; c:"Date: Tue, 17 Aug 2004 11:11:30 -0700"; c:"From: Jim Fenton "; c:"Subject: But what about accreditation/reputation?" 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: I agree that the discussion on the merits/deficiencies of various accreditation services belongs elsewhere, but this prompts another question. Once there is at least some degree of trust in domain-level email source addresses, there will be a need for some way to evaluate those addresses. Otherwise spammers can just buy and use disposable domains (and advertise Sender-ID, of course). This is what Meng is getting at in his "aspen" document. I see a whole ecosystem of accreditation services (some new, some old) springing up once MARID (and similar mechanisms, e.g., MASS) get adopted. I expect they will have different business models and will use different criteria for rating the addresses. Some might require the posting of a bond, others might rate based on what other recipients of mail say (true reputation), and others might be based on criteria like how long the domain has been in existence. It would be good to have common mechanisms for accessing this accreditation data, so that the services can compete freely and recipients can easily use the service that is best for them. Does this make sense as a future work item for the (presumably rechartered) MARID WG? Or does this sound like a separate WG? As mentioned above, MASS will need the same thing. -Jim From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 15:43:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11135 for ; Tue, 17 Aug 2004 15:43:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJKO8K091977; Tue, 17 Aug 2004 12: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 i7HJKOkk091976; Tue, 17 Aug 2004 12:20:24 -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 i7HJKNrw091962 for ; Tue, 17 Aug 2004 12:20:23 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040817192020.KKTX19123.tomts20-srv.bellnexxia.net@ibmrkydk2ufvdd>; Tue, 17 Aug 2004 15:20:20 -0400 From: "John Glube" To: "'Meng Weng Wong'" , "'Chris Haynes'" Cc: "'IETF MARID WG'" Subject: RE: What Meng said Date: Tue, 17 Aug 2004 15:22:09 -0400 Message-ID: <011101c4848f$7d629920$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20040817142535.GG3243@dumbo.pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7HJKOrw091970 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit From: Meng Weng Wong Sent: August 17, 2004 10:26 AM >>On Mon, Aug 16, 2004 at 11:26:39AM +0100, Chris Haynes >>wrote: >>Please may I ask a brutally simple question. >>My question below applies only to those messages in which >>the domain of the MAIL-FROM is different from the domain of >>the PRA. Where, in the collection of drafts issued on >>Friday, does Sender-ID refer to the rejection of a message >>as a result of evaluating the record associated with its MAIL->>FROM domain?" >Sender ID as currently specified doesn't do that. >If people want the MAIL FROM to play a role in Sender ID, >they should say so. If they do not say so, the working >assumption is that nobody cares. >I personally think that if the PRA lookup returns "none" or >"unknown", MAIL FROM should be checked, and if that test returns >"fail" then the message should be rejected. >This is in line with the "unified SPF" model. >The converse is the scenario where a MAIL FROM pass is returned, >and a receiver arrives at a generally positive feeling about the >sender; that would allow EzMLM and similar MLMs to get their >mail through, and reduce the false positives that would occur on >a PRA check alone. My comments: * At present according to its site and related information filed with the IETF, MS is claiming an IPR in Sender-ID, proposes to file a defensive patent and is requesting software developers to sign a royalty free license. * We will not know whether MS will accommodate its required license to meet any expressed concerns of the open source community until August 23. * Based on this, the only workable presumption, given previous comments made to this list concerning the licensing issue, is that some open source mail software will not be able to accept the license and therefore will not be able to alter their software to be compatible with Sender-ID, as the protocol is presently on the table. The change that Meng is saying he would like to see in the protocol documents, which others have requested, brings with it a number of benefits: * It removes an apparent design flaw in Sender-ID by reducing the risk of false positives. This would seem to be a fundamental argument in support of Meng's position, given the mandate of this WG. As to the argument about mail forwarding, Meng has used the word "should" not "must" in his proposal. * It allows software developers within the open source community to design plug-ins for mailing software that support Sender-ID without having to adopt or support the PRA algorithm, simply relying on the SMTP mail from check and by adopting the plug ins available to support mail forwarding. This means the license request by MS becomes a non-issue, except for those in the open source community who wish to implement Submitter and support PRA at the data transmission stage. I simply point this out so that as requested by Harry Katz, MS can take this matter into consideration as it works on its final IPR/license proposal. * It means that senders are not compelled to publish an SPF record and a Sender-ID record. Nice, but not fundamental. * Most importantly, it strengthens the protocol from the receiver's perspective, particularly large mail box providers and large corporate network providers who are facing the greatest crush and cost in the ongoing war against spammers. Why? It means large mail providers can require PRA and SMTP mail from checks using Sender-ID and EHELO/HELO checks using CSV. This strengthens the receiver's hand, while further reducing the risk of false positives. What happens if this change is not made? SPF is not before this WG as a formal protocol. The approach put forward by Meng overcomes the problem which many organizations will face if Sender-ID does not include a formal SMTP mail from check in the absence of PRA at the data stage. Should they or should they not adopt and use a protocol, namely SPF which allows for an SMTP mail from check, so reducing the risk of false positives, but that has not been formally approved by the IETF. Without the requested change, organizations are put in a box. We want to follow the rules. However, by following the rules we adopt a protocol which according to one of the designers may result in an increased false positive rate. This is not in our interest. We can avoid the problem by implementing SPF and Sender-ID, but then we are not following the rules and this puts us into never, never land. * Design Perspective. The underlying reason for having syntax strings for each design is this allows each protocol to focus on one issue. In the case of Sender-ID this is PRA. By writing a design for Sender-ID which focuses on PRA and includes SMTP mail from this is a change in design perspective. The question becomes, does this change bring with it any negatives? Given PRA is a new model version of SMTP Mail From (Both SPF and Sender-ID break mail forwarding) I don't see any. Having said this, I am not a design, security or operational expert and there may be one or more actual reasons which require consideration. * Delay. By accommodating this request, will it further delay the process of getting Sender-ID out of the box? The design work has been done on running an SMTP mail from check. Draft protocols are readily available. Open source plug ins are available both for mail from and re-sent mail from. There is a very lively community available to provide support. * The merger of SPF with Caller-ID. Some are critical of this. What I do know is: * We are where we are; and * We have an opportunity to make the present proposal better, without any downside. As Margaret pointed out: "and more net happiness in the world is also a good thing :-). For all these reasons, I support Meng's request. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 16:05:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12132 for ; Tue, 17 Aug 2004 16:05:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJZDAh092852; Tue, 17 Aug 2004 12: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 i7HJZDGm092851; Tue, 17 Aug 2004 12:35:13 -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 i7HJZCgY092844 for ; Tue, 17 Aug 2004 12:35:12 -0700 (PDT) (envelope-from sb0-0647ddf24c-johnl@iecc.com) Received: (qmail 9865 invoked by uid 100); 17 Aug 2004 19:35:16 -0000 Date: 17 Aug 2004 19:35:16 -0000 Message-ID: <20040817193516.9864.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: But what about accreditation/reputation? In-Reply-To: <4.3.2.7.2.20040817105437.03093708@mira-sjc5-1.cisco.com> Organization: I.E.C.C., Trumansburg NY USA Cc: fenton@cisco.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >It would be good to have common mechanisms for accessing this >accreditation data, so that the services can compete freely and >recipients can easily use the service that is best for them. This is exactly what I've been hoping the ASRG IAR group would work on. Since there is very little existing reputation service practice beyond DNSBLs, it seems to me way too early to try to staandardize anything. What we need is experiments to see what works and what doesn't, you know, like in olden days. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com PS: If you're interested in IAR, see http://asrg.sp.am/subgroups/iar.shtml From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 16:05: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 QAA12155 for ; Tue, 17 Aug 2004 16:05: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 i7HJeTXr093135; Tue, 17 Aug 2004 12:40: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 i7HJeT8O093134; Tue, 17 Aug 2004 12:40:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJeTt5093127 for ; Tue, 17 Aug 2004 12:40: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 9FA7E41497 for ; Tue, 17 Aug 2004 12:40:31 -0700 (PDT) Subject: Mail Policy Records (MPR) From: Douglas Otis To: MARID Content-Type: multipart/mixed; boundary="=-JTRLaOFTAcWacIfUdXKP" Message-Id: <1092771630.19917.4.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 17 Aug 2004 12:40:30 -0700 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-JTRLaOFTAcWacIfUdXKP Content-Type: text/plain Content-Transfer-Encoding: 7bit I expressed concerns of the overhead for either SPF or Sender-ID and how this may affect mail use. Marshall asked if there was possibly a better solution this group should consider. Although this is a sensitive time, as Sender-ID nears submission for Last Call, I decided to submit this draft despite a potential for this being viewed as an attempt to derail progress. I offer this only to allow a technical comparison and as a response to Marshall's question. Although digital signatures are the proper approach, this draft accommodates a Mail Channel/Mailbox Domain relationship, being the basic mechanism used for both SPF and Sender-ID, but treats this as an exceptional case. The Mail Policy draft has been submitted as an I-D. The intent of this draft is to illustrate a method that ensures a single DNS lookup is required to discover mail policy. A lookup of the Mail Channel is also possible with a single DNS lookup. This scheme leverages information gained from the CSV authentication and allows applying policies for both MAIL FROM and From, (a feature needed in the current draft.) The use of the new APL RR is not essential, but offered as it uses a binary RR as a means for a smaller and more concise record for white-listing without requiring a TXT script and parser. The white-listing feature of SPF was seen as one of its greatest assets. Although this draft does not follow the path of least resistance with respect to transforming SMTP, it does establish a foundation to allow enforcement of policies with a goal directly aimed at abating abuse. Sender-ID does not offer an identity safely accredited. The EHLO domain forms the bedrock for identifying mail. By both authenticating this EHLO domain and ensuring this is visible to the user, the ability to spoof becomes greatly diminished. This draft extends this to include identifying the mail channel for exceptional cases, where restrictions on either the MAIL FROM or From is desired. This however only minimally impacts normal mail use. This scheme does not require parsing the RFC2822 headers and thus avoids the IPR being claimed by Microsoft. It also better protects the From and does not allow diversion of the check to a Resent-From header for institutions wishing to protect their From field. It also expects the further development of the BATV proposal that prevents common spammer techniques not addressed by Sender-ID. This draft also allows this technique to be addressed by way of MAIL FROM/Mail Channel restrictions as well. The return-path is area overlooked by Sender-ID. -Doug --=-JTRLaOFTAcWacIfUdXKP Content-Disposition: attachment; filename=draft-otis-marid-mpr-00.txt Content-Type: text/plain; name=draft-otis-marid-mpr-00.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MARID D. Otis Internet-Draft Mail Abuse Prevention System Expires: February 8, 2005 August 10, 2004 Mail Policy Records (MPR) draft-otis-marid-mpr-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 8, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract For domains sending or receiving mail, there is often a desire to publish policies indicating types of mail sent or accepted, and to specify the collateral Mail Channel to assist in these policies. The challenge is to allow the recipient a deterministic means for obtaining this information, while not creating additional burdens for normal mail use. Need for a domain based mail policy facility has become pronounced as many institutions find their mailboxes forged to usurp and thus damage their trust relationships. For these exigent situations, it Otis Expires February 8, 2005 [Page 1] Internet-Draft Mail-PR August 2004 could be advantageous, as example, to request refusal of mail where the [RFC2822] From of Mailbox Domain does not indicate being from the prescribed Mail Channel. These policies may include other prescriptions, such as all outbound mail is digitally signed. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Policy Records . . . . . . . . . . . . . . . . . . . . . . . 4 5. Mail Policy Resource Record . . . . . . . . . . . . . . . . 6 6. Mail Channel Name List . . . . . . . . . . . . . . . . . . . 7 7. Mail Channel Address List . . . . . . . . . . . . . . . . . 7 8. Domain administrator advice . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1 Normative References . . . . . . . . . . . . . . . . . . . 8 10.2 Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 Otis Expires February 8, 2005 [Page 2] Internet-Draft Mail-PR August 2004 1. Overview Terminology: Terminology conforms to [ID-mail-arch]. Terms used in the context of this document: Mail Channel- a prescribed set of Mail Transfer Agents identified by either a list of HELO/EHLO domains or IP addresses in CIDR notation. Mailbox Domain- the portion of the mailbox address on the right hand side of the "@" symbol. Discussion: The venue for discussing this proposal is the IETF MARID working group. [1] 2. Introduction With the DNS records proposed, domains MAY publish a Mail Policy Record (MPR) indicating policies for the use of that domain name, and possibly prescribing the Mail Channel Name List (MCNL) or the Mail Channel Address List (MCAL) records, for lists of associated HELO/ EHLO names or client IP addresses to assist assessments by the mail recipient. Mail Channel prescriptions for Mailbox Domain assessments assume administrative control over shared access for such assertions to produce a desirable result. As such, Mail Channel prescriptions are limited to situations where access to the Mail Channel can be assured as a means to protect a trust relationship with the sending domain and the recipients. Prescribing the Mail Channel for Mailbox Domains is not appropriate with many configurations and uses, as it could invite the problem a Mail Channel prescription attempts to curtail. Domains wishing to assert limited use of their Mailbox Domain, to assist recipients detect nonconforming mail, express this by publishing a DNS Mail Policy record. There is a DNS resource record used to indicate mail polices, and two types of records to prescribe the Mail Channel either by HELO/EHLO names or IP addresses. The Mail Policy Record (MPR) indicates the sending and receiving policies. The Mail Channel Address List (MCAL) enables an exception or white-listing that may be applied when processing forwarded mail. The Mail Channel Name List (MCNL) may be applied to assert the limited use of [RFC2821] or [RFC2822] Mailbox Domains. 3. Background A concise means to prescribe the Mail Channel is needed to establish a determinate burden for the recipient. This method should also Otis Expires February 8, 2005 [Page 3] Internet-Draft Mail-PR August 2004 naturally delegate to other domains without requiring follow-on queries. When considering possible schemes available, there are two related methodologies which enable such a solution. These two methods are defined within Client SMTP Validation (CSV) [ID-Marid-CSV] and Bounce Address Tag Validation [ID-BATV]. By listing authenticated and authorized HELO/EHLO domains to prescribe the Mail Channel, there is no need to resolve to an address. In the case of a message being forwarded, verifying the signature of the local-part of the [RFC2821] MAIL FROM as provided by Bounce Address Tag Validation [ID-BATV] removes the need to decipher the proximal [RFC2822] header. As an alternative to signature checking, the forwarding domain may publish its white-list using a CIDR based record list. An important aspect found combining these methods, is that information is obtained from a deterministic single query for each instance. The overhead for such is then confined to this single DNS lookup and found within a single DNS answer. This becomes important when considering the impact on the DNS cache and the relative amount of UDP traffic imposed upon the network. These deterministic aspects become attractive from the aspect of relative cost, security and network integrity. It should also be noted [RFC2822] headers are often spoofed and can not safely determine the message's origin. There is no means to determine the integrity of the Mail Channel and generally should be assumed insecure. 4. Policy Records There are three DNS records defined by this document. Each of these records are obtained by prepending the "_mp._smtp." sub-domains to the Mailbox Domain reference. The Mail Policy record types delineate their content. Rather than using a TXT RR with notations defined by Augmented BNF for Syntax Specifications (ABNF) [RFC2234] for later processing with a requisite parser, the Mail Policy Record (MPR) is defined as a single encoded IPv4 address record, the list of HELO/ EHLO domain names (MCNL) is defined using PTR records, and the address list of the Mail Channel (MCAL) is defined using APL records defined in A DNS RR Type for Lists of Address Prefixes [RFC3123]. If there is a Mail Channel for the [RFC2822] From Mailbox Domain, then forwarding by the recipient may be allowed to then rely upon [RFC2821] MAIL FROM local part signatures as defined in Bounce Address Tag Validation [ID-BATV] or upon specific forwarding domains having been white-listed by the receiving MTA of the forwarded mail. There are two fields that may reference specific policies, the [RFC2821] MAIL FROM, and the first Mailbox Domain in the [RFC2822] From. The process of deciding on the policies indicated by these two Otis Expires February 8, 2005 [Page 4] Internet-Draft Mail-PR August 2004 fields requires performing a series of conceptually discrete steps: Mailbox Domain Policy: What are the requested policies for the Mailbox Domain in question? This is obtained by performing an MPR, an IPv4 address record, lookup and analyzing the lower 24 bits of the returned address. Permitted Mailbox Domain Channel: Should mail be accepted, if the Mailbox Domain restricts allowable HELO/EHLO domain names? Acceptance is then determined by performing a MCNL PTR record lookup and finding a match with the current CSV HELO/EHLO domain name. Domain names within the MCNL are treated as being wildcarded to allow matches with all sub-domains. If the mail is not accepted and no exceptions are possible, then MTAs performing the Mail Channel check as part of receiving a message SHOULD reject that message with either "550 MAIL FROM Channel Failure." or "550 From Channel Failure." depending upon the field causing the rejection. There may be exceptions made with forwarded mail. Alternative rules may apply when restrictions are placed upon the Mailbox Domain and the Mail Channel fail in the case where the mail has been forwarded. Permitted Channel Failure: Should the mail be accepted, if the Mailbox Domain restricts allowable HELO/EHLO domain names, but the name does not match? Acceptance is then determined by the use of BATV and Return Path Validation when permitted by Mailbox Domain policy. If the BATV Return Path Validation is attempted but fails, " BATV check unsuccessful." should be appended to the error message sent upon rejection. Return Path Validation and Permitted Channel Failture: Should the mail be accepted, if the Mailbox Domain restricts allowable HELO/EHLO domain names, but the name does not match, and there is no Return Path Validation? Acceptance may also be determined by a rule established by the domain administrator of the receiving MTA that then allows preforming an MCAL APL lookup for predefined domains. Should the current IP address of the remote client then be included within the list, the mail is accepted. In other words, is the sender white-listed? The rule of Otis Expires February 8, 2005 [Page 5] Internet-Draft Mail-PR August 2004 allowable Mailbox Domains may be categorized based upon the mail recipient. 5. Mail Policy Resource Record The Mail Policy RR is an encoded A record with bit values used to indicate policy requests. _mp._smtp.domain IN A 127... The address octets are treated independently. The most significant octet is always the value of 127 decimal; see [RFC3330]. The Version octet defines the revision level of this mechanism starting at 1. The Send and Request octets comprise a summation of values used to provide various indications. +--------------+----------------------------------------------------+ | Send Bit | Meaning | | Value | | +--------------+----------------------------------------------------+ | 1 | BATV: This domain uses public key BATV for all | | | sent messages. | | 2 | Signed: This domain uses public key digital | | | signatures for all sent messages. | | 4 | WhiteList: This domain provides a comprehensive | | | MCAL list of all outbound SMTP clients. | | - | Other bit values are reserved for expansion and | | | must be set to zero. | +--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+ | Req Bit | Meaning | | Value | | +--------------+----------------------------------------------------+ | 1 | MailFrom: The Mail Channel prescribed in the MCNL | | | RR should be the exclusive source of this MailBox | | | Domain for the MAIL FROM parameter. | | 2 | From: The Mail Channel prescribed in MCNL RR | | | should be the exclusive source of this MailBox | | | Domain for the From header. | | 4 | Ignore BATV: Return Path Validation by BATV should | | | not be used for acceptance when a Mail Channel | | | check fails. | | - | Other bit values are reserved for expansion and | | | must be set to zero. | +--------------+----------------------------------------------------+ Otis Expires February 8, 2005 [Page 6] Internet-Draft Mail-PR August 2004 6. Mail Channel Name List The Mail Channel Name List RR is comprised of a series of PTR records. As example: _mp.smtp.domain. IN PTR our-domain.com _mp.smtp.domain. IN PTR our-access-provider.com The target of the PTR record should be treated as a wildcarded record when doing a comparison with the HELO/EHLO domain presented by the CSV process. Taking the example our-domain.com would then match with the HELO/EHLO domain mx01.sjc.our-domain.com. 7. Mail Channel Address List The Mail Channel Address List RR is comprised of a series of APL records. As example: _mp.smtp.domain. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28 The use of the address negation "!" is to exclude a range of addresses from a larger list. These lists of CIDR blocks are used to enable the white-listing of this domain for the purposes of selectively enabling this domain to forward mail. If the WhiteList value is present in the Mail Policy record, then it can be assumed to be representative of all mail sent by this domain with respect to any channel restrictions. 8. Domain administrator advice The use of the MCAL as a white-listing tool may be extended to other uses. The lack of a WhiteList value in the Send field of the MPR is intended to indicate the list is not comprehensive and only suitable for qualifying forwarded mail. In this case, other types of mail may be sent from servers not included in this list when the WhiteList value is not asserted. Currently the DNS structures within the UDP packet has a limit of 512 octets. Replies requiring more than 512 octets may create UDP fragmentation and, depending upon the connection and handling, in addition to a higher rate of packet loss, may also cause truncated or partial replies. Furthermore, delivery and resolver handling of truncated and partial responses varies, leading to additional delays and queries. Domain administrators are strongly advised to keep DNS replies below 512 octets for these reasons. With a complete response to an MCAL or MCNL query, SMTP server is able to implement the policies being requested. To help ensure Otis Expires February 8, 2005 [Page 7] Internet-Draft Mail-PR August 2004 complete and coherent answers are obtained from cached records, TTL values of the MPR, MCAL and MCNL records should be the same. Beware some DNS server implementation consider the SOA TTL as a default rather than a minimum. 9. Security Considerations The HELO/EHLO domain contained in the most recently added [RFC2822] Received headers should be visible to the user of the MUA to guard against address spoofing. Successful CSV authentication should append an "*" following the HELO/EHLO domain name in the Received header. A message being within the prescribed Mail Channel should also be visible to the user of the MUA to help guard against the use of sub-domains. If a domain applies mail policies to a domain, then all sub-domains used for mail must also implement mail policies. The nature of the security requirements for Mail Policies are significantly different from typical, "strong" methods required for most Internet security functions. The proposal also relies on security of the underlying IP network and on the integrity of DNS data. It performs a basic authentication of the mail, based on domain name registration of the client IP Address. There is no way a site can keep its hosts from being referenced as servers. This could lead to denial of service. DNS spoofers can supply false addresses. To decrease the success rate for this type of attack, the source port for DNS queries appearing on the Internet should be from random ports. Because this vulnerability exists already with names and addresses, this is not a new vulnerability, merely a slightly extended one. However, as Mail Policy records are used in an authorization context, the DNS servers can be protected by DNSSEC [RFC3008] should this vulnerability become intractable. The proposal relies on the integrity and authenticity of DNS data. 10. References 10.1 Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. Otis Expires February 8, 2005 [Page 8] Internet-Draft Mail-PR August 2004 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2234] Crocker, D., "Augmented BNF for Syntax Specifications", RFC 2234, November 1997. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000. [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes", RFC 3123, June 2001. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC3330] "Special-Use IPv4 Addresses", RFC 3330, September 2002. 10.2 Informative References [ID-BATV] Crocker, D., "Bounce Address Tag Validation (BATV)", August 2004. [ID-CSVCSA] Otis, D., Crocker, D. and J. Leslie, "sending SMTP client Authorization (CSA)", June 2004. [ID-Marid-CSV] Crocker, D., Otis, D. and J. Leslie, "Client SMTP Validation (CSV)", July 2004. Otis Expires February 8, 2005 [Page 9] Internet-Draft Mail-PR August 2004 [ID-Marid-CSVDNA] Leslie, J., Crocker, D. and D. Otis, "Domain Name Accreditation (DNA)", July 2004. [ID-mail-arch] Crocker, D., "Internet Mail Architecture", May 2004. URIs [1] Author's Address Douglas Otis Mail Abuse Prevention System 1737 North First Street, Suite 680 San Jose, CA 94043 USA Phone: +1.408.453.6277 EMail: dotis@mail-abuse.org Appendix A. Acknowledgements John Leslie provided helpful editorial comments. Otis Expires February 8, 2005 [Page 10] Internet-Draft Mail-PR August 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Otis Expires February 8, 2005 [Page 11] --=-JTRLaOFTAcWacIfUdXKP-- From owner-ietf-mxcomp@mail.imc.org Tue Aug 17 17:41: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 RAA16412 for ; Tue, 17 Aug 2004 17:41: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 i7HLFFvu099051; Tue, 17 Aug 2004 14:15: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 i7HLFFr4099050; Tue, 17 Aug 2004 14:15:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HLFD3J099044 for ; Tue, 17 Aug 2004 14:15:14 -0700 (PDT) (envelope-from roy+dated+1095369310.e2692c@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7HLGBiT076753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Aug 2004 21:16:16 GMT (envelope-from roy+dated+1095369310.e2692c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7HLFBcw069292 for ; Tue, 17 Aug 2004 22:15:11 +0100 (BST) (envelope-from roy+dated+1095369310.e2692c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7HLFBOT069291 for ietf-mxcomp@imc.org; Tue, 17 Aug 2004 22:15:11 +0100 (BST) (envelope-from roy+dated+1095369310.e2692c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 17 Aug 2004 22:15:09 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16674.30044.701310.335888@giles.gnomon.org.uk> Date: Tue, 17 Aug 2004 22:15:08 +0100 To: Roy Badami Cc: Meng Weng Wong , Chris Haynes , IETF MARID WG Subject: Checking MAIL FROM (was: What Meng said) In-Reply-To: <16674.9798.699170.553196@giles.gnomon.org.uk> References: <8D4A745B-EBB0-11D8-97B2-000A95B3BA44@hxr.us> <20040813065604.GI28401@dumbo.pobox.com> <02c401c4837b$88cf7590$0200000a@ringo> <20040817142535.GG3243@dumbo.pobox.com> <16674.9798.699170.553196@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Roy" == Roy Badami writes: Roy> Let's get Sender ID out the door, and then we can think about Roy> validating other identities. It would be relatively easy to Roy> add other identities to Sender ID in a backward-compatible Roy> way at a later date, particularly given the new versioning Roy> mechanism. Actually, the one change that might be worth considering for Sender ID is to add an identity macro which always expands to the string 'pra'. This will make it less painful to produce backward compatible extensions later. (Sorry, I know Unified SPF has something like this but I can't remember what it's called.) -roy From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 00:30: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 AAA09163 for ; Wed, 18 Aug 2004 00: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 i7I446sG036137; Tue, 17 Aug 2004 21:04:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I4465P036136; Tue, 17 Aug 2004 21:04: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 i7I4450D036120 for ; Tue, 17 Aug 2004 21:04: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 1BxHgB-00040X-Oj for ietf-mxcomp@imc.org; Tue, 17 Aug 2004 23:04:09 -0500 To: "IETF MARID WG" References: <792DE28E91F6EA42B4663AE761C41C2A02B04DF4@cliff.bai.org> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 17 Aug 2004 23:04:03 -0500 In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02B04DF4@cliff.bai.org> (Ryan Malayter's message of "Tue, 17 Aug 2004 11:51:59 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: [Asrg] REDIRECt to ASRG RE: Reputation systems 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 <792DE28E91F6EA42B4663AE761C41C2A02B04DF4@cliff.bai.org> "Ryan Malayter" writes: > [Pete McNeil] >> Here is a link to the analysis: >> >> http://www2.spamchk.com/public.html > > This is very useful, and most of what I was looking for, but I'd still > like to see an analysis done with hand-filtered email. I agree, this is very useful information. I found it interesting that, despite several comments to this list, the SpamCop DNSBL came out looking very good. It blocked more spam than any other DNSBL and yet its false positive rate isn't a huge amount worse than the highly regarded CBL DNSBL. The SpamCop DNSBL has been around for a long time and was one of the first automated DNSBLs. Its algorithm has changed a lot and the size of the reporting base for SpamCop has increased greatly. I wonder how much of the bad reputation is due to old data/experiences. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 01:13: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 BAA11152 for ; Wed, 18 Aug 2004 01:13: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 i7I4qvoG043475; Tue, 17 Aug 2004 21:52: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 i7I4qvJi043474; Tue, 17 Aug 2004 21:52:57 -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 i7I4qvDs043468 for ; Tue, 17 Aug 2004 21:52:57 -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 i7I4mwve007811 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 17 Aug 2004 21:48:59 -0700 Received: from [192.168.4.153] ([66.153.100.53]) (authenticated bits=0) by righton.sendmail.com (8.13.1.Beta1/8.13.1.Beta1) with ESMTP id i7I4mtIR048364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Aug 2004 21:48:57 -0700 (PDT) Message-ID: <4122901D.3030708@sendmail.com> Date: Tue, 17 Aug 2004 19:09:17 -0400 From: Rand Wacker User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Fenton CC: ietf-mxcomp@imc.org Subject: Re: But what about accreditation/reputation? References: <4.3.2.7.2.20040817105437.03093708@mira-sjc5-1.cisco.com> In-Reply-To: <4.3.2.7.2.20040817105437.03093708@mira-sjc5-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jim Fenton wrote: > It would be good to have common mechanisms for accessing this accreditation data, so that the services can compete freely and recipients can easily use the service that is best for them. "Yes" > Does this make sense as a future work item for the (presumably rechartered) MARID WG? Or does this sound like a separate WG? As mentioned above, MASS will need the same thing. "No, Yes" (please lets not do it here) FWIW, a quick survey of the nascent accreditation/reputation service market (bonded sender/senderbase, cloudmark rating, verisign's upcoming accreditation list, numerous open community projects) reveals a strong disposition of using DNSL-like protocols. Unfortunately, while the query mechanism is standard, the query format and result are not necessarily so. -Rand From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 03:35: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 DAA15122 for ; Wed, 18 Aug 2004 03: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 i7I7AKWK086859; Wed, 18 Aug 2004 00:10:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I7AKoN086858; Wed, 18 Aug 2004 00:10:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I7AK6s086850 for ; Wed, 18 Aug 2004 00:10:20 -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 i7I79Aj16675; Wed, 18 Aug 2004 00:09:10 -0700 Date: Wed, 18 Aug 2004 00:09:05 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1838715938.20040818000905@brandenburg.com> To: Rand Wacker CC: Jim Fenton , ietf-mxcomp@imc.org Subject: Re: But what about accreditation/reputation? In-Reply-To: <4122901D.3030708@sendmail.com> References: <4.3.2.7.2.20040817105437.03093708@mira-sjc5-1.cisco.com> <4122901D.3030708@sendmail.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 Rand, RW> disposition of using DNSL-like protocols. Unfortunately, while the RW> query mechanism is standard, the query format and result are not RW> necessarily so. sure would be nice to get some feedback on CSV's DNA specification... d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 06: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 GAA26552 for ; Wed, 18 Aug 2004 06:58:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IAZ3R5087555; Wed, 18 Aug 2004 03:35:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IAZ38M087554; Wed, 18 Aug 2004 03:35:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IAZ29S087532 for ; Wed, 18 Aug 2004 03:35:03 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1BxNmD-000M9v-00; Wed, 18 Aug 2004 11:34:41 +0100 Message-ID: <024301c4850e$a4eae3b0$0200000a@ringo> From: "Chris Haynes" To: "Andrew Newton" Cc: "IETF MARID WG" Subject: Point of Order: Incomplete, flawed response to MARID WG Charter Date: Wed, 18 Aug 2004 11:32:14 +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 Point of order ====== May I humbly raise a point of order to the Chair concerning the projected output of the MARID WG? The WG is chartered to produce solutions which "confirm that peer MTA's actions are authorized by specific domains or networks." I also note the WG's intention to proceed to 'last call' on Sender-ID within a few days. Is it in order for the WG to proceed to last call with a solution which: - addresses only half the problem space and - increases the number of unauthorized, frequently virus-carrying, messages on the Internet? Chris Haynes ~~~~~~~~~~~~~~~~~~~- Basis and explanation of the Point of Order: ====== Within the scope of SMTP there are two distinct message types: For brevity I'll term them 'Original' and 'Bounce'. With Sender-ID the WG has produced a method for Original messages to be authorized. The WG has not yet produced a method for Bounce messages to be authorized. It has therefore not yet provided a solution for the second half of the problem space. Furthermore... If the Sender-ID authorisation test fails (core-03, section 5.3) the receiving MTA will return a '550' response to the client MTA, containing further information about the rejection. The client will, in most cases, generate and send a Bounce message containing this rejection information, and it is common practice to include a copy of the Original message within that Bounce. Therefore, Sender-ID _requires_ MTAs of previous good repute to generate and send Bounce messages which: - Are themselves wholly unauthorised, - Use information from an Original which is _known_ to be unauthorized, - May be sent to a destination wholly unrelated to the sender of the Original, - May contain malicious content copied from that Original unauthorized message. In essence... Sender-ID requires a peer MTA to perform the act of sending a message when it is _known_ that no domain or network has authorized that action. This is in clear conflict with the WG's own Charter. ~~~~~~~~~~~~~~~~~~~- PR effect of the current proposal: ====== Just to illustrate the weakness of the current WG proposal, I postulate some press headlines which, in my opinion, would be technologically accurate: "'s anti-spam scheme backfires - leads to more virus-carrying messages on Internet" "IETF chooses 's patented, incomplete, flawed approach - ignores proven solution offered by Open Source community, " " makes another security blunder - and this time takes the IETF with it!" Maybe this last headline is not entirely accurate. I'm not sure that promoting the (avoidable) propagation of viruses is strictly a 'security' issue, but that would not stop the press using such an eye-catching 'angle'. ~~~~~~~~~~~~~~~~~~~-- From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 09:56: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 JAA06086 for ; Wed, 18 Aug 2004 09:56: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 i7IDR6nL057928; Wed, 18 Aug 2004 06:27:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IDR6iZ057927; Wed, 18 Aug 2004 06:27:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IDR6Bc057920 for ; Wed, 18 Aug 2004 06:27:06 -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, 18 Aug 2004 09:27:02 -0400 id 00213500.41235928.00003CFC In-Reply-To: <024301c4850e$a4eae3b0$0200000a@ringo> References: <024301c4850e$a4eae3b0$0200000a@ringo> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48D7E736-F11A-11D8-B4ED-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: "IETF MARID WG" From: Andrew Newton Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Charter Date: Wed, 18 Aug 2004 09:27:00 -0400 To: "Chris Haynes" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 18, 2004, at 6:32 AM, Chris Haynes wrote: > May I humbly raise a point of order to the Chair concerning the > projected output > of the MARID WG? I'm not sure there is much humility in raising a point of order premised on your opinion of the technical proposal and not on the process for how this group is conducting its work. Or perhaps you and I have a different idea for the meaning of point of order. You are certainly free to express your technical opinion regarding Sender ID, but let's not start using process issues to win technical arguments. BTW, your technical objections to Sender ID are noted. -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 10:01:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06464 for ; Wed, 18 Aug 2004 10:01:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IDcnCE060693; Wed, 18 Aug 2004 06:38: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 i7IDcnrW060692; Wed, 18 Aug 2004 06:38:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp2g.bellsouth.com (aismtp2g.bellsouth.com [139.76.165.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IDcmRS060673 for ; Wed, 18 Aug 2004 06:38:49 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp2g.bellsouth.com with ESMTP; Wed, 18 Aug 2004 09:38:40 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Wed, 18 Aug 2004 08:37:43 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB904748B7D@bremocog-55> Thread-Topic: Point of Order: Incomplete, flawed response to MARID WG Charter Thread-Index: AcSFKA9SVCaEtK+XSEGXFUdjTCYpmwAADdxQ From: "Sauer, Damon" To: "Andrew Newton" , "Chris Haynes" Cc: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IDcnRS060687 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Please read the objection carefully. The technical description of the issue is wholly flawed. Regards, Damon Sauer -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Andrew Newton Sent: Wednesday, August 18, 2004 9:27 AM To: Chris Haynes Cc: IETF MARID WG Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Charter On Aug 18, 2004, at 6:32 AM, Chris Haynes wrote: > May I humbly raise a point of order to the Chair concerning the > projected output > of the MARID WG? I'm not sure there is much humility in raising a point of order premised on your opinion of the technical proposal and not on the process for how this group is conducting its work. Or perhaps you and I have a different idea for the meaning of point of order. You are certainly free to express your technical opinion regarding Sender ID, but let's not start using process issues to win technical arguments. BTW, your technical objections to Sender ID are noted. -andy ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 10:41: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 KAA10297 for ; Wed, 18 Aug 2004 10:41: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 i7IEG8fa067448; Wed, 18 Aug 2004 07:16:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IEG75v067447; Wed, 18 Aug 2004 07:16:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IEG7C8067431 for ; Wed, 18 Aug 2004 07:16:07 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7IEFsa1005327; Wed, 18 Aug 2004 07:15:55 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 07:15:54 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Chris Haynes'" , Andrew Newton Cc: IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Wed, 18 Aug 2004 07:15:52 -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: > Is it in order for the WG to proceed to last call with a > solution which: > - addresses only half the problem space and > - increases the number of unauthorized, frequently > virus-carrying, messages > on the Internet? By longstanding IETF precedent a charter only states the problems that a WG MAY solve. There is no requirement that the eventual solution MUST meet all the criteria that might be claimed to be in the scope of the charter. In the case of bounces Jim Lyons proposed a scheme that allows a party acting on their own to eliminate fake bounces without requiring any other party to adopt the standard. Perhaps this could be written up as informational so everything was on the table. > Just to illustrate the weakness of the current WG proposal, I > postulate some > press headlines which, in my opinion, would be > technologically accurate: They would not be technically accurate in my opinion. From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 10:54: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 KAA11067 for ; Wed, 18 Aug 2004 10:54: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 i7IEOhid068707; Wed, 18 Aug 2004 07:24:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IEOhhW068706; Wed, 18 Aug 2004 07:24:43 -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 i7IEOgg0068692 for ; Wed, 18 Aug 2004 07:24:42 -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 i7IEOQMD018424 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 Aug 2004 10:24:34 -0400 Date: Wed, 18 Aug 2004 10:24:26 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Andrew Newton cc: Chris Haynes , IETF MARID WG Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Charter In-Reply-To: <48D7E736-F11A-11D8-B4ED-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: A point of order is a process check. The process is not supposed to move forward until the technical issues are solved. If the technical issues aren't solved, then the process shouldn't move forward until they are. So, a technical opinion that the technical problems aren't solved can certainly form the basis for a process question. I submit that your next step as working group chair is to obtain a technical consensus on the question raised by Mr. Haynes. If he is right, then the process shouldn't move forward yet. However, I'd say he has raised a good point. Though, I'd say my 9 or 10 points are also significant show-stopper problems. --Dean On Wed, 18 Aug 2004, Andrew Newton wrote: > > > On Aug 18, 2004, at 6:32 AM, Chris Haynes wrote: > > > May I humbly raise a point of order to the Chair concerning the > > projected output > > of the MARID WG? > > I'm not sure there is much humility in raising a point of order > premised on your opinion of the technical proposal and not on the > process for how this group is conducting its work. > > Or perhaps you and I have a different idea for the meaning of point of > order. > > You are certainly free to express your technical opinion regarding > Sender ID, but let's not start using process issues to win technical > arguments. > > BTW, your technical objections to Sender ID are noted. > > -andy > > From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 11:14: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 LAA12500 for ; Wed, 18 Aug 2004 11:14: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 i7IEpUJH072783; Wed, 18 Aug 2004 07:51: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 i7IEpUR6072782; Wed, 18 Aug 2004 07:51:30 -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 i7IEpThf072775 for ; Wed, 18 Aug 2004 07:51:29 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42047) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp (Exim 4.34) id 1BxRmf-0000Ri-BM (return-path fanf2@hermes.cam.ac.uk) for ietf-mxcomp@imc.org; Wed, 18 Aug 2004 15:51:25 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BxRme-0005Dx-OK; Wed, 18 Aug 2004 15:51:24 +0100 Date: Wed, 18 Aug 2004 15:51:24 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 18 Aug 2004, Hallam-Baker, Phillip wrote: > > In the case of bounces Jim Lyons proposed a scheme that allows a party > acting on their own to eliminate fake bounces without requiring > any other party to adopt the standard. > > Perhaps this could be written up as informational so everything was > on the table. This is being done. Dave Crocker is fleshing out his Bounce Address Tag Validation draft, and various people have or are working on implementations of the idea. 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 Wed Aug 18 11: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 LAA13624 for ; Wed, 18 Aug 2004 11: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 i7IF5uFV074859; Wed, 18 Aug 2004 08:05: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 i7IF5uko074858; Wed, 18 Aug 2004 08:05:56 -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 i7IF5tZW074728 for ; Wed, 18 Aug 2004 08:05:55 -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 i7IF4qbZ010652; Wed, 18 Aug 2004 08:04:52 -0700 In-Reply-To: <024301c4850e$a4eae3b0$0200000a@ringo> References: <024301c4850e$a4eae3b0$0200000a@ringo> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "IETF MARID WG" , "Andrew Newton" From: Marshall Rose Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Charter Date: Wed, 18 Aug 2004 08:04:49 -0700 To: "Chris Haynes" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 18, 2004, at 03:32, Chris Haynes wrote: > May I humbly raise a point of order to the Chair concerning the > projected output > of the MARID WG? in brief: no. there are no points of order in the ietf process. there is no roberts rules of order. there are no senate rules of filibuster. i could go on, but people familiar with the ietf process, should have already gotten the point. if you have specific technical criticisms as to the document, make them in a concise and clear fashion. you may continue to do so until the duration of the working group last call when the chairs will call for consensus. if you are unhappy with this process, then you should appeal directly to the AD, the IESG, the IAB, etc., as put forth in the documents that describe the ietf process. /mtr From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 11:49: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 LAA15760 for ; Wed, 18 Aug 2004 11:49: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 i7IFJtfi077054; Wed, 18 Aug 2004 08:19: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 i7IFJtAt077053; Wed, 18 Aug 2004 08:19:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IFJs0v077047 for ; Wed, 18 Aug 2004 08:19:54 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7IFJoV1027453; Wed, 18 Aug 2004 08:19:51 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 08:19:50 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , Andrew Newton Cc: Chris Haynes , IETF MARID WG Subject: Not a point of order RE: Point of Order: Incomplete, flawed respo nse to MARID WG Charter Date: Wed, 18 Aug 2004 08:19: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: Dean, In the first place a point of order under Roberts Rules is not a point of order unless accepted by the chair. In the second place it is not a point of order at all. A point of order relates purely to procedural items. This is a point of information, which is a move in a debate. In the third place there are no rules of order here. The IETF process does not use Roberts rules or recognize points of order. If you want to raise a point of order there has to first be rules of order on which a point may be raised. Chris can raise the issue in last call. And then the chairs decide on what the consensus of the group is and write a little note to answer the various objections raised. Phill > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Dean Anderson > Sent: Wednesday, August 18, 2004 10:24 AM > To: Andrew Newton > Cc: Chris Haynes; IETF MARID WG > Subject: Re: Point of Order: Incomplete, flawed response to MARID WG > Charter > > > > A point of order is a process check. The process is not > supposed to move > forward until the technical issues are solved. If the technical issues > aren't solved, then the process shouldn't move forward until > they are. > So, a technical opinion that the technical problems aren't solved can > certainly form the basis for a process question. > > I submit that your next step as working group chair is to obtain a > technical consensus on the question raised by Mr. Haynes. If > he is right, > then the process shouldn't move forward yet. > > However, I'd say he has raised a good point. Though, I'd say > my 9 or 10 > points are also significant show-stopper problems. > > --Dean > > On Wed, 18 Aug 2004, Andrew Newton wrote: > > > > > > > On Aug 18, 2004, at 6:32 AM, Chris Haynes wrote: > > > > > May I humbly raise a point of order to the Chair concerning the > > > projected output > > > of the MARID WG? > > > > I'm not sure there is much humility in raising a point of order > > premised on your opinion of the technical proposal and not on the > > process for how this group is conducting its work. > > > > Or perhaps you and I have a different idea for the meaning > of point of > > order. > > > > You are certainly free to express your technical opinion regarding > > Sender ID, but let's not start using process issues to win > technical > > arguments. > > > > BTW, your technical objections to Sender ID are noted. > > > > -andy > > > > > From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 11:50: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 LAA15782 for ; Wed, 18 Aug 2004 11:50: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 i7IFJVEI076987; Wed, 18 Aug 2004 08: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 i7IFJVuO076986; Wed, 18 Aug 2004 08:19:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IFJVIP076980 for ; Wed, 18 Aug 2004 08:19:31 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7IFJPEZ019425 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 Aug 2004 11:19:25 -0400 Date: Wed, 18 Aug 2004 11:19:25 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: "'Chris Haynes'" , Andrew Newton , IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter 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, 18 Aug 2004, Hallam-Baker, Phillip wrote: > > Is it in order for the WG to proceed to last call with a > > solution which: > > - addresses only half the problem space and > > - increases the number of unauthorized, frequently > > virus-carrying, messages > > on the Internet? > > By longstanding IETF precedent a charter only states the problems that > a WG MAY solve. There is no requirement that the eventual solution > MUST meet all the criteria that might be claimed to be in the scope > of the charter. The IETF has a longstanding precedent of having running code that demonstrates the validity of the solution. From the Mission Statement: http://www.ietf.org/internet-drafts/draft-alvestrand-ietf-mission-02.txt Anyway, I thought that someone was going to go off and test SPF (hopefully in a realistically hostile environment). It seems rather premature to move before that is complete. Or has that test been abandoned? > In the case of bounces Jim Lyons proposed a scheme that allows a party > acting on their own to eliminate fake bounces without requiring > any other party to adopt the standard. I didn't see Lyons proposal. But how can you tell a fake bounce from a real bounce without some reference to the _actual_ original message and the _actual_ state of the mail system? This is a relevant point that I'm discussing with attorneys in another issue. > Perhaps this could be written up as informational so everything was > on the table. > > > Just to illustrate the weakness of the current WG proposal, I > > postulate some > > press headlines which, in my opinion, would be > > technologically accurate: > > They would not be technically accurate in my opinion. Well, the press to date certainly hasn't been very accurate. I read an article in one of the linux magazines (linux journal, I think) that was _way_ overstating what SPF would do. --Dean From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 11:53: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 LAA16051 for ; Wed, 18 Aug 2004 11:53: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 i7IFPcdP077816; Wed, 18 Aug 2004 08:25: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 i7IFPc8E077815; Wed, 18 Aug 2004 08:25:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IFPbEP077808 for ; Wed, 18 Aug 2004 08:25:37 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7IFPX4V028006; Wed, 18 Aug 2004 08:25:33 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 08:25:33 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: "'Chris Haynes'" , Andrew Newton , IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Wed, 18 Aug 2004 08:25: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: > > By longstanding IETF precedent a charter only states the > problems that > > a WG MAY solve. There is no requirement that the eventual solution > > MUST meet all the criteria that might be claimed to be in the scope > > of the charter. > > The IETF has a longstanding precedent of having running code that > demonstrates the validity of the solution. From the Mission > Statement: Code is only required for progress from Proposed to Draft. In this case we already have a lot of independent code bases that more than meet the criteria that would be applied on the Proposed to draft transition if they were conformant. The point of the proposed to draft transition is to define the state to which implementations are to be expected to conform. The rules that govern WG procedure are defined by the RFC on standards track process, not the mission statement. Phill From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 12:17: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 MAA18673 for ; Wed, 18 Aug 2004 12:17: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 i7IFq5Cv082070; Wed, 18 Aug 2004 08:52: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 i7IFq5Fj082069; Wed, 18 Aug 2004 08:52:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IFq4se082053 for ; Wed, 18 Aug 2004 08:52:05 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7IFq4lP020070 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 Aug 2004 11:52:04 -0400 Date: Wed, 18 Aug 2004 11:52:04 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: Andrew Newton , Chris Haynes , IETF MARID WG Subject: Re: Not a point of order RE: Point of Order: Incomplete, flawed respo nse to MARID WG Charter 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, 18 Aug 2004, Hallam-Baker, Phillip wrote: > In the third place there are no rules of order here. The IETF > process does not use Roberts rules or recognize points of order. If you > want to raise a point of order there has to first be rules of order on > which a point may be raised. I know. Thats why I used the term "process check", and pointed out the need for consensus. We know what he means without your technicalities on Roberts Rules of Order, which as you point out, don't apply. The IETF does have a process of moving drafts to last call. > Chris can raise the issue in last call. And then the chairs > decide on what the consensus of the group is and write a little note > to answer the various objections raised. WG Chair's announced intention to proceed to 'last call' on Sender-ID within a few days. One might consider that Chris has raised his objection for the Chairs to consider. Since the technical problems are so plain and numerous, it seems to be a waste of time to go to last call. --Dean From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 12:45:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20569 for ; Wed, 18 Aug 2004 12:45: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 i7IGIIaH086218; Wed, 18 Aug 2004 09:18:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IGIIRk086217; Wed, 18 Aug 2004 09:18:18 -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 i7IGIHpq086191 for ; Wed, 18 Aug 2004 09:18:18 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i7IGI3Rf012438; Wed, 18 Aug 2004 18:18:03 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i7IGFfHb006474; Wed, 18 Aug 2004 18:15:41 +0200 From: Hadmut Danisch Date: Wed, 18 Aug 2004 09:15:40 -0700 To: Chris Haynes Cc: Andrew Newton , IETF MARID WG Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Charter Message-ID: <20040818161540.GA6160@danisch.de> References: <024301c4850e$a4eae3b0$0200000a@ringo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024301c4850e$a4eae3b0$0200000a@ringo> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 18, 2004 at 11:32:14AM +0100, Chris Haynes wrote: > > Is it in order for the WG to proceed to last call with a solution which: > - addresses only half the problem space and > - increases the number of unauthorized, frequently virus-carrying, messages > on the Internet? Yes, this is in order for that WG, while I absolutely share your concerns (and therefore had designed RMX to deal with the bounce message problem, so there was a solution to that problem, but that WG does not want this problem to be solved). Security protocol design requires to define a problem space, to create a solution, and then to show that the solution actually solves the problems of the problem space. That's not the way this WG works. The space this WG is working on, is the commercial interestes space. And that's what's going to be fulfilled. Interestingly, this space is not well-defined. As soon as you mention or question it, you'll get kicked out from the mailing list. So don't expect the output of the WG to be a good solution to a technical security problem, because that's not what it has been engineered to be. If it had been, you would have found a precise definition of the 'problem space', what the protocol is aimed to solve. Have a look at the 'Goales and Milestones' section of the group charter. Do you find any precise description or definition of the kind of attack this WG is working on? No. That's not the way it works. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 13:02: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 NAA21964 for ; Wed, 18 Aug 2004 13:02: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 i7IGTop2087917; Wed, 18 Aug 2004 09:29:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IGToMh087916; Wed, 18 Aug 2004 09:29:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IGTnpo087908 for ; Wed, 18 Aug 2004 09:29:49 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i7IGTobh012643; Wed, 18 Aug 2004 18:29:50 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i7IGTZJY006646; Wed, 18 Aug 2004 18:29:35 +0200 From: Hadmut Danisch Date: Wed, 18 Aug 2004 09:29:34 -0700 To: Andrew Newton Cc: "ietf mxcomp (e-mail)" Subject: IPR (Was: draft minutes of the San Diego meeting) Message-ID: <20040818162934.GA6504@danisch.de> References: <8E065FFE-EBA1-11D8-97B2-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E065FFE-EBA1-11D8-97B2-000A95B3BA44@hxr.us> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 11, 2004 at 10:20:11AM -0400, Andrew Newton wrote: > > 4) Intellectual Property Discussion > Andy introduced the IPR discussion with a slide asking > three questions: what parts of Sender ID are covered by IPR > claims, ...? Which kinds of IPR is this WG going to respect? Trademarks and Patents only? Which jurisdictions are relevant to judge what exactly is an IPR? Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 13:12: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 NAA22880 for ; Wed, 18 Aug 2004 13:12: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 i7IGchun089648; Wed, 18 Aug 2004 09:38:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IGchIR089647; Wed, 18 Aug 2004 09:38:43 -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 i7IGcgtJ089626 for ; Wed, 18 Aug 2004 09:38:42 -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 (Email Firewall v6.0.0)); Wed, 18 Aug 2004 09:38:42 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Wed, 18 Aug 2004 09:38:30 -0700 Message-ID: From: "Daryl Odnert" To: "'Chris Haynes'" cc: "IETF MARID WG" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Wed, 18 Aug 2004 09:38:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D3D59981OS6065819-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48541.3242008A" 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_01C48541.3242008A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Chris Haynes wrote: > Therefore, Sender-ID _requires_ MTAs of previous good > repute to generate and send Bounce messages which: > [snip] Sorry, but I don't understand this objection. An MTA is only responsible for sending a non-delivery notification after it has accepted responsibility for relaying the message. What is the real-world situation in which an MTA would be accepting a message for relaying when that message will be unable to pass a Sender-ID test at the next hop? Thanks, Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C48541.3242008A Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: Point of Order: Incomplete, flawed response to MARID WG Charter

Chris Haynes wrote:
> Therefore, Sender-ID _requires_ MTAs of previous good
> repute to generate and send Bounce messages which:
> [snip]

Sorry, but I don't understand this objection.  An MTA is
only responsible for sending a non-delivery notification
after it has accepted responsibility for relaying the message.
What is the real-world situation in which an MTA would be
accepting a message for relaying when that message will be
unable to pass a Sender-ID test at the next hop?

Thanks,
Daryl Odnert
Tumbleweed Communications
Redwood City, California




------_=_NextPart_001_01C48541.3242008A-- From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 13:43:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24734 for ; Wed, 18 Aug 2004 13:43: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 i7IHFrTh095418; Wed, 18 Aug 2004 10:15: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 i7IHFrqn095417; Wed, 18 Aug 2004 10:15:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost4.mail.uk.easynet.net (smarthost4.mail.uk.easynet.net [212.135.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IHFqai095411 for ; Wed, 18 Aug 2004 10:15:52 -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 1BxU2U-000GsW-00; Wed, 18 Aug 2004 18:15:54 +0100 Message-ID: <04c701c48546$b3227000$0200000a@ringo> From: "Chris Haynes" To: "Daryl Odnert" Cc: "IETF MARID WG" References: Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Wed, 18 Aug 2004 18:13:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit RE: Point of Order: Incomplete, flawed response to MARID WG Charter On Wednesday, August 18, 2004 5:38 PM at Daryl Odnert asked: >Chris Haynes wrote: >> Therefore, Sender-ID _requires_ MTAs of previous good >> repute to generate and send Bounce messages which: >> [snip] >Sorry, but I don't understand this objection. An MTA is >only responsible for sending a non-delivery notification >after it has accepted responsibility for relaying the message. >What is the real-world situation in which an MTA would be >accepting a message for relaying when that message will be >unable to pass a Sender-ID test at the next hop? I think the following scenario is one which illustrates my concern: Small business: (Virus on) End user MUA sends message to internal MTA, which stores-and-forwards message to public-facing MTA of the business' ISP. This ISP-MTA has not implemented Sender-ID, so does no know that the PRA will later be detected as a forgery. This ISP is generally slack about security, adding Resent-From headers, etc. ISP-MTA accepts message for onward delivery, cannot initially contact destination MTA, stores message and undertakes to try again later. Second attempt to contact destination MTA succeeds. Destination MTA applies Sender-ID, rejects message during SMTP protocol exchange with a '550'. ISP-MTA notes the '550' and fulfils its 'contract' by generating a non-delivery "Bounce" message, which is sent to the address in "Mail-From" in the original (virus-generated?) message. Chris From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 13:53: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 NAA25445 for ; Wed, 18 Aug 2004 13:53:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IHUo9d097665; Wed, 18 Aug 2004 10:30:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IHUo2V097664; Wed, 18 Aug 2004 10:30:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IHUmKn097649 for ; Wed, 18 Aug 2004 10:30:48 -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, 18 Aug 2004 13:30:49 -0400 id 002134FF.41239249.00005910 In-Reply-To: <20040818162934.GA6504@danisch.de> References: <8E065FFE-EBA1-11D8-97B2-000A95B3BA44@hxr.us> <20040818162934.GA6504@danisch.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <576626CE-F13C-11D8-B4ED-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: "ietf mxcomp (e-mail)" From: Andrew Newton Subject: Re: IPR (Was: draft minutes of the San Diego meeting) Date: Wed, 18 Aug 2004 13:30:47 -0400 To: Hadmut Danisch X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 18, 2004, at 12:29 PM, Hadmut Danisch wrote: > Which kinds of IPR is this WG going to respect? > Trademarks and Patents only? > > Which jurisdictions are relevant to judge what exactly is an > IPR? RFC 3667 and RFC 3668 govern the IETF's process with respect to IPR. -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 14:01: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 OAA25919 for ; Wed, 18 Aug 2004 14:00: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 i7IHd6cG099289; Wed, 18 Aug 2004 10:39: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 i7IHd68B099288; Wed, 18 Aug 2004 10:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp3g.bellsouth.com (aismtp3g.bellsouth.com [139.76.165.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IHd3Ge099268 for ; Wed, 18 Aug 2004 10:39:05 -0700 (PDT) (envelope-from Damon.Sauer@BellSouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp3g.bellsouth.com with ESMTP; Wed, 18 Aug 2004 13:38:10 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Wed, 18 Aug 2004 12:37:54 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB904748D20@bremocog-55> Thread-Topic: Point of Order: Incomplete, flawed response to MARID WG Chart er Thread-Index: AcSFR2+n5ogLCiK2Q52zDo4xJihYBQAARWzA From: "Sauer, Damon" To: "Chris Haynes" , "Daryl Odnert" Cc: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IHd5Ge099283 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit This also can happen today. Viruses act just like human viruses. They need a path of contagion. Block that path or limit it and the virus is quickly contained and dies. The virus writer would have to tailor the virus to these type systems and also figure out how to get the virus to propagate outside these systems in order to have it survive and grow. The virus writer would also have to have an account internal to these systems. Far be it from me to try to figure out what a virus writer is going to do next, but writing specific code to take advantage of this type of infection path would not be in the virus writers best interest as it does not allow for the highest, most widespread infection rate. Sure, the locks on my house don't keep people from driving semi-trucks through my front door... Does that mean I should beef up my deadbolts? Don't try to over design the system. It is not necessary. Regards, Damon Sauer -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Chris Haynes Sent: Wednesday, August 18, 2004 1:14 PM To: Daryl Odnert Cc: IETF MARID WG Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Chart er RE: Point of Order: Incomplete, flawed response to MARID WG Charter On Wednesday, August 18, 2004 5:38 PM at Daryl Odnert asked: >Chris Haynes wrote: >> Therefore, Sender-ID _requires_ MTAs of previous good >> repute to generate and send Bounce messages which: >> [snip] >Sorry, but I don't understand this objection. An MTA is >only responsible for sending a non-delivery notification >after it has accepted responsibility for relaying the message. What is >the real-world situation in which an MTA would be accepting a message >for relaying when that message will be unable to pass a Sender-ID test >at the next hop? I think the following scenario is one which illustrates my concern: Small business: (Virus on) End user MUA sends message to internal MTA, which stores-and-forwards message to public-facing MTA of the business' ISP. This ISP-MTA has not implemented Sender-ID, so does no know that the PRA will later be detected as a forgery. This ISP is generally slack about security, adding Resent-From headers, etc. ISP-MTA accepts message for onward delivery, cannot initially contact destination MTA, stores message and undertakes to try again later. Second attempt to contact destination MTA succeeds. Destination MTA applies Sender-ID, rejects message during SMTP protocol exchange with a '550'. ISP-MTA notes the '550' and fulfils its 'contract' by generating a non-delivery "Bounce" message, which is sent to the address in "Mail-From" in the original (virus-generated?) message. Chris ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 14:30: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 OAA27568 for ; Wed, 18 Aug 2004 14:30: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 i7IHu0Bn002360; Wed, 18 Aug 2004 10:56: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 i7IHu0p1002359; Wed, 18 Aug 2004 10:56:00 -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 i7IHu0xd002340 for ; Wed, 18 Aug 2004 10:56:00 -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 (Email Firewall v6.0.0)); Wed, 18 Aug 2004 10:55:54 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Wed, 18 Aug 2004 10:55:42 -0700 Message-ID: From: "Daryl Odnert" To: "'Chris Haynes'" cc: "IETF MARID WG" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Wed, 18 Aug 2004 10:55:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D3D47A01OS6071854-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4854C.9407E934" 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_01C4854C.9407E934 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Chris, In your example, it wasn't clear to me whether or not the the small business domain published a Sender ID policy in the DNS. Assuming the domain did not publish any policy data, the receiving MTA cannot perform the Sender ID test if there is no policy information in the DNS, so the message should not be rejected with a 550 error unless it has is some other good reason to do so. On the other hand, if the domain did publish a Sender ID policy and the message is rejected for policy reasons, then either the policy data is inaccurate or the ISP is doing something to the message that it shouldn't be doing. So, I still don't understand the crux of your complaint about Sender ID here. How is Sender ID causing any harm to anyone here? Daryl Odnert Tumbleweed Communications Redwood City, California ==== Chris' example: Small business: (Virus on) End user MUA sends message to internal MTA, which stores-and-forwards message to public-facing MTA of the business' ISP. This ISP-MTA has not implemented Sender-ID, so does no know that the PRA will later be detected as a forgery. This ISP is generally slack about security, adding Resent-From headers, etc. ISP-MTA accepts message for onward delivery, cannot initially contact destination MTA, stores message and undertakes to try again later. Second attempt to contact destination MTA succeeds. Destination MTA applies Sender-ID, rejects message during SMTP protocol exchange with a '550'. ISP-MTA notes the '550' and fulfils its 'contract' by generating a non-delivery "Bounce" message, which is sent to the address in "Mail-From" in the original (virus-generated?) message. ------_=_NextPart_001_01C4854C.9407E934 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: Point of Order: Incomplete, flawed response to MARID WG Charter

Chris,

In your example, it wasn't clear to me whether or not the
the small business domain published a Sender ID policy
in the DNS.

Assuming the domain did not publish any policy data, the
receiving MTA cannot perform the Sender ID test if there
is no policy information in the DNS, so the message should
not be rejected with a 550 error unless it has is some other
good reason to do so.

On the other hand, if the domain did publish a Sender ID
policy and the message is rejected for policy reasons, then
either the policy data is inaccurate or the ISP is doing
something to the message that it shouldn't be doing.

So, I still don't understand the crux of your complaint
about Sender ID here.  How is Sender ID causing any harm
to anyone here?

Daryl Odnert
Tumbleweed Communications
Redwood City, California

====
Chris' example:

Small business:  (Virus on) End user MUA sends message to internal MTA, which
stores-and-forwards message to public-facing MTA of the business' ISP.

This ISP-MTA has not implemented Sender-ID, so does no know that the PRA will
later be detected as a forgery. This ISP is generally slack about security,
adding Resent-From headers, etc.

ISP-MTA accepts message for onward delivery, cannot initially contact
destination MTA, stores message and undertakes to try again later.

Second attempt to contact destination MTA succeeds.

Destination MTA applies Sender-ID, rejects message during SMTP protocol exchange
with a '550'.

ISP-MTA notes the '550' and fulfils its 'contract' by generating a non-delivery
"Bounce" message, which is sent to the address in "Mail-From" in the original
(virus-generated?) message.

------_=_NextPart_001_01C4854C.9407E934-- From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 14:40:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28180 for ; Wed, 18 Aug 2004 14:40: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 i7II9hIH008599; Wed, 18 Aug 2004 11:09: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 i7II9hbe008598; Wed, 18 Aug 2004 11:09:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7II9hNe008592 for ; Wed, 18 Aug 2004 11:09:43 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id E631B4149B; Wed, 18 Aug 2004 11:09:46 -0700 (PDT) Subject: Comparison of Sender-ID versus SPF and MPR & BATV From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1092852585.20710.128.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 18 Aug 2004 11:09:45 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Feature comparison of Sender-ID versus SPF and MPR & BATV ........................................... Sender-ID SPF MPR & BATV DNS Lookups for Policy........................ 10 ..... 20 ....... 1 DNS Lookups for Channel..................... >500 ... >500 ....... 1 Maximal Overhead Time w/o pkt loss (seconds) 200 .. >4000 ...... 15 Maximal UDP/TCP ratio w avg 4KB mail........ 5000% .. 5000% ..... 30% UDP Exponential Back-off...................... No .... Yes ..... Yes Reduces Spoof Bounces......................... No .... Yes ..... Yes w/o BATV Stops Spoof Bounces........................... No ..... No ..... Yes w BATV Assures RFC2821 MAIL FROM..................... No .... Yes ..... Yes Assures RFC2822 From.......................... No ..... No ..... Yes Identifies actual sender...................... No ..... No ..... Yes Reduces Phishing.............................. No ..... No ..... Yes Reduces Spoofing.............................. No ..... No ..... Yes Enables Accreditation to abate abuse.......... No ..... No ..... Yes Enables legal enforcement..................... No ..... No ..... Yes Identity helps locate logs.................... No ..... No ..... Yes May require digital signature................. No ..... No ..... Yes May require BATV.............................. No ..... No ..... Yes Allows use of recognized mailbox.............. No ..... No ..... Yes Encumbered by IPR............................ Yes ..... No ...... No Invites addition of Resent-From headers...... Yes ..... No ...... No Assumes RFC2822 header integrity............. Yes ..... No ...... No Requires text parser to execute macros....... Yes .... Yes ...... No Allows Identity spoofing with open records... Yes .... Yes ...... No Checks required at each MTA.................. Yes .... Yes ...... No Breaks Forwarding with Channel Restrictions.. Yes .... Yes Optional w/o BATV With Sender-ID, a spammer may employ open records or utilize Resent-From headers to continue spoofing or phishing with the From. With Sender-ID, a spammer may also employ return-path bounce techniques to evade blacklisting. Although Sender-ID and SPF allow use of open records to retain an ability to use different access, such records will become problematic when exploited by spammers. MPR does not suffer this problem, as the sender identity is based upon both From and authenticated EHLO domain. With MPR, restrictions on From or MAIL FROM are optional and asserting these fields to be unrestricted can not be exploited, as with Sender-ID or SPF. The actual sender is the entity submitting the mail. If there is a problem, this is the identity that may be safely blocked. As the mail channel is not secure, negative assertions based upon RFC 2822 content can not be defended. Such assumption implies every point within the mail channel performs Sender-ID checks. As Sender-ID is highly prone to DoS attack, it is likely such checks may be disabled. The motivation for a DoS of Sender-ID would be to enable spoofing over shared MTAs with full validations. With Sender-ID, there is nothing to alert a user the the channel integrity is compromised. Sender-ID assumes channel integrity, but it is not verifiable. With Sender-ID, the sender is held responsible for a lack of mail channel integrity, although needed checks must be done by the recipient. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 15:46: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 PAA03056 for ; Wed, 18 Aug 2004 15:46: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 i7IJKFOe021464; Wed, 18 Aug 2004 12:20: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 i7IJKFgQ021463; Wed, 18 Aug 2004 12:20:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from paexchange.corp.mailfrontier.com (67.109.59.194.ptr.us.xo.net [67.109.59.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJKFC7021444 for ; Wed, 18 Aug 2004 12:20:15 -0700 (PDT) (envelope-from nleon@mailfrontier.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: New draft-ietf-marid-core-03 and draft-ietf-marid-pra-00 Date: Wed, 18 Aug 2004 12:20:13 -0700 Message-ID: Thread-Topic: New draft-ietf-marid-core-03 and draft-ietf-marid-pra-00 Thread-Index: AcSBjp8Ld/mIu9qbR664kchd+beaYADyLPyg From: "Nate Leon" To: "IETF MARID WG" Cc: "Internet Draft Editor" , "Jim Lyon" , , "Andrew Newton" , "Marshall Rose" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IJKFC7021457 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit A few minor comments on core-03... Abstract -------- Says: This document describes the following: mechanisms by which a domain owner can publish its set of outgoing MTAs But I don't think that is the case anymore? 3. Decision Model ----------------- Says: There are four steps to answering this question but I still see only three steps listed. :-) 7.1 Simple E-mailers -------------------- Says: domains SHOULD publish e-mail policy records in DNS I think "e-mail policy records" is a term left over from previous revs? If not, it should be defined in this doc someplace. Regards, Nate -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Jim Lyon Sent: Friday, August 13, 2004 4:38 PM To: Internet Draft Editor Cc: Andrew Newton; Marshall Rose; IETF MARID WG Subject: New draft-ietf-marid-core-03 and draft-ietf-marid-pra-00 I-D Editor, One revised draft, draft-ietf-marid-core-03 and one new draft, draft-ietf-marid-pra-00 are attached. The MARID WG chairs are copied for approval for the new draft. Change record (for the working group): Section 2.1: Changed "it makes no attempt to authenticate the local-part" to "it is not directed at the local-part". Section 4: Moved PRA definition to new draft-ietf-marid-pra-00. Section 6.3: Changed title from "Forged Resent-From Attacks" to "Forged Sender Attacks". Changed "In order to avoid this attack" to "In order to neutralize this attack". New Section 6.4: Address Space Hijacking Section 7: Added language that e-mail forwarders, mailing list servers and third-party mailers SHOULD publish Sender ID records, and SHOULD use MTAs for which the Sender ID test will yield a "pass" result. Page header now matches title. Fixed a few typos. Thanks, -- Jim Lyon mailto:JimLyon@Microsoft.Com tel:+1-425-706-0867 Internet commerce will never really take off until you can buy something online without getting spammed by the vendor. From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 15:49: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 PAA03630 for ; Wed, 18 Aug 2004 15:49:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJNbbx022166; Wed, 18 Aug 2004 12: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 i7IJNbu6022165; Wed, 18 Aug 2004 12:23: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 i7IJNake022159 for ; Wed, 18 Aug 2004 12:23:36 -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 PAA01396; Wed, 18 Aug 2004 15:22:48 -0400 (EDT) Message-Id: <200408181922.PAA01396@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-02.txt Date: Wed, 18 Aug 2004 15:22:48 -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 Sender-ID Record: Format and Interpretation Author(s) : M. Wong, M. Lentczner Filename : draft-ietf-marid-protocol-02.txt Pages : 41 Date : 2004-8-18 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-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-protocol-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-protocol-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-8-18143137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-18143137.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 16:38:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03632 for ; Wed, 18 Aug 2004 15:49: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 i7IJNR3V022125; Wed, 18 Aug 2004 12:23: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 i7IJNR05022124; Wed, 18 Aug 2004 12:23:27 -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 i7IJNQCC022116 for ; Wed, 18 Aug 2004 12:23:27 -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 PAA01357; Wed, 18 Aug 2004 15:22:39 -0400 (EDT) Message-Id: <200408181922.PAA01357@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-pra-00.txt Date: Wed, 18 Aug 2004 15:22: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 : Purported Responsible Address in E-Mail Messages Author(s) : J. Lyon Filename : draft-ietf-marid-pra-00.txt Pages : 6 Date : 2004-8-18 The document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the "Purported Responsible Address" (PRA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-pra-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-pra-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-pra-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-8-18143121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-pra-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-pra-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-18143121.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 16:39: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 PAA03641 for ; Wed, 18 Aug 2004 15:49: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 i7IJNWVK022152; Wed, 18 Aug 2004 12:23: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 i7IJNW2A022151; Wed, 18 Aug 2004 12:23:32 -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 i7IJNVrl022144 for ; Wed, 18 Aug 2004 12:23:31 -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 PAA01384; Wed, 18 Aug 2004 15:22:44 -0400 (EDT) Message-Id: <200408181922.PAA01384@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-03.txt Date: Wed, 18 Aug 2004 15:22:43 -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 : Sender ID: Authenticating E-Mail Author(s) : J. Lyon, M. Wong Filename : draft-ietf-marid-core-03.txt Pages : 12 Date : 2004-8-18 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-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-core-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-core-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-18143126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-core-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-core-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-18143126.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 16:59: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 QAA16111 for ; Wed, 18 Aug 2004 16:59: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 i7IKOTgG032283; Wed, 18 Aug 2004 13: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 i7IKOTSN032282; Wed, 18 Aug 2004 13:24:29 -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 i7IKOSqb032249 for ; Wed, 18 Aug 2004 13:24:28 -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 i7IKOK3R025001 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 Aug 2004 16:24:23 -0400 Date: Wed, 18 Aug 2004 16:24:20 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Sauer, Damon" cc: Chris Haynes , Daryl Odnert , IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er In-Reply-To: <38363D9940D92A458010AAE24D162EB904748D20@bremocog-55> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The flaw in this line of thought is that computer viruses are engineered by people who are far more intelligent than biological viruses. Once an obstacle appears, the human can alter the virus, most of which upgrade themselves automatically already. In the case of SPF, all the virus operator has to do to continue forging email is to have the virus upgrade itself to use the infected domain's relays using the user's stored email configuration or just by guessing, or better, by using the SPF records. After that, they forge away. --Dean On Wed, 18 Aug 2004, Sauer, Damon wrote: > > This also can happen today. > Viruses act just like human viruses. They need a path of contagion. > Block that path or limit it and the virus is quickly contained and dies. > The virus writer would have to tailor the virus to these type systems > and also figure out how to get the virus to propagate outside these > systems in order to have it survive and grow. The virus writer would > also have to have an account internal to these systems. Far be it from > me to try to figure out what a virus writer is going to do next, but > writing specific code to take advantage of this type of infection path > would not be in the virus writers best interest as it does not allow for > the highest, most widespread infection rate. > Sure, the locks on my house don't keep people from driving semi-trucks > through my front door... Does that mean I should beef up my deadbolts? > Don't try to over design the system. It is not necessary. > > Regards, > Damon Sauer > > > > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Chris Haynes > Sent: Wednesday, August 18, 2004 1:14 PM > To: Daryl Odnert > Cc: IETF MARID WG > Subject: Re: Point of Order: Incomplete, flawed response to MARID WG > Chart er > > > > RE: Point of Order: Incomplete, flawed response to MARID WG Charter On > Wednesday, August 18, 2004 5:38 PM at Daryl Odnert asked: > > >Chris Haynes wrote: > >> Therefore, Sender-ID _requires_ MTAs of previous good > >> repute to generate and send Bounce messages which: > >> [snip] > >Sorry, but I don't understand this objection. An MTA is > >only responsible for sending a non-delivery notification > >after it has accepted responsibility for relaying the message. What is > >the real-world situation in which an MTA would be accepting a message > >for relaying when that message will be unable to pass a Sender-ID test > >at the next hop? > > > I think the following scenario is one which illustrates my concern: > > Small business: (Virus on) End user MUA sends message to internal MTA, > which stores-and-forwards message to public-facing MTA of the business' > ISP. > > This ISP-MTA has not implemented Sender-ID, so does no know that the PRA > will later be detected as a forgery. This ISP is generally slack about > security, adding Resent-From headers, etc. > > ISP-MTA accepts message for onward delivery, cannot initially contact > destination MTA, stores message and undertakes to try again later. > > Second attempt to contact destination MTA succeeds. > > Destination MTA applies Sender-ID, rejects message during SMTP protocol > exchange with a '550'. > > ISP-MTA notes the '550' and fulfils its 'contract' by generating a > non-delivery "Bounce" message, which is sent to the address in > "Mail-From" in the original > (virus-generated?) message. > > > Chris > > > > ***** > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 > > > From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 17:23: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 RAA20273 for ; Wed, 18 Aug 2004 17:23: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 i7IKtRZU037130; Wed, 18 Aug 2004 13:55: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 i7IKtROQ037129; Wed, 18 Aug 2004 13:55:27 -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 i7IKtRrp037120 for ; Wed, 18 Aug 2004 13:55:27 -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 i7IKtRnt025632 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 Aug 2004 16:55:28 -0400 Date: Wed, 18 Aug 2004 16:55:27 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: "'Chris Haynes'" , Andrew Newton , IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er 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, 18 Aug 2004, Hallam-Baker, Phillip wrote: > > > > By longstanding IETF precedent a charter only states the problems > > > that a WG MAY solve. There is no requirement that the eventual > > > solution MUST meet all the criteria that might be claimed to be in > > > the scope of the charter. > > > > The IETF has a longstanding precedent of having running code that > > demonstrates the validity of the solution. From the Mission > > Statement: > > Code is only required for progress from Proposed to Draft. In this > case we already have a lot of independent code bases that more than > meet the criteria that would be applied on the Proposed to draft > transition if they were conformant. I suggest you look at RFC 2026, and tighten your terminology. A "draft" is what we have now. A "draft" is worked on, edited, and finally moves to "Proposed Standard". A "Proposed Standard" moves to "Draft Standard". It does not move to "draft" ordinarilly. 4.1.2 Draft Standard A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. The multiple implementations and experience referred to in RFC 2026 is different from the concept of obtaining _some_ running code to ensure that a draft is complete and workable. Indeed, the mission statement was drafted to make it clear that the IETF does not deal in hypothetical protocols. But we aren't moving from proposed standard to draft standard, we are moving from draft to proposed standard, and I'm not calling for multiple codebases or successful experience. Unless I miss the purpose of the last call or the track this draft is on. The point of several people posting is that there are many different problems that need to be solved before this draft should be considered for last call. _some_ testing and codebase should be available before a draft is put to last call. Otherwise, we are dealing in hypotheticals. Several days ago it was proposed that some testing be done before last call. I thought there were many people in favor of that. Indeed, I would have thought there was a consensus on that direction. Is that not the case? So what is the rush? I'm still not understanding what the rush is. --Dean From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 17:53: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 RAA23391 for ; Wed, 18 Aug 2004 17:53:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILK0k5041227; Wed, 18 Aug 2004 14: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 i7ILK0pi041226; Wed, 18 Aug 2004 14:20:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILJvhQ041197 for ; Wed, 18 Aug 2004 14:19:59 -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 D064B16E0B for ; Wed, 18 Aug 2004 17:28:21 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Chart er In-Reply-To: Your message of "Wed, 18 Aug 2004 16:24:20 EDT." Date: Wed, 18 Aug 2004 17:28:21 -0400 Message-Id: <20040818212821.D064B16E0B@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > In the case of SPF, all the virus operator has to do to continue forging > email is to have the virus upgrade itself to use the infected domain's > relays using the user's stored email configuration or just by guessing, or > better, by using the SPF records. After that, they forge away. One huge benefit to viruses by forging is that millions of user machines, with fast network connections, who aren't normally MTA's, can suddenly all attack other peoples MTA's. Like may people, I've had MTA's severely hit by a new virus load, due to precisely the above problem. If the viruses have to use the infected domains MTA to propogate, I think that's a great thing. Their MTA will probably die, won't distribute as many viruses, and therefore my MTA won't die. Viruses can, of course, get around this by using "open" SPF records, or records from an "evil" domain associated with the virus. But both of those situations involve a single point of attack: the DNS for the domain. Shut that down, and there's no longer any SPF records, and we're back to where we are today with viruses & forgery. So in one situation, we'll be better off. In another, we'll be worse off, due to the cost of deploying a protocol that doesn't help for that situation. It's up to individual MTA administrators to do the cost/benefit analysis for the two situations, to see if it's worth it for them to deploy a particular solution. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 18:01: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 SAA23899 for ; Wed, 18 Aug 2004 18:01: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 i7ILYPi3043431; Wed, 18 Aug 2004 14:34: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 i7ILYPdw043430; Wed, 18 Aug 2004 14:34:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from paexchange.corp.mailfrontier.com (67.109.59.194.ptr.us.xo.net [67.109.59.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILYOiq043412 for ; Wed, 18 Aug 2004 14:34:24 -0700 (PDT) (envelope-from nleon@mailfrontier.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Forged Sender (Resent-From) attacks Date: Wed, 18 Aug 2004 14:34:23 -0700 Message-ID: Thread-Topic: Forged Sender (Resent-From) attacks Thread-Index: AcSFayD+1uMiCBb0SXGyQvCU7QSUdQ== From: "Nate Leon" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7ILYOiq043424 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I realize concern around this topic has been raised multiple times (Dave Crocker, Doug Otis, Chris Haynes, etc...) but I still can't help feel we are under-estimating the seriousness of this issue. If I missed the posting where everybody agreed on the solution (entirely possible) please point me to it. :) I expect it will take years before all MUAs are updated (and widely deployed) to display the PRA, which I do not think is an acceptable timeframe to put a serious dent into phishing attacks. For completeness, here is another example of the concern: MAIL FROM:<> // don't care RCPT TO: DATA Subject: update your account info Resent-From: JoePhisher@phishingScam.com // valid domain authenticated by MARID ... From: account-services@yourbank.com // Spoofed domain, displayed by the MUA To: valid-recipient@example.com // bummer for you ... Are we really going to RFC with this issue left open? If nothing else, I at least want to add my vote to more thought being put into this topic. Regards, Nate From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 18: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 SAA26137 for ; Wed, 18 Aug 2004 18: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 i7ILqld9046132; Wed, 18 Aug 2004 14: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 i7ILqlMa046131; Wed, 18 Aug 2004 14:52:47 -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 i7ILqkUc046116 for ; Wed, 18 Aug 2004 14:52:46 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 394D2E05E6; Wed, 18 Aug 2004 17:52:47 -0400 (EDT) Date: Wed, 18 Aug 2004 17:52:47 -0400 From: John Leslie To: ietf-mxcomp@imc.org Subject: Re: I-D ACTION:draft-ietf-marid-protocol-01.txt Message-ID: <20040818215247.GE50011@verdi> References: <200408161919.PAA24682@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408161919.PAA24682@ietf.org> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I recognize how hard it is to put together a spec: in no way do I wish to belittle the work that went into this. But RFCs are forever. (Please be assured I was at least this picayune with Dave and Doug's drafts.) OTOH, this was a lot of work. I don't think I'll review all the other drafts so closely unless someone asks... Internet-Drafts@ietf.org wrote: > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-02.txt Meng/Mark asked: ] ] In the interests of openness, rather than contacting the authors ] directly, please post to either: ] the ietf-mxcomp mailing list ] or ] the spf-discuss mailing list. So, here goes: ] Abstract ] This document defines the format of a record that domains publish to ^^^^^^^ ] authorize a set of hosts to send mail on its behalf... ^^^ grammatical mismatch. ] This document only describes the particulars of the syntax and the ] algorithm of the function. I'd leave out the "only", and possibly add a few words to the next sentence to clarify where the "semantics" are defined. ] 1. Introduction ] Owners of domain names publish SPF records to make declarations about ] hosts that are and are not permitted to use their domain names... ^^^^^^^^^ "Permitted" isn't a very helpful word here. Granted, this is an "introduction", and we've already disclaimed any intent to describe semantics; but I fail to see how "permitted" gives the right connotations or denotations. If we avoided the passive voice, and talked about "intend to permit" to use their domain names, I think we'd be far better off. We might also consider the word "authorize", though I'd strongly recommend sticking within RFC2828 definitions of that word. BTW, we might consider listing RFC2828 in the references... ] Mail receivers perform tests, which read published records to ] determine how a domain's declarations apply to particular hosts in ^^ ] during mail reception. ^^^^^^ I think you mean just "during". ] 2. Permitted Sender Records ] ... ] record = version *( 1*SP ( directive / modifier ) ) *SP I know the Table of Contents already mentioned ABNF being "collected" in Appendix A; but I think it would make things easier if we mentioned in the text here that the full ABNF description of the syntax is in Appendix A, and that parts of it are quoted in the text which follows. ] 2.1.1 SPF DNS RR Type ] ... ] Sender-ID compliant mail originating zones MUST publish SPF2 type ] records, and MAY publish TXT type records that have identical content. ^^^ Perhaps we should warn folks about broken resolvers that won't be able to retrieve SPF2 RRs: this text makes it sound as if the problem is only finding DNS servers that correctly publish them. ] A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup ^^^^^^^ ^^^^^^ We should try for consistency of spelling... ] TXT record at the same time, or wait for negative answer. SPF2 type ] SHOULD be used if available. There's an implementation issue here: it's easy to imagine cases where the TXT RR will arrive first, or even where the negative response to the SPF2 query may never come. I think it would help to hint at this issue. ] It is recognized that the current practice (using a TXT type record), ^^^^^^^^^^^^^^^^^^^^ A bad term, IMHO. RFCs are forever. I'd delete it, and replace the parenthetical phrase with "using a TXT record" (without parentheses). ] Example RRs in this document are shown with the SPF2 record type, ] however they could be published with a TXT type. ^ Do you mean "also be published"? ] 2.1.3 Multiple Records ] A domain MUST NOT publish multiple records with the same version ] section, or with version sections that differ only in ver-minor or ] ver-ext fields. Such multiple records would cause a system checking ] them to select multiple records for processing and will result in a ] permanent error (see Section 3.4.1). ] ] Note that this rule still allows a domain to publish the same record ] twice, once as a TXT RR and once as a SPF2 RR, as only the SPF2 RR ] records will be considered. I think the intent is to state that you may not publish two SPF2 records with the version string starting with "spf2." or two TXT records starting with "spf2."; but that it is clearly OK to publish one SPF2 and one TXT (ignoring the issue of whether they must be identical). I'm not sure that's what this text says. Also, it's easy to imagine cases of a "minor" extension giving a domain reason to publish different records to be interpreted by receivers who are or are not updated to reflect the extension. We should be clear whether we're forbidding such a practice. You never specify what ver-ext should be used for. I think of it as similar to SMTP extensions, but I may be far afield of the intent. Since you seem to specify that its actual value must be ignored, I must admit to being confused. ] 2.1.5 Multiple Strings ] Text DNS records (both TXT and SPF2 RR types) can be composed of more ] than one strings.] ^^^^^^^ Usual usage is "more than one string". This section mainly (IMHO) deals with the feature where DNS servers silently break a string into multiple substrings for purposes of storing and reporting. I think it would be better to limit the text to describing that practice and how to deal with it. We certainly should not be encouraging people to advertise text strings that would require they be split. Also, this text as written tends to confuse multiple strings in a single text-type RR with multiple RRs. ] 2.1.6 Record Size ] It is STRONGLY ENCOURAGED that published records remain small enough ] that query results will fit within 512 octets in order to keep DNS ] answers from falling over to TCP. Since the answer size is dependent ] on many things outside the scope of this document, it is only ] possible to give this guideline: If the combined length of the DNS ] name and the record text is under 480 characters, then DNS answers ] should fit in UDP packets. This is not quite sufficient: _all_ records to be returned must fit in the 480 bytes. (Since we seem to be headed for a situation in which both SPF2 and SPF1 TXT records will be published for the same domain name, this is not an academic quibble.) ] Nonetheless, Sender-ID compliant sites MUST use DNS recursive servers ] that support EDNS0 [RFC2671] and [RFC3226] in order to be able to ] receive large DNS RR sets This language confuses. I think you mean Sender-ID receivers MUST query DNS servers that support EDNS0 (DNS Extension Mechanisms), not mentioning that they also must uses resolvers which support EDNS0 to make those queries. In any case, this is a capital-MUST, and I feel an obligation to ask whether we really want to say that a sender or receiver is _not_ doing sender-ID if they don't : personally, I would prefer this MUST weren't there; but if we decide we want it, I think we need to be _really_ clear what exactly MUST be done, and by which parties to sender-ID. ] 2.1.8 Minor Version ] This document only specifies records with a minor version of "0". ] All published records MUST start with "spf2.0/pra". ] ] Future versions of this document may define other minor versions to ] be used. This leaves me confused as to how we could manage a transition to the next minor version. I recommend giving careful thought to that expandability issue. ] 3.5.1 Term Evaluation ]... ] Mechanisms usually contain a ":" or "/" character after the name. I suspect that, in the wild, mechanisms will more often be specified without these. Do you perhaps mean, 'most mechanisms allow a ":" or "/" ' ? ] 3.7 Domain Spec ] Several of these mechanisms and modifiers have a ] section. The string is macro expanded (see Section 7). ] The resulting string is the common presentation form of a fully ] qualified DNS name: A series of labels separated by periods. This ] domain is called the in the rest of this document. ^^^^^^^^^^^^^ It's not clear to me whether refers to the macro- expanded version. (It seems it should, but this doesn't clearly say so.) ] 4.2 "include" There's a lot of room for confusion between "include" and "redirect". If one looks long enough, it becomes clear that the basic difference is that "include" returns, thus can generate only four conditions, while "redirect" doesn't return, thus can generate all seven. I think it would help to say so in as many words. ] The Include mechanism is intended for crossing administrative ] boundaries. While it is possible to use includes to consolidate ] multiple domains that share the same set of designated hosts, domains ] are encouraged to use redirects where possible, and to minimize the ] number of includes within a single administrative domain. This text is particularly confusing. In fact, it _still_ confuses me after multiple readings, and after I think I understand the differences between "include" and "redirect". Unless we can clarify just what point we're trying to make, I'd recommend deleting it. ] 4.3 "a" Here we get into serious IPv4 vs. IPv6 territory. I assume that if is v4, one implements an "A" lookup, while if is v6, one implements an "AAAA" lookup. It wouldn't hurt, IMHO, to say so explicitly. Also, since we _are_ aware of DNS servers which return incomplete lists, it wouldn't (IMHO) hurt to hint at that -- at least to the point of saying that is tested against the list returned. (Personally, I am careful enough to go through the ABNF to find just what "dual-cidr-length" means: not everyone will be. I don't have a specific recommendation about this; but examples might help.) ] 4.4 "mx" ]... ] Then perform an A lookup on each MX name returned, This is incorrect in the IPv6 case. (The grammatical structure also doesn't match the previous sentence.) I'm not enough of a DNS expert to remember for sure, but I think resolvers are required to return A and/or AAAA RRs if they are known and they fit. It wouldn't hurt to check the actual rule, and make the text match the rule more closely. ] This behavior breaks with the legacy "implicit MX" rule. See ] [RFC2821] Section 5. If such behavior is desired, the publisher ] should specify an "a" directive. ^ I think you mean "also specify". ] 4.5 "ptr" ]... ] For each record returned, validate the host name by looking up its ] IP address. Since this has known failure cases, we need to be quite explicit. Fortunately, we're almost there in the pseudocode which follows. IMHO, we should still clarify the v4/v6 issue; regardless, we're not "looking up its IP address" -- we're doing an A or AAAA query and searching the list returned. ] This mechanism matches if the is an ancestor of the ] name of , ^^^^^^^^^^^^ I think you mean "validated host name". ] 4.6 "ip4" and "ip6" ] These mechanisms test if falls into a given IP network. ^^^^^^^^^^ I think you mean "is contained within". ] The is compared to the given network. If they match, ^^^^^^^^^^ Better to say " high-order bits match". ] 5.2 exp: Explanation ]... ] If is empty, or there are any processing errors, ] temporary (such as SERVFAIL) or permanent (such as NXDOMAIN), or if ] no records are returned, or if more than one record is returned, then ] the explanation string empty with no further computation. ^^^^^^^^^^^^^^^^^^^^^^^^ I'm not sure I know what you meant here... ] Note: During recursion into an Include mechanism, explanations do not ] propagate out. ^^^^^^^^^^^^^ I assume you mean that a "Fail", "SoftFail", or "Neutral" result while recursed to an "include" mechanism should ignore the "exp=" modifier in the included SPF2 record and use the "exp=" modifier of the outermost check_host(). Language to that effect, IMHO, belongs under the "include" section, rather than here. (Or in addition; I really don't care.) It's less clear whether the "TempError" and "PermError" must similarly ignore the "exp=" in the included SPF2 record. That, IMHO, _needs_to_ be stated in the "include" section, as well as here. ] But during execution of a Redirect modifier, the explanation string ] from the target of the redirect is used. ^ I'd add: " for a "Fail" result of a mechanism in the redirected record Also, I think it would help to explicitly state whether the "exp=" modifier may be used for any other result. ] 6.1 Unrecognized Mechanisms and Modifiers ] New mechanisms can only be introduced by new versions of this ] document. At first blush, I'd expect future versions of this document to increment the . But here, we run afoul of the requirement (elsewhere) that there may not be two records which differ in . This strikes me as a Catch-22: we can't publish for both old and new versions of check_host() without publishing for both s; while we're prohibited from publishing one record for each. While I _can_ wrap my mind about the idea that we have a field which MUST always be ignored, I'm having trouble wrapping my mind around the idea that we MAY introduce new mechanisms, but all receivers that haven't been updated yet MUST fail to evaluate our SPF2 records in a useful way. ] 6.2 Processing Limits ]... ] MTAs or other processors MAY also impose a limit on the maximum ] amount of elapsed time to evaluate check_host(). This fails to make it clear whether the time limit applies: - to the entire process, including all "include"s and "redirect"s; - to all "include"s but separately to a "redirect"; - separately to all "include"s and "redirect"s; If we want that to be a local option, we've got a problem trying to guess which kind of limit the processor is imposing. If we specify one of the above, the guessing is much easier, but I'd still rather have an explicit error code for the timeout. ] Such a limit SHOULD allow at least 20 seconds. If such a limit is ] exceeded, the result of authentication SHOULD be "TempError". This strikes me as a bad idea. With "TempError", the default action (per core-3) is to reject with " 450 4.4.3 Sender ID check is temporarily unavailable The sender has no fully plausible alternative to simply retrying the email, according to whatever schedule the sending MTA may have programmed. Typically, this continues for days, possibly giving one warning which usually says, "You do not need to retry," and offers the user no mechanism for purging the queue. However, the actual situation is likely to be that that particular receiver chooses not to evaluate a record as complicated as the one the submitter's domain has published. This information may _never_ reach anyone capable of resolving the issue; and in the meantime, we're generating useless DNS traffic (which by definition exceeds what the recipient is willing to handle). ] 7.1 Macro definitions ]... ] The uppercase versions of all these macros are URL-encoded. Does this mean all macros, or just the three preceding ones? ] The "p" macro expands to the validated host name of . ]... ] There are two deprecated macro letters: "p" and "h". I'm guessing you mean the first sentence overrides the second. In any case, one of them should go, IMHO. ] 9. IANA Considerations ]... ] [[Missing application review policy]] We need to specify at least the allocation method (e.g. first-come- first-served). ] B.1 Simple Examples ]... ] spf2.0/pra mx/8 mx:example.org/8 -all ] -- any sending host in 192.0.2.128/24 or 192.168.2.136/8 passes CIDR lengths are inconsistent. I'd rather not try to guess what was intended... -- John Leslie From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 18:23: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 SAA26661 for ; Wed, 18 Aug 2004 18:23: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 i7ILx4L1047878; Wed, 18 Aug 2004 14:59: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 i7ILx4Nl047877; Wed, 18 Aug 2004 14:59:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILx48I047869 for ; Wed, 18 Aug 2004 14:59:04 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7ILx4Jt004704; Wed, 18 Aug 2004 14:59:04 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 14:59:03 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: "'Chris Haynes'" , Andrew Newton , IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Wed, 18 Aug 2004 14:58:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I suggest you look at RFC 2026, and tighten your terminology. Is this a deliberate troll or are the insults merely gratuious? > A "draft" is > what we have now. A "draft" is worked on, edited, and finally moves to > "Proposed Standard". A "Proposed Standard" moves to "Draft > Standard". It does not move to "draft" ordinarilly. My statement was perfectly clear in context. The IETF process is confusing but not that confusing. There is no code required at all at this point. We have multiple independent implementations that provide proof of concept. The creation of compliant versions is dependent on progress to Proposed Standard. > The multiple implementations and experience referred to in RFC 2026 is > different from the concept of obtaining _some_ running code > to ensure that a draft is complete and workable. That is not a process requirement. > The point of several people posting is that there are many different > problems that need to be solved before this draft should be > considered for last call. They can raise them in the last call period, that is the purpose of last call. > _some_ testing and codebase should be available before a draft > is put to last call. Otherwise, we are dealing in hypotheticals. There is considerably more experience of use of SPF today than there is of application of the vast majority of Proposed standards and more than a few Draft standard. > Several days ago it was proposed that some testing be done before last > call. I thought there were many people in favor of that. > Indeed, I would > have thought there was a consensus on that direction. Is that not the > case? So what is the rush? I'm still not understanding what > the rush is. If you really don't know what the rush is then I don't think you understand the problem. From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 18: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 SAA28483 for ; Wed, 18 Aug 2004 18: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 i7IMU9Gp052715; Wed, 18 Aug 2004 15:30: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 i7IMU9kX052714; Wed, 18 Aug 2004 15:30:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMU9gF052708 for ; Wed, 18 Aug 2004 15:30:09 -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, 18 Aug 2004 15:30:14 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Aug 2004 15:30:14 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Aug 2004 15:30:13 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Aug 2004 15:30:10 -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: Forged Sender (Resent-From) attacks Date: Wed, 18 Aug 2004 15:30:08 -0700 Message-ID: Thread-Topic: Forged Sender (Resent-From) attacks thread-index: AcSFayD+1uMiCBb0SXGyQvCU7QSUdQABxh+A From: "Harry Katz" To: "Nate Leon" , X-OriginalArrivalTime: 18 Aug 2004 22:30:10.0794 (UTC) FILETIME=[EC26ACA0:01C48572] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IMU9gF052709 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, August 18, 2004 2:34 PM, Nate Leon wrote: > I realize concern around this topic has been raised multiple > times (Dave Crocker, Doug Otis, Chris Haynes, etc...) but I > still can't help feel we are under-estimating the seriousness > of this issue. If I missed the posting where everybody > agreed on the solution (entirely possible) please point me to it. :) > > I expect it will take years before all MUAs are updated (and widely > deployed) to display the PRA, which I do not think is an > acceptable timeframe to put a serious dent into phishing attacks. > > For completeness, here is another example of the concern: > > MAIL FROM:<> // don't care > RCPT TO: > DATA > Subject: update your account info > Resent-From: JoePhisher@phishingScam.com // valid domain > authenticated by MARID > ... > From: account-services@yourbank.com // Spoofed domain, > displayed by the MUA > To: valid-recipient@example.com // bummer for you > ... > > Are we really going to RFC with this issue left open? > > If nothing else, I at least want to add my vote to more > thought being put into this topic. > To address the forged Sender/Resent problem I suggest we could add the following logic: If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY reject a message after DATA. In other words, if we validate an identity different from 2822.From, then there's a higher bar for a message to be accepted. The higher bar is that check of the SPF record must return PASS, else the receiver MAY reject the message. Another approach that's been discussed is to fall back to doing a check on the MAIL FROM address when there is no SPF record for the PRA. Both alternatives share some things in common: - Neither approach permits rejecting a message before DATA, unless SUBMITTER is present. If SUBMITTER is present then both approaches permit rejection before DATA. - Both place a higher burden on the "specialty" senders, namely the forwarders and list servers. This is a good thing. (Not that it's a good thing to place a burden, but that the burden is on the specialty senders rather than all MTAs in general.) - Neither approach can be done on day 1. At minimum we need to allow time for the specialty senders to publish SPF records. I think the approach I'm suggesting has several advantages: - It's semantically cleaner. We're basing the check on 2822 identities, with a higher burden in special cases where PRA is different from 2822.From. This isn't just a theoretical distinction. As we have repeatedly discussed on this list there are substantial semantic differences between MAIL FROM and the 2822 identities. - More importantly, this allow us to give much clearer directions to senders in terms of what to publish. You publish the IP addresses of servers authorized to send mail on behalf of your domain. We're not trying to mix this up with the IP addresses of servers that receive bounce messages on behalf of your domain. - This approach involves fewer DNS lookups because you're only performing the spoof check on one identity in all cases. Thus, if a spammer wants to forge a Sender or Resent- header, they have to use their own domain name. That'll get block-listed fairly quickly. I belive that plugs the hole that we're addressing. At this late point in the process I'm not sure whether this idea needs to go into the spec itself. It could be written up in a BCP. From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 19:40: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 TAA00565 for ; Wed, 18 Aug 2004 19:40: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 i7INDmYa059765; Wed, 18 Aug 2004 16:13:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7INDmME059764; Wed, 18 Aug 2004 16:13:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from paexchange.corp.mailfrontier.com (blackcomb.mailfrontier.com [209.144.181.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INDlku059752 for ; Wed, 18 Aug 2004 16:13:47 -0700 (PDT) (envelope-from nleon@mailfrontier.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Sender-ID and last hop validation Date: Wed, 18 Aug 2004 16:13:47 -0700 Message-ID: Thread-Topic: Sender-ID and last hop validation Thread-Index: AcSFeQOziSgnuCppS/unlgXMiUFIFw== From: "Nate Leon" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7INDlku059759 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Do I understand correctly that Sender-ID only authenticates the most recent hop? In the simple case, this is the domain where the client lives that sent the message. But in the more complex case, there may be forwarding hosts in the middle. i.e. my receiving MTA will authenticate the SMTP client delivering the message to me. Specifically, it will ask, is the IP address connecting to me authorized to send mail for the domain listed in the Purported Responsible Address? Or in example form... Some Guy at Yahoo! sends a msg to my Pobox.com account (assuming I had one :-) which in turn, forwards the message to MyWork address. Thus, the MTA at MyWork will see the msg coming from Pobox.com and validate that the Source IP address of the incoming message is authorized to send mail for the Pobox.com domain. The receiving MTA at MyWork.com does not authenticate anything about the yahoo.com domain. Simple illustration: SomeGuy@yahoo.com ---> nleon@pobox.com ---> nleon@MyWork.com Gory detail example... EHLO host.yahoo.com MAIL FROM: RCPT TO: DATA Subject: let's do lunch ... From: SomeGuy@yahoo.com To: nleon@pobox.com ... Hopefully, the MTA @ pobox.com validates against yahoo.com Pobox pre-pends a new header, and delivers the message to MyWork... EHLO host.pobox.com MAIL FROM: SUBMITTER= RCPT TO: DATA Subject: let's do lunch Resent-From: nleon@pobox.com ... From: SomeGuy@yahoo.com To: nleon@pobox.com ... Finally, the MTA @ MyWork validates against pobox.com (and not yahoo.com) So Sender-ID relies on the MTAs at each hop to do the authentication? If I was using P-U-box.com (instead of POBox.com) and the MTA at P-U-box didn't know about Sender-ID, I could receive junk at MyWork with an SPF/PASS. (assuming P-U-box did publish SPF records) Then I would obviously change my service provider, or yell at them until they implemented Sender-ID. :) Please correct any mis-understandings! TIA, Nate From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 20:01: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 UAA02187 for ; Wed, 18 Aug 2004 20:01: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 i7INdoKA064098; Wed, 18 Aug 2004 16:39:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7INdoZx064097; Wed, 18 Aug 2004 16:39: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 i7INdolp064074 for ; Wed, 18 Aug 2004 16:39: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 B6B04414BA; Wed, 18 Aug 2004 16:39:49 -0700 (PDT) Subject: Re: Solution For Trojans From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040818212821.D064B16E0B@mail.nitros9.org> References: <20040818212821.D064B16E0B@mail.nitros9.org> Content-Type: text/plain Message-Id: <1092872388.20821.82.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 18 Aug 2004 16:39: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 Wed, 2004-08-18 at 14:28, Alan DeKok wrote: > Dean Anderson wrote: > > In the case of SPF, all the virus operator has to do to continue forging > > email is to have the virus upgrade itself to use the infected domain's > > relays using the user's stored email configuration or just by guessing, or > > better, by using the SPF records. After that, they forge away. > > One huge benefit to viruses by forging is that millions of user > machines, with fast network connections, who aren't normally MTA's, > can suddenly all attack other peoples MTA's. Like may people, I've > had MTA's severely hit by a new virus load, due to precisely the above > problem. When transparent interception is not used by network providers, Trojans are free to submit mail from compromised machines without detection. Sender-ID may create market disincentives for trapping Trojans in this manner, although this is an effective ploy where network providers can handle the outbound problem themselves. > If the viruses have to use the infected domains MTA to propagate, I > think that's a great thing. Their MTA will probably die, won't > distribute as many viruses, and therefore my MTA won't die. Sender-ID attempts to change the paradigm of being able to use a mailbox address as an identifier from any point of access. This leaves two options for ISPs. Create an "open" list, or add a Resent-From header to the message as a means to accommodate customer expectations. If a few hundred thousand domains wish to retain this paradigm, then the number of "open" lists will ensure a Trojan can use a different mailbox for each spoofed message that "should" be accepted. If these "open" lists become blacklisted or refused as a result of this type of exploit, then "open" lists should have never been allowed in the standard, as it then invites mail failure. On the other hand, if each message was sent using a hostile domain, both SPF and Sender-ID allow these lists to encompass a significant portion of the Internet address space, which enables "throw away" domains to easily stage a broad base attack. > Viruses can, of course, get around this by using "open" SPF records, > or records from an "evil" domain associated with the virus. But both > of those situations involve a single point of attack: the DNS for the > domain. Shut that down, and there's no longer any SPF records, and > we're back to where we are today with viruses & forgery. Just as these Trojans exploit thousands of mailbox addresses, these mailboxes can be culled from a list with "open" records. There would be no single DNS to enable a shut-down. In addition, these mailbox records and DNS servers likely represent legitimate users. These users would react to retaliation tactics, as they have done nothing wrong, and overload customer support. This assumes mail providers are coerced into publishing these records initially, without changing the habits of their users. > So in one situation, we'll be better off. In another, we'll be > worse off, due to the cost of deploying a protocol that doesn't help > for that situation. If ISPs check their SMTP error logs, those sending spam can be quickly spotted. For this reason, transparent interception becomes a good choice incompatible with Sender-ID or SPF, however. ISPs should be able to track their clients to better enable quick removal, such as blacklisting at their intercept. Unlike Sender-ID, the channel is self documenting with CSV, and users become aware of the channel as part of the identification. If there is a problem, CSV identifies the entity responsible and safely blocked as a result. > It's up to individual MTA administrators to do the cost/benefit > analysis for the two situations, to see if it's worth it for them to > deploy a particular solution. Unlike Sender-ID, CSV does not change mail paradigms, but can be an effective deterrent as illustrated in the MPR draft. Unlike Sender-ID or SPF, the address space allocated by a particular CSV record is limited to that normally occupied by a single host, making a broad based attack more difficult. If there is a case to be made for placing a restriction on the RFC2822 From, MPR makes this restriction explicit and can prevent different headers from removing the desired protection. As providers are not required to create an "open" list to authenticate the MTA when using CSV and MPR, there is no record available to enable an exploit. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 20:05:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02367 for ; Wed, 18 Aug 2004 20:05: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 i7INWEmK062822; Wed, 18 Aug 2004 16: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 i7INWEL3062821; Wed, 18 Aug 2004 16:32:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from paexchange.corp.mailfrontier.com (blackcomb.mailfrontier.com [209.144.181.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INWDvZ062810 for ; Wed, 18 Aug 2004 16:32:13 -0700 (PDT) (envelope-from nleon@mailfrontier.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: IP Address spoofing Date: Wed, 18 Aug 2004 16:32:13 -0700 Message-ID: Thread-Topic: IP Address spoofing Thread-Index: AcSFe5cfpeMu+XOZQpiAa9G9vG9q9w== From: "Nate Leon" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7INWDvZ062814 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I am not an IP expert, so I defer to those on this list who have such expertise. It seems like folks on this list are not so concerned about spammers/fraudsters spoofing IP addresses, and that brings me some comfort. :) I believe the success of Sender-ID assumes spammers cannot spoof IP Addresses. I understand this is not easy to do. My concern is the degree of difficulty/expense it takes to do so. I saw one vendor who claims to have a sample, fraudulent message claiming to be from US Bank where the IP address was spoofed. e.g. how difficult is it for the spammer to get the whole transaction into a single packet so they can ignore return messages (blind attack), forge the packet's source address, get it through firewalls and routers that don't verify the source address, guess the sequence number, etc... Are we worrying enough about the potential for spammers to do IP Address spoofing? Or will it just be easier for them to write viruses/worms which carry spam-bots as their payload?! Regards, Nate From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 21:27: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 VAA05739 for ; Wed, 18 Aug 2004 21:27: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 i7J0nnT0074011; Wed, 18 Aug 2004 17:49: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 i7J0nnfI074010; Wed, 18 Aug 2004 17:49:49 -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 i7J0nms4074003 for ; Wed, 18 Aug 2004 17:49:48 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id E09A14149B; Wed, 18 Aug 2004 17:49:54 -0700 (PDT) Subject: RE: Forged Sender (Resent-From) attacks From: Douglas Otis To: Harry Katz Cc: MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1092876593.20821.143.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 18 Aug 2004 17:49:53 -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-08-18 at 15:30, Harry Katz wrote: > > To address the forged Sender/Resent problem I suggest we could add the > following logic: > > If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY reject > a message after DATA. These terms are odd as the Sender-ID check is called Check_Host() and not SPFCheck(PRA). From this terminology, it seems there is an expectation that a different data-set will now exclude the PRA. The flawed concept behind using Resent-From was to allow the From to be ignored, as this From domain will not pass! You are suggesting that if the forwarding domain does not publish, reject the message? Publish or die. > In other words, if we validate an identity different from 2822.From, > then there's a higher bar for a message to be accepted. The higher bar > is that check of the SPF record must return PASS, else the receiver MAY > reject the message. This will immediately reject valid mail. You may note the MPR draft allowed this treatment to be specifically defined. > Another approach that's been discussed is to fall back to doing a check > on the MAIL FROM address when there is no SPF record for the PRA. > > Both alternatives share some things in common: > > - Neither approach permits rejecting a message before DATA, unless > SUBMITTER is present. If SUBMITTER is present then both approaches > permit rejection before DATA. This is not true for the MPR draft. : ) > - Both place a higher burden on the "specialty" senders, namely the > forwarders and list servers. This is a good thing. (Not that it's a > good thing to place a burden, but that the burden is on the specialty > senders rather than all MTAs in general.) Again, the MPR draft does not place a higher burden upon these MTAs. It does however allow institutions to ensure their mail is not valid when the From does not indicate coming from their Mail Channel regardless of whether the Resent-From was published by some entity. The MPR provides a suitable treatment for this class of mail, without breaking other mail. Remember, forwarded mail is still rejected. > - Neither approach can be done on day 1. At minimum we need to allow > time for the specialty senders to publish SPF records. The MPR scheme would not need to impose any changes for institutions to have restrictions placed upon their From mailbox. > I think the approach I'm suggesting has several advantages: > > - It's semantically cleaner. We're basing the check on 2822 identities, > with a higher burden in special cases where PRA is different from > 2822.From. This isn't just a theoretical distinction. As we have > repeatedly discussed on this list there are substantial semantic > differences between MAIL FROM and the 2822 identities. This Resent-From may evolve into being the normal PRA. In which case, simply authenticating the EHLO domain and making this visible would arrive at that point much sooner, and not by imposing sets of "burdens" for mail to be accepted. It would also more quickly educate users and not run afoul of PRA selection errors or IPR contracts. : ) > - More importantly, this allow us to give much clearer directions to > senders in terms of what to publish. You publish the IP addresses of > servers authorized to send mail on behalf of your domain. We're not > trying to mix this up with the IP addresses of servers that receive > bounce messages on behalf of your domain. You just suggested a MAIL FROM fall-back mode? > - This approach involves fewer DNS lookups because you're only > performing the spoof check on one identity in all cases. You have simply decided more otherwise valid mail should be rejected. > Thus, if a spammer wants to forge a Sender or Resent- header, they have > to use their own domain name. That'll get block-listed fairly quickly. I > belive that plugs the hole that we're addressing. You seemed to have overlooked the "open" list problem. The spammer can use other people's records. You will be black-listing these people that have done nothing wrong, other than implemented this specification and made the mistake of publishing a record. Publish and die. > At this late point in the process I'm not sure whether this idea needs > to go into the spec itself. It could be written up in a BCP. Now you think the best practices should be to reject mail, if these records are not found? Publish or die. Death seems inevitable. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 21:32: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 VAA06001 for ; Wed, 18 Aug 2004 21:32: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 i7J0vblg075012; Wed, 18 Aug 2004 17:57: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 i7J0vbDQ075011; Wed, 18 Aug 2004 17:57:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J0vauc075005 for ; Wed, 18 Aug 2004 17:57:37 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7J0vg28008309; Wed, 18 Aug 2004 17:57:42 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 17:57:42 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Nate Leon'" , ietf-mxcomp@imc.org Subject: RE: IP Address spoofing Date: Wed, 18 Aug 2004 17:57:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I understand this is not easy to do. My concern is the degree of > difficulty/expense it takes to do so. I saw one vendor who claims to > have a sample, fraudulent message claiming to be from US Bank > where the > IP address was spoofed. It is a viable small scale attack, it is not a viable large scale attack. There are basically two types of IP spoofing, one is asymmetric routing which requires the assistence of the IP address being spoofed and is not relevant in the Sender-ID context. The second method is various routing compromises. These are certainly possible but unlikely to be persistent. Injecting fake routes for IP blocks in use is not a very easy crime to get away with. From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 21:39: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 VAA06270 for ; Wed, 18 Aug 2004 21:39: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 i7J143bL075913; Wed, 18 Aug 2004 18:04: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 i7J143WS075912; Wed, 18 Aug 2004 18:04:03 -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 i7J143lQ075896 for ; Wed, 18 Aug 2004 18:04:03 -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 (Email Firewall v6.0.0)); Wed, 18 Aug 2004 18:04:09 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Wed, 18 Aug 2004 18:03:55 -0700 Message-ID: From: "Daryl Odnert" To: "'Nate Leon'" , ietf-mxcomp@imc.org Subject: RE: Forged Sender (Resent-From) attacks Date: Wed, 18 Aug 2004 18:03:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D3D23031OS6119535-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48588.63D93807" 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_01C48588.63D93807 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Nate Leon wrote: > I expect it will take years before all MUAs are updated (and widely > deployed) to display the PRA, which I do not think is an acceptable > timeframe to put a serious dent into phishing attacks. My personal opinion is that solutions to the phishing problem absolutely require changes to MUAs. It is simply not enough to tell all email users to start trusting that email is "more secure" after some date when Sender ID goes to RFC. There needs to be some way that recipients can easily distinguish mail that has been authenticated versus mail that has not. Period. Until that happens and people understand the difference, the phishing problem is unlikely to go away. The closest analogy I can think of is that once upon a time, there was no SSL on the Web. But HTTP over SSL wasn't enough to secure the Web. The lock icon in the browsers were needed too so users could tell the difference between what is trustworthy and what is not. Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C48588.63D93807 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: Forged Sender (Resent-From) attacks

Nate Leon wrote:
> I expect it will take years before all MUAs are updated (and widely
> deployed) to display the PRA, which I do not think is an acceptable
> timeframe to put a serious dent into phishing attacks.

My personal opinion is that solutions to the phishing problem
absolutely require changes to MUAs.  It is simply not enough
to tell all email users to start trusting that email is "more
secure" after some date when Sender ID goes to RFC.

There needs to be some way that recipients can easily distinguish
mail that has been authenticated versus mail that has not.  Period.

Until that happens and people understand the difference, the phishing
problem is unlikely to go away.  The closest analogy I can think of
is that once upon a time, there was no SSL on the Web.  But HTTP over
SSL wasn't enough to secure the Web.  The lock icon in the browsers
were needed too so users could tell the difference between what is
trustworthy and what is not.

Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C48588.63D93807-- From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 22:26:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09890 for ; Wed, 18 Aug 2004 22:26:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J1vfcB084266; Wed, 18 Aug 2004 18:57: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 i7J1vfAb084265; Wed, 18 Aug 2004 18:57:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J1vWpN084232 for ; Wed, 18 Aug 2004 18:57:32 -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 4EA0D16E0B for ; Wed, 18 Aug 2004 22:06:06 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Sender-ID and last hop validation In-Reply-To: Your message of "Wed, 18 Aug 2004 16:13:47 PDT." Date: Wed, 18 Aug 2004 22:06:06 -0400 Message-Id: <20040819020606.4EA0D16E0B@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Nate Leon" wrote: > Do I understand correctly that Sender-ID only authenticates the most > recent hop? Any recipient looking at SMTP traffic must, by it's very design, look only at the most recent hop (i.e. the information it has, and can determine for itself). However, as the message traverses a series of MTA's to get to a final mailbox, the message must (by definition) traverse *all* of those MTA's. It can only do that if, at each hop, the message passes whatever checks are implemented by that hop. > Or in example form... Some Guy at Yahoo! sends a msg to my Pobox.com > account (assuming I had one :-) which in turn, forwards the message to > MyWork address. Thus, the MTA at MyWork will see the msg coming from > Pobox.com and validate that the Source IP address of the incoming > message is authorized to send mail for the Pobox.com domain. The > receiving MTA at MyWork.com does not authenticate anything about the > yahoo.com domain. If pobox has claimed responsibility for the message via the fields used by PRA, then the MyWork MTA can verify that the message passes the rules published by pobox.com. If pobox does not claim responsibility, and just forwards the message without touching the PRA fields, then the message must pass the rules published by the responsible domain as determined by PRA. Odds are, because the message now comes from pobox, that it won't. Whether this means that such forwarding is wrong, or Sender-Id is wrong, is an exercise left for the reader. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 22:26:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09922 for ; Wed, 18 Aug 2004 22:26:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J208SE084636; Wed, 18 Aug 2004 19:00: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 i7J208dT084635; Wed, 18 Aug 2004 19:00:08 -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 i7J206MN084626 for ; Wed, 18 Aug 2004 19:00:07 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 21892 invoked from network); 19 Aug 2004 02:01:52 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 19 Aug 2004 02:01:52 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7E7C0C9E-F183-11D8-8A10-000A95BC6A7E@margaretolson.com> Cc: "'Nate Leon'" , ietf-mxcomp@imc.org From: Margaret Olson Subject: Re: Forged Sender (Resent-From) attacks Date: Wed, 18 Aug 2004 22:00:07 -0400 To: "Daryl Odnert" X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7J207MN084629 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Aug 18, 2004, at 9:03 PM, Daryl Odnert wrote: > Nate Leon wrote: > > I expect it will take years before all MUAs are updated (and widely > > deployed) to display the PRA, which I do not think is an acceptable > > timeframe to put a serious dent into phishing attacks. > > But HTTP over > SSL wasn't enough to secure the Web.  The lock icon in the browsers > were needed too so users could tell the difference between what is > trustworthy and what is not. And the lock on the browser came after the SSL standard. SenderID is the first step, and a necessary step, not an instant cure for all that ails email. Margaret. From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 22:49: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 WAA10833 for ; Wed, 18 Aug 2004 22:49: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 i7J2BiRl086344; Wed, 18 Aug 2004 19:11:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J2Bi72086343; Wed, 18 Aug 2004 19:11:44 -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 i7J2BhTM086337 for ; Wed, 18 Aug 2004 19:11:43 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 6972 invoked from network); 19 Aug 2004 02:13:29 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 19 Aug 2004 02:13:29 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1CAFEF16-F185-11D8-8A10-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: "Nate Leon" , From: Margaret Olson Subject: Re: Forged Sender (Resent-From) attacks Date: Wed, 18 Aug 2004 22:11:42 -0400 To: "Harry Katz" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 18, 2004, at 6:30 PM, Harry Katz wrote: > > On Wednesday, August 18, 2004 2:34 PM, Nate Leon wrote: > >> I realize concern around this topic has been raised multiple >> times (Dave Crocker, Doug Otis, Chris Haynes, etc...) but I >> still can't help feel we are under-estimating the seriousness >> of this issue. If I missed the posting where everybody >> agreed on the solution (entirely possible) please point me to it. :) >> >> I expect it will take years before all MUAs are updated (and widely >> deployed) to display the PRA, which I do not think is an >> acceptable timeframe to put a serious dent into phishing attacks. >> >> For completeness, here is another example of the concern: >> >> MAIL FROM:<> // don't care >> RCPT TO: >> DATA >> Subject: update your account info >> Resent-From: JoePhisher@phishingScam.com // valid domain >> authenticated by MARID >> ... >> From: account-services@yourbank.com // Spoofed domain, >> displayed by the MUA >> To: valid-recipient@example.com // bummer for you >> ... >> >> Are we really going to RFC with this issue left open? >> >> If nothing else, I at least want to add my vote to more >> thought being put into this topic. >> > > To address the forged Sender/Resent problem I suggest we could add the > following logic: > > If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY > reject > a message after DATA. > <...much good stuff snipped ...> > Thus, if a spammer wants to forge a Sender or Resent- header, they have > to use their own domain name. That'll get block-listed fairly quickly. > I > belive that plugs the hole that we're addressing. This works. It for all practical purposes closes the hole whereby incomplete or absent records for Sender and particularly Resent can be used to dive under identity based controls in the temporary (but undoubtedly not brief) period before Sender ID records are for all practical purposes mandatory. My gut says that the people burdened - those running mail related services - are those most likely to be able to publish definitive and complete Sender ID records quickly. Margaret. From owner-ietf-mxcomp@mail.imc.org Wed Aug 18 23:04: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 XAA11624 for ; Wed, 18 Aug 2004 23:04: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 i7J2Zf9S089774; Wed, 18 Aug 2004 19:35:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J2Zfng089773; Wed, 18 Aug 2004 19:35:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J2Ze1B089767 for ; Wed, 18 Aug 2004 19:35:40 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B5B3C16E0B for ; Wed, 18 Aug 2004 22:44:14 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Solution For Trojans In-Reply-To: Your message of "Wed, 18 Aug 2004 16:39:48 PDT." <1092872388.20821.82.camel@ddev.mail-abuse.org> Date: Wed, 18 Aug 2004 22:44:14 -0400 Message-Id: <20040819024414.B5B3C16E0B@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > When transparent interception is not used by network providers, Trojans > are free to submit mail from compromised machines without detection. Which would appear to be outside of the scope of MARID. > Sender-ID attempts to change the paradigm of being able to use a mailbox > address as an identifier from any point of access. That's only part of the truth. It changes the paradigm of being able to use SMTP from any point of access to submit messages to an MTA you don't have a previous relationship with, UNLESS the domain hosting your mailbox (as determined by PRA) publishes a policy saying you are permitted to send mail. The additional qualifiers are part of the proposal, and leaving them out distorts any description of the proposal. I still like Hadmut's comment in his RMX draft, and think it's generally true: If you (i.e. an administrative locale) are not going to accept mail via SMTP, you shouldn't be sending mail via SMTP. We've had SUBMIT for years. Let's encourage people to use it, and leave MARID to address the issue of enabling sending MTA's to accountably communicate with receiving MTA's. > Just as these Trojans exploit thousands of mailbox addresses, these > mailboxes can be culled from a list with "open" records. There would be > no single DNS to enable a shut-down. In addition, these mailbox records > and DNS servers likely represent legitimate users. These users would > react to retaliation tactics, Like the DNS owners realizing that their bad policies are giving them a bad name, and updating their policies? You're assuming that the only possible method of dealing with bad policies is for a third party to "retaliate". I see that assumption as unnecessarily pessimistic. > Unlike Sender-ID, CSV does not change mail paradigms Sender-Id interacts with only the parties involved in an SMTP conversation: sender, receiver, and (as a new paradigm) the domain(s) who's names are (ab)used in the conversation. In that respect, CSV-CSA is identical. > As providers are not required to create an "open" list to > authenticate the MTA when using CSV and MPR, there is no record > available to enable an exploit. Other methods do not require an "open" list, but they do permit it. In that way, they are more flexible than CSV and MPR, and therefore as a side effect, more open to abuse. These are common trade-offs in protocol design. We need quantifiable reasons to pick one design over the other. Some proposals have been deployed for many months, and other have not. This difference makes it difficult to quantitatively compare methods as implemented. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 00:05: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 AAA14605 for ; Thu, 19 Aug 2004 00:05: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 i7J3fsMv000184; Wed, 18 Aug 2004 20: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 i7J3fsQI000183; Wed, 18 Aug 2004 20:41:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J3frEY000176 for ; Wed, 18 Aug 2004 20:41:53 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id i7J3fxEU002724; Wed, 18 Aug 2004 23:41:59 -0400 In-Reply-To: <20040816033758.GL28401@dumbo.pobox.com> References: <20040816033758.GL28401@dumbo.pobox.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: MARID From: "Anne P. Mitchell, Esq." Subject: Re: Reputation systems Date: Wed, 18 Aug 2004 20:41:55 -0700 To: Meng Weng Wong X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Things have moved fast since I wrote that document. > Cloudmark has announced > http://rating.cloudmark.com/senderid/ (a domain-name-based > reputation service) and Verisign has announced its VDL (a > first approximation to domain-name-based accreditation). Please also don't forget ISIPP's IDDB (ISIPP Domain Database) which presently lists domains (both top level alone, and with subdomain) and both declares the only IP addresses through which mail from that domain may properly issue, and cross-references to the IADB and IADB data (making it also true domain-name-based accreditation). Anne From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 02:50:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06162 for ; Thu, 19 Aug 2004 02:50: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 i7J6Guu5023932; Wed, 18 Aug 2004 23:16:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J6Guvc023931; Wed, 18 Aug 2004 23:16:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J6GlbJ023913 for ; Wed, 18 Aug 2004 23:16:50 -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 B041741497; Wed, 18 Aug 2004 23:16:55 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Wed, 18 Aug 2004 23:16:55 -0700 (PDT) Message-ID: <1104.64.142.13.68.1092896215.squirrel@harry.mail-abuse.org> In-Reply-To: <20040819024414.B5B3C16E0B@mail.nitros9.org> References: Your message of "Wed, 18 Aug 2004 16:39:48 PDT." <1092872388.20821.82.camel@ddev.mail-abuse.org> <20040819024414.B5B3C16E0B@mail.nitros9.org> Date: Wed, 18 Aug 2004 23:16:55 -0700 (PDT) Subject: Re: Solution For Trojans From: "Douglas Otis" To: "Alan DeKok" Cc: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "Alan DeKok" wrote: > Douglas Otis wrote: >> >> When transparent interception is not used by network providers, Trojans >> are free to submit mail from compromised machines without detection. > > Which would appear to be outside of the scope of MARID. By attempting to map the mail channel to a mailbox domain, the normal practices of handling mail are affected. Sender-ID is attempting to use RFC2822 content as a means of authenticating the MTA. Had the MTA been directly authenticated, there would not be a conflict which makes this issue relevant to MARID. >> Sender-ID attempts to change the paradigm of being able to use a mailbox >> address as an identifier from any point of access. > > That's only part of the truth. It changes the paradigm of being > able to use SMTP from any point of access to submit messages to an MTA > you don't have a previous relationship with, UNLESS the domain hosting > your mailbox (as determined by PRA) publishes a policy saying you are > permitted to send mail. The additional qualifiers are part of the > proposal, and leaving them out distorts any description of the > proposal. > > I still like Hadmut's comment in his RMX draft, and think it's > generally true: If you (i.e. an administrative locale) are not going > to accept mail via SMTP, you shouldn't be sending mail via SMTP. > > We've had SUBMIT for years. Let's encourage people to use it, and > leave MARID to address the issue of enabling sending MTA's to > accountably communicate with receiving MTA's. The technique of using RFC2822 content to identify the MTA will lead to errors and is based upon a premise such content has not been spoofed between MTAs. There is no means within this standard to hold a particular MTA accountable. >> Just as these Trojans exploit thousands of mailbox addresses, these >> mailboxes can be culled from a list with "open" records. There would be >> no single DNS to enable a shut-down. In addition, these mailbox records >> and DNS servers likely represent legitimate users. These users would >> react to retaliation tactics, > > Like the DNS owners realizing that their bad policies are giving > them a bad name, and updating their policies? These are not errors of policy. These are errors built into the standard. > You're assuming that the only possible method of dealing with bad > policies is for a third party to "retaliate". I see that assumption > as unnecessarily pessimistic. Those being black-listed are not provided a means to ensure the integrity of the mail channel down stream. It could easily be within the recipients realm that spoofed identities are injected. The indirect method of identifying the MTA may lead to grevious errors where perhaps legal retaliation becomes the only available option, should an guiltless party become blacklisted out of the caviler confidence of the mail channel integrity. >> Unlike Sender-ID, CSV does not change mail paradigms > > Sender-Id interacts with only the parties involved in an SMTP > conversation: sender, receiver, and (as a new paradigm) the domain(s) > who's names are (ab)used in the conversation. In that respect, > CSV-CSA is identical. CSV-CSA deals directly with the entity sending the mail, and not indirectly based upon RFC2822 content. This restriction placed upon the RFC2822 content by the recipient with respect to the a prescibed mail channel is a new paradigm. CSV is still dealing directly with the MTA without imposing such restrictions and without the possibility of false implications of responsibilty. >> As providers are not required to create an "open" list to >> authenticate the MTA when using CSV and MPR, there is no record >> available to enable an exploit. > > Other methods do not require an "open" list, but they do permit it. > In that way, they are more flexible than CSV and MPR, and therefore as > a side effect, more open to abuse. I do not agree the Sender-ID's attempt to make a general rule for all mailbox domains to be bound to a mail channel is more flexible. In fact, the desire to prevent phishing and spoofing for finacial institutions, as example, is better addressed by MPR. MPR is far more flexible while not breaking mail. > These are common trade-offs in protocol design. We need > quantifiable reasons to pick one design over the other. Some > proposals have been deployed for many months, and other have not. > This difference makes it difficult to quantitatively compare methods > as implemented. This was my reason for creating a list of features. This effort should consider the impact of the current mail system and how this transitions. If there is to be an accreditation system, it better be defendable. I do not see how one could defend Sender-ID assessments. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 03:06:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07202 for ; Thu, 19 Aug 2004 03:06:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J6dg3V027738; Wed, 18 Aug 2004 23:39: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 i7J6dg9s027737; Wed, 18 Aug 2004 23:39: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 i7J6dgMU027731 for ; Wed, 18 Aug 2004 23:39: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 7B70C41497; Wed, 18 Aug 2004 23:39:42 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Wed, 18 Aug 2004 23:39:42 -0700 (PDT) Message-ID: <1114.64.142.13.68.1092897582.squirrel@harry.mail-abuse.org> In-Reply-To: <1CAFEF16-F185-11D8-8A10-000A95BC6A7E@margaretolson.com> References: <1CAFEF16-F185-11D8-8A10-000A95BC6A7E@margaretolson.com> Date: Wed, 18 Aug 2004 23:39:42 -0700 (PDT) Subject: Re: Forged Sender (Resent-From) attacks From: "Douglas Otis" To: "Margaret Olson" Cc: "Harry Katz" , 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 "Margaret Olson" wrote: > On Aug 18, 2004, at 6:30 PM, Harry Katz wrote: > >> To address the forged Sender/Resent problem I suggest we could add the >> following logic: >> >> If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY >> reject a message after DATA. > >> <...much good stuff snipped ...> > >> Thus, if a spammer wants to forge a Sender or Resent- header, they have >> to use their own domain name. That'll get block-listed fairly quickly. >> I belive that plugs the hole that we're addressing. > > This works. It for all practical purposes closes the hole whereby > incomplete or absent records for Sender and particularly Resent can be > used to dive under identity based controls in the temporary (but > undoubtedly not brief) period before Sender ID records are for all > practical purposes mandatory. > > My gut says that the people burdened - those running mail related > services - are those most likely to be able to publish definitive and > complete Sender ID records quickly. This implies once a record gets published, these domains may also become blacklisted. If there are MTAs shared by more than a single domain, then this MTA MUST compare these records against the PRA as a means to protect these domains. This also implies every MTA application must have a signed contract with Microsoft? It also suggests that when these records are "open" they may become blacklisted, as spammers are not required to use "their" records to spoof the system. By making statements that without a Sender-ID record, mail will be rejected should also include the statement that without a "closed" Sender-ID record, mail will be backlisted. Or to conclude, all ISPs will soon include a Resent-From header with their "closed" list. How would this Resent-From header be better or different than CSV? 500 DNS lookups or 1 DNS lookup? Many possible PRA headers, or one EHLO domain? IPR or no IPR? My gut says Sender-ID is the wrong approach. Call From:EHLO Mailer-ID. By moving to such a name based accreditation, a history can be established. If they are new, a go slow approach can minimize the potential damage. Sender-ID makes it easy for every message to assume a different identity and allows records to span large address spaces. CSV constrains such a dodge far better. MPR can put clamps on phishing and spoofing far better than Sender-ID with a single DNS lookup for the channel. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 03: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 DAA08705 for ; Thu, 19 Aug 2004 03:33:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J70CWw031840; Thu, 19 Aug 2004 00:00: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 i7J70Chg031839; Thu, 19 Aug 2004 00:00:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J70Cd3031828 for ; Thu, 19 Aug 2004 00:00:12 -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 i7J770VO005265; Thu, 19 Aug 2004 00:07:00 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7J770UC005262; Thu, 19 Aug 2004 00:07:00 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 19 Aug 2004 00:07:00 -0700 (PDT) From: "william(at)elan.net" To: Nate Leon cc: ietf-mxcomp@imc.org Subject: Re: Sender-ID and last hop validation 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, 18 Aug 2004, Nate Leon wrote: > Do I understand correctly that Sender-ID only authenticates the most > recent hop? In the simple case, this is the domain where the client > lives that sent the message. But in the more complex case, there may be > forwarding hosts in the middle. > > i.e. my receiving MTA will authenticate the SMTP client delivering the > message to me. Specifically, it will ask, is the IP address connecting > to me authorized to send mail for the domain listed in the Purported > Responsible Address? You understand correctly. MARID/SenderID and any similar technology (RMX, SPF, CSV, etc) based on concept of MTA IP authorization are alaways going to be one-hop only authentication. And there is nothing that can be done about that, since what is being authenticated is the ip address of the mail server in the current email hop. In order to do authentication of hop not directly preceding current one in email path, you must have an identity that comes from that hop that you can trust and verify to have been added during that hop and could not have been added (forged) by anyone else. This basicly means it has not be a cryptographic signature based verification. This is probably going to be focus of MASS IETF WG. I have also some slides at http://www.elan.net/~william/asrg/SecuringEmailPath.htm (its reworked version of previously published presentation), that show how in my view MARID (rather Unified SPF, as what is improperly listed in slides as MARID is really unified SPF) fit into securing email system. What is not clearly listed in slides, in that MARID work offers good features for internet mail system because of its low computational overhead. I've ran some tests on how much computational work is involved in different authentication methods. The results are not unexpected - first its clear that any cryptographic based signature verification (s/mime compared to yahoo dk for example) requires about same amount of work, or more precisely the computation work required is dependent on the size of the public key and if RSA or Diffie-Helman is used but not really dependent on the method of how signature is included and this computational work is even with low 384k keys is 10 times the work necessary to do most email body transformations or 20 times or more what it takes to just extract simple one-line header from the body. At the same time, the work necessary to actually go through email body text (and dely necessary before you can do it), is also not 0 compared to what happens when you re able to judge authenticity of email. The scale of computation work that exist is probably something like: 1 : Envelope-only check during transmission (RMX, SPF Classic, CSV) 5-10 : Quick body context check (known bad and good "From: header address from your personal list, reject based on known bad Subject phrase) 20-50 : Body context full check (spamphrase in body, boesian filters) 40-100 : Encryption based checks (S/MIME or PGP, Yahoo DK, etc) From all this and from common sense, clearly the quicker you can decide on validity of email and reject bad ones, the better. And in my view MARID goal is to provide lightweight mechanism with low computational overhead to be able to reject bad emails during SMTP transmission. Its a first step that may not be able to reliable authenticate sender in complex path, but at the same time 50% of emails are personal one sent person-person with basicly only one hop and there it can work perfectly (i.e. direct path cases from sender ISP MTA to recepient ISP MTA; sometimes sender may have multiple servers involved in transmission and recepient too may have filtering server, but these are "intranet" servers where no authenticaion is necessary - its the step from two independent networks that we need to be worried about). In such view if we create mechanism that works for 50% of current email cases with low computation overhead and avoids necessity to do more complex check that requires 20% more computational complexity, then we have done a lot of good towards authenticated email (this is alike RBL checks and email content checks - I use both with SBL and 5 other RBL checks during email transmission and afterwards sending email through spamassisin for more complex checks). Now to be able to authenticate sender several hopes away is what we'll need cryptography for. I do note that one highly publicided proposed cryptography method - yahoo dk - does not fit well into this because by its design (signature for entire body of email which can only be checked if that body does not change; but headers do change by email servers, forwarders or new ones added or additional body added to the end of email) it can also only work reliably for direct next hop check and that that is not what we want for cryptography to be used for when 20 times less computational method is available (I hope MASS IETF group will see it despite pressure of corporate interests involved and what will be developed is something for point-point authentication where points are expected to be MTAs that are often several hops away in email path). Now one last thing, is that BATV proposal (which proposes encryption of envelope mail from) is also cryptography based and that means it has a lot highier overhead then something like RMX or SPF Classic. But it does mean it will work reliably for multiple hopes, rather then just one hop. My view of this is that RMX or SPF Classic mail-from mechanisms should not be discarded (as they seem to be currently as part of MARID) but should be used as whitelisting mechanisms to avoid necessity to do more complex cryptographic verification - that is if RMX fails, the email should not be rejected, but instead its BATV signature should be checked in that case if it exists. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 03:53: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 DAA10318 for ; Thu, 19 Aug 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 i7J7LZih036136; Thu, 19 Aug 2004 00:21:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J7LZNK036135; Thu, 19 Aug 2004 00:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J7LYPv036095 for ; Thu, 19 Aug 2004 00:21:35 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7J7LOgQ032209 for ; Thu, 19 Aug 2004 08:21:24 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7J7LO9r032208; Thu, 19 Aug 2004 08:21:24 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Sender-ID and last hop validation References: <20040819020606.4EA0D16E0B@mail.nitros9.org> From: Graham Murray Date: Thu, 19 Aug 2004 08:21:24 +0100 In-Reply-To: <20040819020606.4EA0D16E0B@mail.nitros9.org> (Alan DeKok's message of "Wed, 18 Aug 2004 22:06:06 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Alan DeKok" writes: > If pobox has claimed responsibility for the message via the fields > used by PRA, then the MyWork MTA can verify that the message passes > the rules published by pobox.com. > > If pobox does not claim responsibility, and just forwards the > message without touching the PRA fields, then the message must pass > the rules published by the responsible domain as determined by PRA. > Odds are, because the message now comes from pobox, that it won't. So what happens if someone sets up a phisher friendly forwarding system which does not perform PRA tests on incoming mail but which generates valid PRA on the outgoing mail (ie adds a Resent-From: and SUBMITTER)? This mail would pass all the tests but still be a forgery. From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 04:29: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 EAA12368 for ; Thu, 19 Aug 2004 04:29: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 i7J7tXGj042137; Thu, 19 Aug 2004 00:55:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J7tXmJ042136; Thu, 19 Aug 2004 00:55:33 -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 i7J7tWM6042126 for ; Thu, 19 Aug 2004 00:55:32 -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 1Bxhld-000POm-00; Thu, 19 Aug 2004 08:55:25 +0100 Message-ID: <058901c485c1$9299c5b0$0200000a@ringo> From: "Chris Haynes" To: "Daryl Odnert" Cc: "IETF MARID WG" References: Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Thu, 19 Aug 2004 08:53:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0586_01C485C9.F2DE9290" 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: This is a multi-part message in MIME format. ------=_NextPart_000_0586_01C485C9.F2DE9290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Point of Order: Incomplete, flawed response to MARID WG = CharterDaryl, Perhaps it will help if I summarise my understanding of how Sender-ID = (and SPF) actually work. My example was of an outbound, stored message in which the PRA (e.g. = "From:") was forged. The "To:" address is that of a valid recipient. The 'Mail-From:' address is a real address, but that of an 'innocent = victim' who has no connection whatsoever with the small business or the = ISP. In Sender-ID (and in SPF) it is the policy of the domain which the = message claims to be from (the _Purported_ Responsible Address and the = Mail-From address respectively) which is consulted, not the policy of = the domain of the host attempting to send the message. So, as the message does not claim to come from the small business, it = does not matter one jot whether or not the small business has published = a record, and whether or not that record identifies the outbound MTA as = a valid sender of its messages. It will be the record of the domain which has been forged which will be = consulted, and as that domain's record will not have authorised this = particular MTA host to send its messages, the message will be rejected = and Sender-ID will have worked as required. However, with Sender_ID, the host which was attempting to send the = Original (stored) message will now create and send a Bounce message to = whatever address the forger decided to put into the Mail-From header. It = may well also put a full copy of the original message (including virus, = sexually-explicit spam, etc.) into that message. =20 That virus-carrying message will now be sent, unauthorised and unchecked = by Sender-ID, to whatever innocent victim was chosen by the forger.=20 This is the 'harm' that Sender-ID would be causing. If Sender-ID had = not been used, this second, virus-carrying message would not have been = created and sent.=20 Headline summary: Sender-ID propagates viruses! One really significant difference between Sender-ID and SPF is that SPF = prevents both messages being sent. =20 SPF inspects the Mail-From address and asks its domain record if the = host currently attempting to send the original message is authorised to = use that Mail-From address.=20 If the SPF test result is 'fail' (i.e. if the domain record derived from = the Mail-From address says "I _never_ use that host") the message is = proven to be unauthorised, the SMTP 'Deliver-or-Bounce' commitment is = null-and-void, so the outbound message is discarded and no bounce is = generated. To return to the essence of my original question to the Chair, Sender-ID = only seeks authority for the Original message. No authority is sought = for Bounce messages. SPF seeks authority for _both_ messages - thus covering the whole of the = MARID charter's problem-space. [Note, I use SPF solely as a 'proof-of-existence' of technology which = has demonstrated its ability to validate the authorities of both = messages. As far as I am aware, SPF has not formally been submitted to = the IETF, so has not yet undergone the rigorous engineering inspection = which Sender-ID is now undergoing. It would appear that there may also = be other as-yet-unsubmitted candidate technologies to be considered]. HTH Chris ----- Original Message -----=20 From: Daryl Odnert=20 To: 'Chris Haynes'=20 Cc: IETF MARID WG=20 Sent: Wednesday, August 18, 2004 6:55 PM Subject: RE: Point of Order: Incomplete, flawed response to MARID WG = Chart er Chris,=20 In your example, it wasn't clear to me whether or not the=20 the small business domain published a Sender ID policy=20 in the DNS.=20 Assuming the domain did not publish any policy data, the=20 receiving MTA cannot perform the Sender ID test if there=20 is no policy information in the DNS, so the message should=20 not be rejected with a 550 error unless it has is some other=20 good reason to do so.=20 On the other hand, if the domain did publish a Sender ID=20 policy and the message is rejected for policy reasons, then=20 either the policy data is inaccurate or the ISP is doing=20 something to the message that it shouldn't be doing.=20 So, I still don't understand the crux of your complaint=20 about Sender ID here. How is Sender ID causing any harm=20 to anyone here?=20 Daryl Odnert=20 Tumbleweed Communications=20 Redwood City, California=20 =3D=3D=3D=3D=20 Chris' example:=20 Small business: (Virus on) End user MUA sends message to internal = MTA, which=20 stores-and-forwards message to public-facing MTA of the business' ISP. = This ISP-MTA has not implemented Sender-ID, so does no know that the = PRA will=20 later be detected as a forgery. This ISP is generally slack about = security,=20 adding Resent-From headers, etc.=20 ISP-MTA accepts message for onward delivery, cannot initially contact=20 destination MTA, stores message and undertakes to try again later.=20 Second attempt to contact destination MTA succeeds.=20 Destination MTA applies Sender-ID, rejects message during SMTP = protocol exchange=20 with a '550'.=20 ISP-MTA notes the '550' and fulfils its 'contract' by generating a = non-delivery=20 "Bounce" message, which is sent to the address in "Mail-From" in the = original=20 (virus-generated?) message.=20 ------=_NextPart_000_0586_01C485C9.F2DE9290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Point of Order: Incomplete, flawed response to = MARID WG Charter
Daryl,
 
Perhaps it will help if I summarise my=20 understanding of how Sender-ID (and SPF) actually work.
 
My example was of an outbound, = stored message=20 in which the PRA (e.g. "From:") was forged.
 
The "To:" address is that of a valid=20 recipient.
 
The 'Mail-From:' address is a real = address, but=20 that of an 'innocent victim' who has no connection whatsoever with the = small=20 business or the ISP.
 
 
In Sender-ID (and in SPF) it is the = policy of the=20 domain which the message claims to be from (the _Purported_ Responsible=20 Address and the Mail-From address respectively) which is consulted, = not the=20 policy of the domain of the host attempting to send the = message.
 
So, as the message does not claim to = come from the=20 small business, it does not matter one jot whether or not the small = business has=20 published a record, and whether or not that record identifies the = outbound MTA=20 as a valid sender of its messages.
 
It will be the record of the domain = which has been=20 forged which will be consulted, and as that domain's record will not = have=20 authorised this particular MTA host to send its messages, the message = will be=20 rejected and Sender-ID will have worked as required.
 
However, with Sender_ID, the host which = was=20 attempting to send the Original (stored) message will now create and = send a=20 Bounce message to whatever address the forger decided to put into the = Mail-From=20 header. It may well also put a full copy of the original message = (including=20 virus, sexually-explicit spam, etc.) into that message.  =
 
That virus-carrying message will now be = sent,=20 unauthorised and unchecked by Sender-ID, to whatever innocent victim was = chosen=20 by the forger.
 
This is the 'harm' that = Sender-ID would=20 be causing.  If Sender-ID had not been used, this second,=20 virus-carrying message would not have been created and sent. =
 
Headline summary: Sender-ID propagates=20 viruses!
 
One really significant difference = between=20 Sender-ID and SPF is that SPF prevents both messages being = sent. =20
 
SPF inspects the Mail-From address and = asks its=20 domain record if the host currently attempting to send the original = message is=20 authorised to use that Mail-From address. 
 
If the SPF test result is = 'fail' (i.e. if=20 the domain record derived from the Mail-From address says "I = _never_=20 use that host") the message is proven to be unauthorised, the SMTP=20 'Deliver-or-Bounce' commitment is null-and-void, so the outbound message = is=20 discarded and no bounce is generated.
 
 
To return to the essence of my original = question to=20 the Chair, Sender-ID only seeks authority for the Original message. No = authority=20 is sought for Bounce messages.
 
SPF seeks authority for _both_ messages = - thus=20 covering the whole of the MARID charter's problem-space.
 
 
[Note, I use SPF solely as a = 'proof-of-existence'=20 of technology which has demonstrated its ability to validate = the=20 authorities of both messages. As far as I am aware, SPF has not = formally=20 been submitted to the IETF, so has not yet undergone the rigorous = engineering=20 inspection which Sender-ID is now undergoing. It would appear that there = may=20 also be other as-yet-unsubmitted candidate technologies to be=20 considered].
 
HTH
 
Chris
 
----- Original Message -----
From:=20 Daryl Odnert
Sent: Wednesday, August 18, = 2004 6:55=20 PM
Subject: RE: Point of Order: = Incomplete,=20 flawed response to MARID WG Chart er

Chris,

In your example, it wasn't clear to me whether or = not=20 the
the small business domain published a = Sender ID=20 policy
in the DNS.

Assuming the domain did not publish any policy data, = the
receiving MTA cannot perform the Sender = ID test if=20 there
is no policy information in the DNS, = so the=20 message should
not be rejected with a 550 = error unless=20 it has is some other
good reason to do = so.

On the other hand, if the domain did publish a = Sender=20 ID
policy and the message is rejected for = policy=20 reasons, then
either the policy data is = inaccurate or=20 the ISP is doing
something to the message = that it=20 shouldn't be doing.

So, I still don't understand the crux of your = complaint=20
about Sender ID here.  How is Sender ID = causing any=20 harm
to anyone here?

Daryl Odnert
Tumbleweed=20 Communications
Redwood City, = California

=3D=3D=3D=3D
Chris' = example:

Small business:  (Virus on) End user MUA sends = message to=20 internal MTA, which
stores-and-forwards = message to=20 public-facing MTA of the business' ISP.

This ISP-MTA has not implemented Sender-ID, so does = no know=20 that the PRA will
later be detected as a = forgery. This=20 ISP is generally slack about security,
adding=20 Resent-From headers, etc.

ISP-MTA accepts message for onward delivery, cannot = initially=20 contact
destination MTA, stores message and = undertakes=20 to try again later.

Second attempt to contact destination MTA = succeeds.=20

Destination MTA applies Sender-ID, rejects message = during SMTP=20 protocol exchange
with a '550'.

ISP-MTA notes the '550' and fulfils its 'contract' = by=20 generating a non-delivery
"Bounce" message, = which is=20 sent to the address in "Mail-From" in the original
(virus-generated?) message. =

------=_NextPart_000_0586_01C485C9.F2DE9290-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 04:53: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 EAA13691 for ; Thu, 19 Aug 2004 04:53: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 i7J8ORpn049770; Thu, 19 Aug 2004 01:24: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 i7J8OR5l049769; Thu, 19 Aug 2004 01:24:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7J8OQIe049756 for ; Thu, 19 Aug 2004 01:24:27 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 17CA51A6BB; Thu, 19 Aug 2004 10:24:26 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id D7E921A6B6 for ; Thu, 19 Aug 2004 10:24:23 +0200 (CEST) Message-Id: Date: Thu, 19 Aug 2004 10:24:42 +0200 From: Arnt Gulbrandsen To: ietf-mxcomp@imc.org Subject: Re: IP Address spoofing References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nate Leon writes: > I am not an IP expert, so I defer to those on this list who have such > expertise. It seems like folks on this list are not so concerned > about spammers/fraudsters spoofing IP addresses, and that brings me > some comfort. :) I believe the success of Sender-ID assumes spammers > cannot spoof IP Addresses. > > I understand this is not easy to do. My concern is the degree of > difficulty/expense it takes to do so. It requires injecting routes into the main BGP net. Every notable ISP can do that, and can let some of its customers do that. Say 20,000 organizations in all have the ability to do that. Most of the people who've engaged in such practices seem to be listed on http://www.completewhois.com/hijacked/hijackers.htm - at least the incidents I've heard about are listed there. > e.g. how difficult is it for the spammer to get the whole transaction > into a single packet so they can ignore return messages (blind > attack), forge the packet's source address, get it through firewalls > and routers that don't verify the source address, guess the sequence > number, etc... Can't be done using any TCP common implementation. > Or will it just be easier for them to write viruses/worms which carry > spam-bots as their payload?! Quite likely, IMHO. Arnt From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 05:12: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 FAA14461 for ; Thu, 19 Aug 2004 05:12: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 i7J8keGk057791; Thu, 19 Aug 2004 01:46:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J8ke5e057790; Thu, 19 Aug 2004 01:46:40 -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 i7J8kdoU057773 for ; Thu, 19 Aug 2004 01:46:39 -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 1BxiZ2-0003xX-00; Thu, 19 Aug 2004 09:46:28 +0100 Message-ID: <05b801c485c8$b435bab0$0200000a@ringo> From: "Chris Haynes" To: "Harry Katz" Cc: "Nate Leon" , References: Subject: Re: Forged Sender (Resent-From) attacks Date: Thu, 19 Aug 2004 09:44:03 +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 On Wednesday, August 18, 2004 at 11:30 PM "Harry Katz" wrote: > > - More importantly, this allow us to give much clearer directions to > senders in terms of what to publish. You publish the IP addresses of > servers authorized to send mail on behalf of your domain. We're not > trying to mix this up with the IP addresses of servers that receive > bounce messages on behalf of your domain. > Harry, There's a VERY important point here. I presume that when you talk of "IP addresses of servers that receive bounce messages on behalf of your domain" you are referring to the SPF records. You and I seem to have a significantly different understanding of how SPF works. In my understanding, a 'pass' result from a call of SPF's check_host(IP, DOMAIN, SENDER) function, with DOMAIN and SENDER derived from the MailFrom: address has the following semantics: "The domain DOMAIN authorises the host IP to *originate* messages whose Mail-From address is SENDER". SPF is not designating "servers that receive". Just like Sender-ID it is designating servers which are authorised to send. The semantic differences between the two authorities are actually very subtle, and it is my understanding from discussions on the spf-discuss list that the majority of sites could have identical records for both tests - which is why it so galls many knowledgable observers that the IETF seems determined to proceed with an approach which _forces_ two sets of usually-identical records to be established and maintained. This is not the time and place to explore the circumstances under which the records would be different - it needs extensive, detailed UseCase analysis (and for SPF to have been submitted to the IETF?). Significant questions: ============= Is it possible that, all along, there has been a fundamental misunderstanding of SPF amongst the designers of Sender-ID? If so (and these misunderstandings were corrected), is there an engineering opportunity to work towards a sympathetic fusion of Sender-ID and SPF *at this time*? Yours optimistically, Chris Haynes From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 05:39:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16022 for ; Thu, 19 Aug 2004 05:39:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J9EhB2069166; Thu, 19 Aug 2004 02: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 i7J9EhkR069165; Thu, 19 Aug 2004 02:14:43 -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 i7J9Eh3p069142 for ; Thu, 19 Aug 2004 02:14:43 -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 1Bxj0I-000PHx-00; Thu, 19 Aug 2004 10:14:38 +0100 Message-ID: <05c701c485cc$a3a44190$0200000a@ringo> From: "Chris Haynes" To: "Nate Leon" Cc: References: Subject: Re: IP Address spoofing Date: Thu, 19 Aug 2004 10:12:23 +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 "Nate Leon" observed: > I saw one vendor who claims to > have a sample, fraudulent message claiming to be from US Bank where the > IP address was spoofed. > These reports are achieving the status of Urban Myths. When a report sounding very much like the one you reference was referred to the experts on spf-discuss, and the purported log file (published as a flash animation!) was analysed, they concluded that there was no evidence of IP address spoofing, and that the people who had published the log and claimed evidence of spoofing had made a number of elementary mistakes in their analysis of the logged SMTP dialog. Without direct, validated evidence I would discount all such reports. They spread corrosive FUD. Chris From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 06:07: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 GAA17148 for ; Thu, 19 Aug 2004 06:07: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 i7J9a7CV075953; Thu, 19 Aug 2004 02:36:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J9a77T075952; Thu, 19 Aug 2004 02:36:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J9a5Fx075912 for ; Thu, 19 Aug 2004 02:36:06 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7J9a1Ov001282 for ; Thu, 19 Aug 2004 10:36:01 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7J9a1RG001281; Thu, 19 Aug 2004 10:36:01 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Forged Sender (Resent-From) attacks References: <05b801c485c8$b435bab0$0200000a@ringo> From: Graham Murray Date: Thu, 19 Aug 2004 10:36:01 +0100 In-Reply-To: <05b801c485c8$b435bab0$0200000a@ringo> (Chris Haynes's message of "Thu, 19 Aug 2004 09:44:03 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Chris Haynes" writes: > If so (and these misunderstandings were corrected), is there an engineering > opportunity to work towards a sympathetic fusion of Sender-ID and SPF *at this > time*? Do not forget that Sender-ID is supposed to already be a fusion of SPF and the original MicroSoft Caller-ID. From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 06:58: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 GAA20249 for ; Thu, 19 Aug 2004 06:58: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 i7JATShD093979; Thu, 19 Aug 2004 03: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 i7JATSSC093978; Thu, 19 Aug 2004 03:29:28 -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 i7JATR8E093957 for ; Thu, 19 Aug 2004 03:29:27 -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 1BxkAh-0009Vx-00; Thu, 19 Aug 2004 11:29:28 +0100 Message-ID: <066101c485d7$17a7c3f0$0200000a@ringo> From: "Chris Haynes" To: "Graham Murray" Cc: References: <05b801c485c8$b435bab0$0200000a@ringo> Subject: Re: Forged Sender (Resent-From) attacks Date: Thu, 19 Aug 2004 11:27:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "Graham Murray" commented: > > "Chris Haynes" writes: > > > If so (and these misunderstandings were corrected), is there an engineering > > opportunity to work towards a sympathetic fusion of Sender-ID and SPF *at this > > time*? > > Do not forget that Sender-ID is supposed to already be a fusion of SPF > and the original MicroSoft Caller-ID. > Hello Graham, What do you mean by "supposed"? "required"? "alleged"? "presumed"? As far as I can tell, Sender-ID has adopted some of SPF's better implementation ideas, including: - The record and macro formats - The opportunity for early rejection (with the SUBMITTER option) but, functionally, it still tests a different entity (the PRA vs. the Mail-From: address) and thus has the 'unauthorised bounce' weakness that many people are concerned about. There may be other significant differences - I've not done that detailed an analysis. Then there is the licensing issue: I don't think any Open Source advocate would describe the current Sender-ID as a "sympathetic fusion" of the two approaches to licencing. Note also Meng's post of http://www.imc.org/ietf-mxcomp/mail-archive/msg03093.html which seems to indicate that Meng believed (on 6 Aug) that there was still a substantive difference between Sender-ID and his conception of "Unified spf". Chris Haynes From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 08:23: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 IAA26251 for ; Thu, 19 Aug 2004 08:23: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 i7JBmqNp027514; Thu, 19 Aug 2004 04:48: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 i7JBmqhk027513; Thu, 19 Aug 2004 04:48:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBmp5p027452 for ; Thu, 19 Aug 2004 04:48:51 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7JBmiD9002917 for ; Thu, 19 Aug 2004 12:48:44 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7JBmiFm002916; Thu, 19 Aug 2004 12:48:44 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Forged Sender (Resent-From) attacks References: <05b801c485c8$b435bab0$0200000a@ringo> <066101c485d7$17a7c3f0$0200000a@ringo> From: Graham Murray Date: Thu, 19 Aug 2004 12:48:44 +0100 In-Reply-To: <066101c485d7$17a7c3f0$0200000a@ringo> (Chris Haynes's message of "Thu, 19 Aug 2004 11:27:13 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Chris Haynes" writes: > What do you mean by "supposed"? > > "required"? > "alleged"? > "presumed"? alleged. > Then there is the licensing issue: I don't think any Open Source advocate would > describe the current Sender-ID as a "sympathetic fusion" of the two approaches > to licencing. It also does not help that Microsoft have kept delaying telling us exactly what is covered by their claimed IPR. > Note also Meng's post of > http://www.imc.org/ietf-mxcomp/mail-archive/msg03093.html > which seems to indicate that Meng believed (on 6 Aug) that there was still a > substantive difference between Sender-ID and his conception of "Unified spf". I may be wrong about this, but I think that since the original merger of SPF and Caller-ID to form Sender-ID that (with one notable exception - the use of XML) Sender-ID has diverged considerably from SPF (hence the 'supposed' in my original email). In my opinion (which probably counts for almost nothing) this divergence has not been an improvement. From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 10:15: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 KAA04709 for ; Thu, 19 Aug 2004 10:15: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 i7JDdlhD072260; Thu, 19 Aug 2004 06:39: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 i7JDdltf072259; Thu, 19 Aug 2004 06:39:47 -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 i7JDdi0O072230 for ; Thu, 19 Aug 2004 06:39:45 -0700 (PDT) (envelope-from roy+dated+1095514778.298ea9@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7JDf4gY040163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Aug 2004 13:41:10 GMT (envelope-from roy+dated+1095514778.298ea9@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7JDdchS083300 for ; Thu, 19 Aug 2004 14:39:38 +0100 (BST) (envelope-from roy+dated+1095514778.298ea9@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7JDdcXr083299 for ietf-mxcomp@imc.org; Thu, 19 Aug 2004 14:39:38 +0100 (BST) (envelope-from roy+dated+1095514778.298ea9@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 19 Aug 2004 14:39:36 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16676.44440.161225.346881@giles.gnomon.org.uk> Date: Thu, 19 Aug 2004 14:39:36 +0100 To: "Chris Haynes" Cc: "Daryl Odnert" , "IETF MARID WG" Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Chart er In-Reply-To: <058901c485c1$9299c5b0$0200000a@ringo> References: <058901c485c1$9299c5b0$0200000a@ringo> 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 >>>>> "Chris" == Chris Haynes writes: Chris> That virus-carrying message will now be sent, unauthorised Chris> and unchecked by Sender-ID, to whatever innocent victim was Chris> chosen by the forger. Chris> This is the 'harm' that Sender-ID would be causing. If Chris> Sender-ID had not been used, this second, virus-carrying Chris> message would not have been created and sent. Backscatter (ie bounce messages sent to forged addresses) is already a _huge_ problem for many people, and will need to be solved whatever happens in the MARID front. People are working on it (schemes that modify the MAIL FROM such as BATV or SES, schemes that keep track of Message-IDs, schemes that add additional tracking headers). Your argument basically boils down to saying I should never reject any SMTP transaction because it might result in backscatter. I don't buy it. Backscatter is a problem; let's fix it (but not here). -roy From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 10:59:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08128 for ; Thu, 19 Aug 2004 10:59:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JEVnhp094004; Thu, 19 Aug 2004 07:31:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JEVnIG094003; Thu, 19 Aug 2004 07:31:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ddg.com (mail.ddg.com [66.93.83.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JEVmEO093946 for ; Thu, 19 Aug 2004 07:31:48 -0700 (PDT) (envelope-from awd@DDG.com) Received: from [192.168.1.35] (account awd HELO [192.168.1.35]) by ddg.com (CommuniGate Pro SMTP 4.2) with ESMTP id 1515105 for ietf-mxcomp@imc.org; Thu, 19 Aug 2004 09:29:37 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IETF MARID WG Message-Id: <319B86FE-F1EC-11D8-B8A5-000A9566A350@DDG.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2-801942137 From: "Andrew W. Donoho" Subject: There can be more than one Date: Thu, 19 Aug 2004 09:29:35 -0500 X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-801942137 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Folks, Admittedly, I am new to this IETF process but it appears to be substantially different than other standards processes with which I have been involved (W3C, UPnP and, cursorily, OASIS). In the IETF, because it is a "running code" organization, there appears to be a standard practice that multiple protocol additions can be in process at the same time. Furthermore, multiple mechanisms are frequently deployed on the network. For example, while Sender-ID is going out the door "first", it is to be quickly followed by MPR (nee CSV-BATV?). Both of these have been preceded in implementation by SPF Classic. We are now entering the implementation phase of these standards. In the race for anti-MTA forgery technology (RFC2821 time IP Authorization), SPF Classic is clearly ahead. Sender-ID barely addresses anti-MTA forgery at all. In the race for trying to solve the anti-phishing problem, Sender-ID provides one extra step that will need to be buttressed by whatever IETF MASS WG produces. In other words, in classic IETF fashion, the pieces will sort themselves out, based on efficacy/utility, on the network. With respect to the above, I would suggest that SPF Classic be resubmitted to MARID as an anti-MTA forgery technology. The SPF/Microsoft deal to eventually support MAIL FROM checking (as judged by Mr. Lyons recent comments on this list) does not appear to exist. We need both RFC 2821 and RFC 2822 time checking. We will be considering MPR (which attempts to do both) in the near future. The engineering process for effective anti-spam technology is just beginning. Andrew P.S. For those on this list who fear Microsoft's market power, you should just relax. Yes, Microsoft has a huge amount of market leverage. Yes, they will be able to modify both Outlook and Outlook Express to advertise the PRA. Yet, they also suffer from real economic forces. Changes to MUAs cost them and their customer's money, time and labor. Therefore, changes are not done lightly. If Sender-ID does not really solve the problem (which is quite intractable and, therefore, unlikely to be solved by any one approach), then IETF will layer multiple solutions to narrow the areas where spamming can occur. This will be a net improvement. Anything that reduces noise in the mail system will improve dynamic filtering. The incidence of false positives will go down because the differences between real mail and spam will be clearer to automatic analysis systems. P.P.S. For those of you concerned about the costs of accreditation/reputation systems, you should just relax. If, as a small volume email source, you advertise your MX, reverse DNS, SPF Classic, MPR and Sender-ID records, then you have an extremely good chance of getting through anti-spam filters - you will not incur dynamic scoring penalties that would push your email into the spam category. P.P.P.S. For those of you concerned about even one false positive, you should just relax. There is no pure technical fix that allows the unsolicited nature of email to continue. We just need to make sure that bouncing and non-delivery messages work properly so that the sender really does know if his/her mail got through. If they get the bounce/DSN, then users can use other means of communication, like the telephone or fax, to open up the channel. (For those CEOs who are expecting important correspondence from forwarders, this will sort itself out. People who do business via forwarded domains will chose forwarding vendors that help them get their email through anti-spam filters. Frankly, I do not know any CEOs that would trust the unencrypted email system today to reliably transmit business critical information, such as a digitally signed contract. These messages, if they go over email, will be encrypted with keys to well known business partners. The spam filters, because well known business partners are whitelisted, will leave these messages alone.) ____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-2-801942137 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Folks, Admittedly, I am new to this IETF process but it appears to be substantially different than other standards processes with which I have been involved (W3C, UPnP and, cursorily, OASIS). In the IETF, because it is a "running code" organization, there appears to be a standard practice that multiple protocol additions can be in process at the same time. Furthermore, multiple mechanisms are frequently deployed on the network. For example, while Sender-ID is going out the door "first", it is to be quickly followed by MPR (nee CSV-BATV?). Both of these have been preceded in implementation by SPF Classic. We are now entering the implementation phase of these standards. In the race for anti-MTA forgery technology (RFC2821 time IP Authorization), SPF Classic is clearly ahead. Sender-ID barely addresses anti-MTA forgery at all. In the race for trying to solve the anti-phishing problem, Sender-ID provides one extra step that will need to be buttressed by whatever IETF MASS WG produces. In other words, in classic IETF fashion, the pieces will sort themselves out, based on efficacy/utility, on the network. With respect to the above, I would suggest that SPF Classic be resubmitted to MARID as an anti-MTA forgery technology. The SPF/Microsoft deal to eventually support MAIL FROM checking (as judged by Mr. Lyons recent comments on this list) does not appear to exist. We need both RFC 2821 and RFC 2822 time checking. We will be considering MPR (which attempts to do both) in the near future. The engineering process for effective anti-spam technology is just beginning. Andrew P.S. For those on this list who fear Microsoft's market power, you should just relax. Yes, Microsoft has a huge amount of market leverage. Yes, they will be able to modify both Outlook and Outlook Express to advertise the PRA. Yet, they also suffer from real economic forces. Changes to MUAs cost them and their customer's money, time and labor. Therefore, changes are not done lightly. If Sender-ID does not really solve the problem (which is quite intractable and, therefore, unlikely to be solved by any one approach), then IETF will layer multiple solutions to narrow the areas where spamming can occur. This will be a net improvement. Anything that reduces noise in the mail system will improve dynamic filtering. The incidence of false positives will go down because the differences between real mail and spam will be clearer to automatic analysis systems. P.P.S. For those of you concerned about the costs of accreditation/reputation systems, you should just relax. If, as a small volume email source, you advertise your MX, reverse DNS, SPF Classic, MPR and Sender-ID records, then you have an extremely good chance of getting through anti-spam filters - you will not incur dynamic scoring penalties that would push your email into the spam category. P.P.P.S. For those of you concerned about even one false positive, you should just relax. There is no pure technical fix that allows the unsolicited nature of email to continue. We just need to make sure that bouncing and non-delivery messages work properly so that the sender really does know if his/her mail got through. If they get the bounce/DSN, then users can use other means of communication, like the telephone or fax, to open up the channel. (For those CEOs who are expecting important correspondence from forwarders, this will sort itself out. People who do business via forwarded domains will chose forwarding vendors that help them get their email through anti-spam filters. Frankly, I do not know any CEOs that would trust the unencrypted email system today to reliably transmit business critical information, such as a digitally signed contract. These messages, if they go over email, will be encrypted with keys to well known business partners. The spam filters, because well known business partners are whitelisted, will leave these messages alone.) Helvetica____________________________________ Andrew W. Donoho awd@DDG.com, PGP Key ID: 0x81D0F250 +1 (512) 453-6652 (o), +1 (512) 750-7596 (m) --Apple-Mail-2-801942137-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 11:11: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 LAA08880 for ; Thu, 19 Aug 2004 11:11: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 i7JEgbvY098544; Thu, 19 Aug 2004 07:42: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 i7JEgblS098543; Thu, 19 Aug 2004 07:42:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JEgSIM098477 for ; Thu, 19 Aug 2004 07:42:30 -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 C1C0A16E0B for ; Thu, 19 Aug 2004 10:50:59 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Sender-ID and last hop validation In-Reply-To: Your message of "Thu, 19 Aug 2004 08:21:24 BST." Date: Thu, 19 Aug 2004 10:50:59 -0400 Message-Id: <20040819145059.C1C0A16E0B@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Graham Murray wrote: > So what happens if someone sets up a phisher friendly forwarding > system which does not perform PRA tests on incoming mail but which > generates valid PRA on the outgoing mail (ie adds a Resent-From: > and SUBMITTER)? This mail would pass all the tests but still be a > forgery. Then that forwarding server would be publicly recognized as claiming accountability for the mail. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 11:31: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 LAA10236 for ; Thu, 19 Aug 2004 11:31: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 i7JF7NuA009419; Thu, 19 Aug 2004 08:07: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 i7JF7NKF009418; Thu, 19 Aug 2004 08:07:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JF7M7v009396 for ; Thu, 19 Aug 2004 08:07:23 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7JF7Hwg013222 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 Aug 2004 11:07:20 -0400 Date: Thu, 19 Aug 2004 11:07:17 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Arnt Gulbrandsen cc: ietf-mxcomp@imc.org Subject: Re: IP Address spoofing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 19 Aug 2004, Arnt Gulbrandsen wrote: > Nate Leon writes: > > I am not an IP expert, so I defer to those on this list who have such > > expertise. It seems like folks on this list are not so concerned > > about spammers/fraudsters spoofing IP addresses, and that brings me > > some comfort. :) I believe the success of Sender-ID assumes spammers > > cannot spoof IP Addresses. To a limited extent, it is easy. If you are on a company lan, and it has say, a /24, it is trivial to become the other addresses in the /24. If you are on colo, it is often easy to become another IP in the colo. Some ISPs take some countermeasures to prevent this, others don't. If you are on DSL, it is frequently trivial to become any other IP in the DSL net. Some providers have countermeasures. Others don't. Even the countermeasures frequently allow stolen PPOE accounts to be used on any DSL port in the lata, if you also know the ethernet MAC address. DSL is like one big lan with a single virtual switch. Things are worse for cable because sniffing is easier. > > I understand this is not easy to do. My concern is the degree of > > difficulty/expense it takes to do so. > > It requires injecting routes into the main BGP net. It does not require this. This is just one way. > Every notable ISP can do that, and can let some of its customers do > that. Say 20,000 organizations in all have the ability to do that. Actually the AS numbers are past 30000 now. > > e.g. how difficult is it for the spammer to get the whole transaction > > into a single packet so they can ignore return messages (blind > > attack), forge the packet's source address, get it through firewalls > > and routers that don't verify the source address, guess the sequence > > number, etc... > > Can't be done using any TCP common implementation. Spoofing can be done with some implementations that have predictable sequence numbers. Linux is hard. BSD is hard. But some other things are quite predictable in sequence numbers. But this sort of security is also much improved from what it was in, say, the early 90s. Spoofing can also be done easily if you can sniff packets in the path to the real address. In that case, you can see the return packets, and get the sequence number directly. This was easy back to the days when the backbone links ran on thick ethernet down the basement halls of some prestigious universities. However, physical security is much better these days than it used to be. Cable operators also have difficult problem with sniffing. > > Or will it just be easier for them to write viruses/worms which carry > > spam-bots as their payload?! > > Quite likely, IMHO. The easier things happen more frequently than the harder things. Sending email with a virus is much easier and than TCP spoofing, and the outcome is the same: an infected machine. Frequently, the control channels are just passworded IRC channels, with passwords and channels obtained from the infected machine. It is not hard for law enforcement to track down virus operators when they have an inclination. Sometimes it is not impossible for regular people to get in contact with the virus operators though the IRC control channels. See http://grc.com/dos/grcdos.htm for a detailed analysis. One doesn't frequently see TCP spoofing, however. Its just too hard, and there is no gain over not spoofing for abusers. To stop spam and ddos attacks, one needs to work on better accountability in IRC, not in SMTP. Of course, if that happened, they would switch to jabber, I suppose. --Dean From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 11:34:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10422 for ; Thu, 19 Aug 2004 11:34: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 i7JEwgOY005673; Thu, 19 Aug 2004 07:58:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JEwgB4005672; Thu, 19 Aug 2004 07:58: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 i7JEwfF6005662 for ; Thu, 19 Aug 2004 07:58:42 -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 6C6D816F53 for ; Thu, 19 Aug 2004 11:07:13 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Solution For Trojans In-Reply-To: Your message of "Wed, 18 Aug 2004 23:16:55 PDT." <1104.64.142.13.68.1092896215.squirrel@harry.mail-abuse.org> Date: Thu, 19 Aug 2004 11:07:13 -0400 Message-Id: <20040819150713.6C6D816F53@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Douglas Otis" wrote: > The technique of using RFC2822 content to identify the MTA will lead to > errors and is based upon a premise such content has not been spoofed > between MTAs. There is no means within this standard to hold a particular > MTA accountable. I agree. It's only hop-by-hop accountability. CSV-CSA isn't any different, in that regard. > CSV-CSA deals directly with the entity sending the mail, and not > indirectly based upon RFC2822 content. For similar reasons, my interest in this area has always been RFC 2821 content, alone. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 11:37: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 LAA10556 for ; Thu, 19 Aug 2004 11:37: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 i7JF68sh008848; Thu, 19 Aug 2004 08:06: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 i7JF689m008847; Thu, 19 Aug 2004 08:06:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JF68r0008828 for ; Thu, 19 Aug 2004 08:06:08 -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, 19 Aug 2004 11:06:06 -0400 id 002134FE.4124C1DF.000049CA In-Reply-To: <319B86FE-F1EC-11D8-B8A5-000A9566A350@DDG.com> References: <319B86FE-F1EC-11D8-B8A5-000A9566A350@DDG.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <42D264A2-F1F1-11D8-B4ED-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: There can be more than one Date: Thu, 19 Aug 2004 11:05:51 -0400 To: "Andrew W. Donoho" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 19, 2004, at 10:29 AM, Andrew W. Donoho wrote: > For example, while Sender-ID is going out the door "first", it is to > be quickly followed by MPR (nee CSV-BATV?). MPR is not a working group item. Some of you may have noticed that this is a high-volume list. I was asked by Wayne if it was ok to start discussing alternative drafts on this list. My answer to him was: go ahead and submit them as individuals but please hold off discussion until we have evaluated Sender ID. I am not just asking this of Wayne but of all participants. > In the race for trying to solve the anti-phishing problem, Sender-ID > provides one extra step that will need to be buttressed by whatever > IETF MASS WG produces. MASS is not yet a working group. -andy From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 11:51: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 LAA11550 for ; Thu, 19 Aug 2004 11:51:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFEMlp011476; Thu, 19 Aug 2004 08:14: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 i7JFEMEL011475; Thu, 19 Aug 2004 08:14:22 -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 i7JFEK4h011467 for ; Thu, 19 Aug 2004 08:14:21 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id BA7A71BDE7C; Thu, 19 Aug 2004 17:14:22 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by kalyani.oryx.com (Postfix) with SMTP id C29BC1BDE74 for ; Thu, 19 Aug 2004 17:14:21 +0200 (CEST) Message-Id: Date: Thu, 19 Aug 2004 17:22:53 +0200 From: Arnt Gulbrandsen To: ietf-mxcomp@imc.org Subject: Re: IP Address spoofing References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I forgot about the local IP attacks. Sorry, I should have mentioned them. Dean Anderson writes: > On Thu, 19 Aug 2004, Arnt Gulbrandsen wrote: >> Every notable ISP can do that, and can let some of its customers do >> that. Say 20,000 organizations in all have the ability to do that. > > Actually the AS numbers are past 30000 now. Sure, but many AS owners have more than one AS. Arnt From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 11:59: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 LAA12103 for ; Thu, 19 Aug 2004 11:59: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 i7JFV8Io014119; Thu, 19 Aug 2004 08:31: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 i7JFV8BQ014117; Thu, 19 Aug 2004 08:31:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFV7M8014105 for ; Thu, 19 Aug 2004 08:31:08 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7JFV10w013678 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 Aug 2004 11:31:02 -0400 Date: Thu, 19 Aug 2004 11:31:01 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: "'Chris Haynes'" , Andrew Newton , IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er 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, 18 Aug 2004, Hallam-Baker, Phillip wrote: > > > > I suggest you look at RFC 2026, and tighten your terminology. > > Is this a deliberate troll or are the insults merely gratuious? You used the wrong terms, as I very politely explained. If you take correction is insult, that's not my problem. However, it was not gratuitous. > > _some_ testing and codebase should be available before a draft > > is put to last call. Otherwise, we are dealing in hypotheticals. > > There is considerably more experience of use of SPF today than > there is of application of the vast majority of Proposed standards > and more than a few Draft standard. I'll stipulate there has been bad past practice, though I doubt as bad as you say, but even so, bad past practice doesn't justify further bad practice. We are supposed to learn from our mistakes. It has already been pointed out nearly all of the previous antispam measures has failed. They failed largely because they went off half-cocked without sufficient analysis. > > Several days ago it was proposed that some testing be done before last > > call. I thought there were many people in favor of that. Indeed, I > > would have thought there was a consensus on that direction. Is that > > not the case? So what is the rush? I'm still not understanding what > > the rush is. > > If you really don't know what the rush is then I don't think you > understand the problem. I guess I don't then. Because if the MTA authorization problem is serious, then it is more imporantant to have a solution that works, than one that doesn't work. I wonder if people are in a rush because they _know_ that if time is spent on analysis and hostile testing, that their schemes just won't measure up. --Dean From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 12:42: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 MAA15330 for ; Thu, 19 Aug 2004 12:42:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JG6YCf020330; Thu, 19 Aug 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 i7JG6YBq020329; Thu, 19 Aug 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 zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JG6YbK020318 for ; Thu, 19 Aug 2004 09:06:34 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 19 Aug 2004 12:06:32 -0400 id 00213565.4124D009.00005145 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Thu, 19 Aug 2004 12:06:29 -0400 To: Dean Anderson , Phillip Hallam-Baker X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 19, 2004, at 11:31 AM, Dean Anderson wrote: > On Wed, 18 Aug 2004, Hallam-Baker, Phillip wrote: > >> >> >>> I suggest you look at RFC 2026, and tighten your terminology. >> >> Is this a deliberate troll or are the insults merely gratuious? > > You used the wrong terms, as I very politely explained. If you take > correction is insult, that's not my problem. However, it was not > gratuitous. > Is it possible that this back-and-forth volley can end without a finding of fault on any party? I'm sure there are valid points all the way around, but agreement to disagree seems to be the only way forward. -andy From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 12:49: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 MAA15776 for ; Thu, 19 Aug 2004 12:49: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 i7JGKNH2022442; Thu, 19 Aug 2004 09:20: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 i7JGKNtb022441; Thu, 19 Aug 2004 09:20:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGKMCu022411 for ; Thu, 19 Aug 2004 09:20:22 -0700 (PDT) (envelope-from mbaugher@cisco.com) X-BrightmailFiltered: true Received: from [65.121.149.214] (sjc-vpn2-63.cisco.com [10.21.112.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7JGIts5005321 for ; Thu, 19 Aug 2004 09:18:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <7E7C0C9E-F183-11D8-8A10-000A95BC6A7E@margaretolson.com> References: <7E7C0C9E-F183-11D8-8A10-000A95BC6A7E@margaretolson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <72A08FE9-F1FB-11D8-B83A-000A95DC10F2@cisco.com> From: Mark Baugher Subject: Re: Forged Sender (Resent-From) attacks Date: Thu, 19 Aug 2004 09:18:46 -0700 To: ietf-mxcomp@imc.org X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JGKMCu022436 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit There are a number of problems with present-day secure web transactions, which typically use SSL. For starters, the server does the authentication by querying the user for a password but not vice versa. Many servers ask for a secret question and use the answer to expedite lost password recovery but don't allow the user to even ask what the secret question is. And web servers typically get a lot of authenticating information from the user, who has very little to go on beyond a natural-language-looking domain name that is vulnerable to social-engineering attacks and simple mistakes such as typos. All of this has been considered in RFC 2693, Risks, and other places. My point here is that it is not reasonable to expect that an MTA authorization record is going to do much to alleviate phishing beyond removing one delivery option, i.e. an email message with a forged from address. More extensive cryptographic mechanisms might help, if you believe these mechanisms are suitable for most consumers. But I don't see how MARID can do more than mitigate _one type_ of phishing attack. Mark On Aug 18, 2004, at 7:00 PM, Margaret Olson wrote: > > > On Aug 18, 2004, at 9:03 PM, Daryl Odnert wrote: > >> Nate Leon wrote: >> > I expect it will take years before all MUAs are updated (and widely >> > deployed) to display the PRA, which I do not think is an acceptable >> > timeframe to put a serious dent into phishing attacks. >> >> But HTTP over >> SSL wasn't enough to secure the Web.  The lock icon in the browsers >> were needed too so users could tell the difference between what is >> trustworthy and what is not. > > And the lock on the browser came after the SSL standard. > SenderID is the first step, and a necessary step, not an instant cure > for all that ails email. > > Margaret. > > From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 12:57: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 MAA16289 for ; Thu, 19 Aug 2004 12:57:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGW4iI025678; Thu, 19 Aug 2004 09:32:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JGW4iS025677; Thu, 19 Aug 2004 09:32:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JGW3SP025654 for ; Thu, 19 Aug 2004 09:32:03 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 33964 invoked from network); 19 Aug 2004 16:32:02 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 19 Aug 2004 16:32:02 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: Subject: RE: change of version string Date: Thu, 19 Aug 2004 12:32:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of william(at)elan.net > Sent: Wednesday, August 11, 2004 5:59 AM > To: IETF MARID WG > Subject: Re: change of version string > Perhaps it would be usefull if we allow one type of SPF record to > reference > (include, refer to) another type of SPF record, this would eliminate > duplication problems in case of long records and avoid issues with large > dns packet (because of multiple large txt records) as well. > Or perhaps we could say that mail receivers MAY use an v=spf1 records if no SPF2 record is returned. As I understand it, any query for a TXT record will return all TXT records for the domain, so if the TXT version of SPF2 is queried for, the v=spf1 record will be returned if it exists. I understand that some are concerned with the difference between 2821 mail.from and 2822 PRA. I've read all the drafts and as nearly as I can tell, the mechanisms defined in my v=spf1 record will work perfectly well for Sender-ID. For those, like me, for whom the records would be the same, allowing for backward use of the earler SPF records would simplify things considerably. It would also allow for Sender-ID checks to be usefully evaluated much sooner since a large body of v=spf1 records is already published. For those who are concerned about the distinction, but want to use v=spf1, if they publish an SPF2 record, then they can define that distinction. The change I am proposing would be to Page 5 of The Sender-ID Record: Format and Interpretation, draft-ietf-marid-protocol-02. Change: A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup TXT record at the same time, or wait for negative answer. SPF2 type SHOULD be used if available. To: A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup TXT record at the same time, or wait for negative answer. SPF2 type SHOULD be used if available. If a v=spf1 record is returned from the TXT record lookup, it MAY be used if and only if no SPF2 (SPF2 RR or SPF2 TXT) record is returned. I believe that would make life simpler for many of us without undue complication for others. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 13:28:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15329 for ; Thu, 19 Aug 2004 12:42:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGCa8I021219; Thu, 19 Aug 2004 09:12:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JGCaS4021218; Thu, 19 Aug 2004 09:12: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 i7JGCZGf021208 for ; Thu, 19 Aug 2004 09:12: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 (Email Firewall v6.0.0)); Thu, 19 Aug 2004 09:12:37 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Thu, 19 Aug 2004 09:12:20 -0700 Message-ID: From: "Daryl Odnert" To: "Chris Haynes" cc: "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Thu, 19 Aug 2004 09:12:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D3A0EFF1OS6197136-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48607.4D18179C" 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_01C48607.4D18179C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit I agree with Roy Badami's response. "Bad" email is already rejected in large quantities today by many MTAs using anti-spam, anti-virus, and anti-DoS-attack techniques. Sender ID does not attempt to address this problem, nor does it make this problem significantly worse. Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C48607.4D18179C Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: Point of Order: Incomplete, flawed response to MARID WG Charter

I agree with Roy Badami's response.  "Bad" email is already rejected
in large quantities today by many MTAs using anti-spam, anti-virus,
and anti-DoS-attack techniques.  Sender ID does not attempt to address
this problem, nor does it make this problem significantly worse.

Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C48607.4D18179C-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 13:32: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 NAA18454 for ; Thu, 19 Aug 2004 13:32: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 i7JH2UFH029680; Thu, 19 Aug 2004 10:02: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 i7JH2U0j029679; Thu, 19 Aug 2004 10:02:30 -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 i7JH2T0S029646 for ; Thu, 19 Aug 2004 10:02:29 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from sputnik (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i7JH2Hhg009146; Thu, 19 Aug 2004 19:02:17 +0200 Received: (from hadmut@localhost) by sputnik.mobil.danisch.de (8.12.11/8.12.11/Debian-5) id i7JH2AbC012632; Thu, 19 Aug 2004 19:02:10 +0200 From: Hadmut Danisch Date: Thu, 19 Aug 2004 10:02:10 -0700 To: Internet-Drafts@ietf.org, ietf-mxcomp@imc.org Subject: Re: I-D ACTION:draft-ietf-marid-core-03.txt Message-ID: <20040819170210.GA12521@danisch.de> References: <200408181922.PAA01384@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200408181922.PAA01384@ietf.org> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, I hereby raise IPR/Copyright claims under US law and Urheberrechte and Urheberpersönlichkeitsrechte under German law against the SenderID drafts, because my RMX work and draft (submitted as an RFC, status unknown) is not sufficiently cited and acknowledged. I'm still on journey in California and will be back home on Aug 24. I'll be offline and not able to respond to email until then. regards Hadmut Danisch From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 13:36: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 NAA18754 for ; Thu, 19 Aug 2004 13:36:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JG1vQO019646; Thu, 19 Aug 2004 09:01: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 i7JG1vp7019645; Thu, 19 Aug 2004 09:01:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JG1vbj019621 for ; Thu, 19 Aug 2004 09:01:57 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1BxpMN-000MMz-00; Thu, 19 Aug 2004 17:01:51 +0100 Message-ID: <072b01c48605$87d1ab40$0200000a@ringo> From: "Chris Haynes" To: "Roy Badami" Cc: "IETF MARID WG" References: <058901c485c1$9299c5b0$0200000a@ringo> <16676.44440.161225.346881@giles.gnomon.org.uk> Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Thu, 19 Aug 2004 16:59:26 +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 At 2:39 PM on Thursday, August 19, 2004 "Roy Badami" said: > Your argument basically boils down to saying I should never reject any > SMTP transaction because it might result in backscatter. I don't buy > it. Backscatter is a problem; let's fix it (but not here). > No, it does not. I was pointing out that: 1) Sender-ID makes the backscatter problem worse, 2) SPF can in many cases make it better, but never worse. AFAICT, no one has a proven universal solution to offer. What can be done, and is now being done in this anti-forgery activity, is to deploy a sequence of relatively simple schemes which gradually chip away at parts of the problem, forcing the bad guys to change their behaviour in ways which makes it progressively more difficult / more expensive for them to act, and easier for them and their works to be identified and dealt with. What we have to ensure, however, is that these simple schemes do not have unintended, avoidable side-effects, or at least that, if they do, there is a proper, engineering evaluation of the overall cost-benefit before deciding to deploy them. It occurs to me that this process is rather like that which public health experts must go through when deciding on programs of public immunisation. A vaccine which gives benefit / protection to the many may have the side-effect of causing vaccine-damage to a minority. This current debate is about an undesirable side-effect of Sender_ID, and one which is avoidable if the essence of SPF is added to the 'vaccine' at the same time. Ethically, which do you do: - Rush out a single-strain vaccine with a known adverse side-effect, or - Spend another three or four weeks mixing a 'cocktail' which avoids that side-effect? I think that is the choice facing this working group. Chris From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 14:07: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 OAA20651 for ; Thu, 19 Aug 2004 14:07: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 i7JHXxfd034703; Thu, 19 Aug 2004 10:33: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 i7JHXxBu034702; Thu, 19 Aug 2004 10:33: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 i7JHXxH0034696 for ; Thu, 19 Aug 2004 10:33: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 318DE41497; Thu, 19 Aug 2004 10:34:03 -0700 (PDT) Subject: Re: Solution For Trojans From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040819150713.6C6D816F53@mail.nitros9.org> References: <20040819150713.6C6D816F53@mail.nitros9.org> Content-Type: text/plain Message-Id: <1092936841.21470.60.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 19 Aug 2004 10:34: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 On Thu, 2004-08-19 at 08:07, Alan DeKok wrote: > "Douglas Otis" wrote: > > > > The technique of using RFC2822 content to identify the MTA will lead to > > errors and is based upon a premise such content has not been spoofed > > between MTAs. There is no means within this standard to hold a particular > > MTA accountable. > > I agree. It's only hop-by-hop accountability. With Sender-ID, EHLO and MAIL FROM are ignored. Sender-ID has no concept of the hop, but rather considers a distribution that _may_ be part of a merged set of domains, or even of an "open" set. As example, with Sender-ID, the message may initially be identified as being outside the "open" set, but if introduced into the merged set, it will be promoted to being validated as being inside the "open" set. : ( With Sender-ID, the entity accountable for traffic emerging from a hop is _not_ identified. CSV, however, clearly identifies this entity and thus provides an identity that may safely be held accountable. These are important nits from the perspective of enforcement with repudiation, reputation, or accreditation. Once considering the likely evolution of Sender-ID, where ISPs resort to using Resent-From, the PRA is not substantially different than . With BATV, would be just as good as Submitter. (The reason for indicating BATV use in MPR.) > CSV-CSA isn't any different, in that regard. CSV is very different from Sender-ID in that regard. It seems we agree on major points, so I am confused how you can hold this view. > > CSV-CSA deals directly with the entity sending the mail, and not > > indirectly based upon RFC2822 content. > > For similar reasons, my interest in this area has always been RFC > 2821 content, alone. I agree 2821 EHLO and MAIL FROM should be the focus, if to curtail spoof bounces, Trojans, and spam. I provided the MPR draft to illustrate how the channel could be related to the From Mailbox Domain using a single DNS reference, to afford protections for institutions being phished, as example. Sender-ID however does not offer an effective protection in this area, while it breaks much of the current mail, hammers DNS, and ignores UDP back-off requirements. I see such Mailbox Domain/Mail Channel restrictions as the exceptional case. Perhaps over time, this exceptional case would be better accommodated by things like BATV. : ) *Authenticated. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 14:34: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 OAA22518 for ; Thu, 19 Aug 2004 14:34: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 i7JI4l58039146; Thu, 19 Aug 2004 11:04:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JI4lpM039145; Thu, 19 Aug 2004 11:04:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from 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 i7JI4kb7039138 for ; Thu, 19 Aug 2004 11:04: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 4D6F116E0B for ; Thu, 19 Aug 2004 14:13:19 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Solution For Trojans In-Reply-To: Your message of "Thu, 19 Aug 2004 10:34:02 PDT." <1092936841.21470.60.camel@ddev.mail-abuse.org> Date: Thu, 19 Aug 2004 14:13:19 -0400 Message-Id: <20040819181319.4D6F116E0B@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > > I agree. It's only hop-by-hop accountability. > > With Sender-ID, EHLO and MAIL FROM are ignored. Sender-ID has no > concept of the hop, It's applied by MTA's, which do have the concept of a hop. > With Sender-ID, the entity accountable for traffic emerging from a hop > is _not_ identified. The PRA of the traffic is identified, who may not be the same as the MTA client originating the traffic for the current SMTP session. > CSV, however, clearly identifies this entity and thus provides an > identity that may safely be held accountable. It uses different fields to hold a different entity accountable for different behavior. > CSV is very different from Sender-ID in that regard. It seems we agree > on major points, so I am confused how you can hold this view. The paradigm change to hold entities responsible for SMTP traffic is the same in both proposals. The fields they use, and the implementation, differ. Previously, recipient MTA's had to determine the responsible entitity by making reasonable implications, which may or not not have been correct. The proposals here in MARID allow entities to explicitly state who is to be help accountable. > Sender-ID however does not offer an effective protection in this > area, while it breaks much of the current mail, hammers DNS, and > ignores UDP back-off requirements. I'm not sure I agree with all that, but I do agree that other systems within the MARID scope may acheive the MARID goals with less effort. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 14:38: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 OAA22797 for ; Thu, 19 Aug 2004 14:38: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 i7JI8nd1039679; Thu, 19 Aug 2004 11:08: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 i7JI8nWU039678; Thu, 19 Aug 2004 11:08:49 -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 i7JI8mdQ039669 for ; Thu, 19 Aug 2004 11:08:48 -0700 (PDT) (envelope-from roy+dated+1095530923.a392b4@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7JIADVO099714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Aug 2004 18:10:19 GMT (envelope-from roy+dated+1095530923.a392b4@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7JI8huN085332 for ; Thu, 19 Aug 2004 19:08:43 +0100 (BST) (envelope-from roy+dated+1095530923.a392b4@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7JI8hSQ085323 for ietf-mxcomp@imc.org; Thu, 19 Aug 2004 19:08:43 +0100 (BST) (envelope-from roy+dated+1095530923.a392b4@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 19 Aug 2004 19:08:42 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16676.60586.22401.296538@giles.gnomon.org.uk> Date: Thu, 19 Aug 2004 19:08:42 +0100 To: "Chris Haynes" Cc: "Roy Badami" , "IETF MARID WG" Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Chart er In-Reply-To: <072b01c48605$87d1ab40$0200000a@ringo> References: <058901c485c1$9299c5b0$0200000a@ringo> <16676.44440.161225.346881@giles.gnomon.org.uk> <072b01c48605$87d1ab40$0200000a@ringo> 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 >>>>> "Chris" == Chris Haynes writes: Chris> No, it does not. Chris> I was pointing out that: Chris> 1) Sender-ID makes the backscatter problem worse, Chris> 2) SPF can in many cases make it better, but never worse. Really? draft-mengwong-spf-01 permits rejection of a message with a 550 reply code if the SPF check fails, and that's what most implementations seem to do. If you reject an SMTP transaction due to an SPF failure, then the up-stream MTA is likely to generate a bounce to a forged address. As far as I can see, all MARID schemes are likely to increase backscatter. In fact, anything that cause more mail to be SMTP rejected will increase backscatter. -roy From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 14: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 OAA23143 for ; Thu, 19 Aug 2004 14:46:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JI8CsH039540; Thu, 19 Aug 2004 11:08:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JI8CX5039539; Thu, 19 Aug 2004 11:08:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JI8BWH039533 for ; Thu, 19 Aug 2004 11:08:11 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7JI8FKX010870 for ; Thu, 19 Aug 2004 11:08:15 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Aug 2004 11:08:15 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Thu, 19 Aug 2004 11:08:11 -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 wonder if people are in a rush because they _know_ that if > time is spent > on analysis and hostile testing, that their schemes just > won't measure up. Since Dean has objected to me taking this type of issue up in private I will take it up on the list. I find the above statement to be unprofessional and defamatory. Attacking the motives of working group members in this way is not acceptable. The eliptical method in which the attack is made does not make it any less an attack. Phill From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 15:04: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 PAA24355 for ; Thu, 19 Aug 2004 15:04: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 i7JITk3S042538; Thu, 19 Aug 2004 11:29: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 i7JITjFk042537; Thu, 19 Aug 2004 11:29:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JITjGc042531 for ; Thu, 19 Aug 2004 11:29:45 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 19 Aug 2004 11:29:46 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Aug 2004 11:29:46 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Aug 2004 11:29:45 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 11:29:44 -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: Forged Sender (Resent-From) attacks Date: Thu, 19 Aug 2004 11:29:44 -0700 Message-ID: Thread-Topic: Forged Sender (Resent-From) attacks thread-index: AcSFyRGxX2J8byc6RVGi4nraPFjEcwAUHzAQ From: "Harry Katz" To: "Chris Haynes" Cc: "Nate Leon" , X-OriginalArrivalTime: 19 Aug 2004 18:29:44.0885 (UTC) FILETIME=[800D6650:01C4861A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JITjGc042532 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, August 19, 2004 1:44 AM, Chris Haynes [mailto:chris@harvington.org.uk] wrote: > > > > > - More importantly, this allow us to give much clearer > directions to > > senders in terms of what to publish. You publish the IP > addresses of > > servers authorized to send mail on behalf of your domain. We're not > > trying to mix this up with the IP addresses of servers that receive > > bounce messages on behalf of your domain. > > > > > Is it possible that, all along, there has been a fundamental > misunderstanding of SPF amongst the designers of Sender-ID? > No there is no fundamental misunderstanding. There may be a wording problem, though. :-) The point I'm trying to make, and which has been made many times before, is that there is a semantic difference between the 2821 MAIL FROM address and the 2822 headers. So maybe I should have said "the IP addresses of servers authorized to transmit mail on behalf of the domain that receives your bounce messages." From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 16:04: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 QAA02280 for ; Thu, 19 Aug 2004 16:04: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 i7JJV3JC053419; Thu, 19 Aug 2004 12:31:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JJV36I053418; Thu, 19 Aug 2004 12:31:03 -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-srv.bellnexxia.net [209.226.175.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJV2hs053411 for ; Thu, 19 Aug 2004 12:31:02 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040819193105.MJLF14082.tomts16-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 19 Aug 2004 15:31:05 -0400 From: "John Glube" To: "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" Cc: "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter Date: Thu, 19 Aug 2004 15:32:45 -0400 Message-ID: <018c01c48623$4dccc7e0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JJV2hs053412 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Daryl, * Sender-ID does not call for receiving MTAs to do a malformed SMTP Mail From check. However, we know (see the US Bank spoof scenario as an example) doing such a check would prevent spammers from sending directly from IP address to the receivers MX. * Sender-ID does not call for receiving MTAs to do an SMTP Mail From check in the absence of PRA. However, we know as has been pointed out by doing so, this aids in the prevention of one form of 'backscatter' as pointed out by Chris and helps to minimize the risk of false positives, as has been pointed out by Meng. I must be honest and say I am totally confused. For almost 3 weeks now, some of us have been raising the issue of having Sender-ID include an SMTP Mail From check based on the SPF protocol to pick up and deal with these obvious exploits. Yet the answer has been negative. That is until most recently. Harry has now responded by suggesting a BCP as opposed to amending the protocol drafts. I am most grateful for Harry's response. The proposal only deals with one part of the issue, the malformed SMTP Mail From at the data stage. It does not call for doing a spoof check using SMTP MAIL FROM in the absence of PRA at the data stage, so reducing the risk of false positives as pointed out by Meng and avoiding one element of back scatter as pointed out by Chris. However, I am sure the proposal can easily include both without causing any disruption or delay, while giving favourable consideration to the solution to the version string issue as proposed by Scott. At the same time Andy has now indicated it is appropriate for individuals to come forward with other proposals, which means a set of drafts for SPF can be put on the table and dealt with once we finish dealing with Sender-ID. Yes, I appreciate Chris's stance may have offended some and caused others to get upset. However, others have been equally offended and upset by the refusal to budge on an issue which to many was clear. But now that we all understand what the engineering concerns are, how about we get on with the show and work on a BCP for Sender-ID, while letting others come forward with SPF protocol drafts to complete the needed work to support the BCP? John cc. Chris, Harry 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.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 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 QAA02481 for ; Thu, 19 Aug 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 i7JJdLsu054720; Thu, 19 Aug 2004 12:39: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 i7JJdLSL054719; Thu, 19 Aug 2004 12:39:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJdL2q054713 for ; Thu, 19 Aug 2004 12:39:21 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 5BBC34149B; Thu, 19 Aug 2004 12:39:25 -0700 (PDT) Subject: Re: Solution For Trojans From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040819181319.4D6F116E0B@mail.nitros9.org> References: <20040819181319.4D6F116E0B@mail.nitros9.org> Content-Type: text/plain Message-Id: <1092944364.21514.55.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 19 Aug 2004 12:39: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 Thu, 2004-08-19 at 11:13, Alan DeKok wrote: > Douglas Otis wrote: > > > I agree. It's only hop-by-hop accountability. > > > > With Sender-ID, EHLO and MAIL FROM are ignored. Sender-ID has no > > concept of the hop, > > It's applied by MTA's, which do have the concept of a hop. Perhaps one could describe the PRA algorithm as the MTA considering prior hops, when the accountable identity is deciphered. If an unchanged message is passed from MTA to MTA into a prescribed channel (merged-open set), the evaluation of this identity may be promoted, as Sender-ID does not consider messages passing through a chain of MTAs of differing acceptance levels. With respect to Sender-ID, there is no acceptance state at each hop being relayed. This information is being ignored. With Sender-ID, the accountable entity is based solely upon RFC2822 message content, this may change at each hop when a header is added, this entity may or not be checked against Sender-ID records at various MTAs, and the accountable levels for the entity may erroneously increase. Although there may be _some_ notion of a hop within Sender-ID, Sender-ID seems to assume communications are end-to-end for the purpose of reputation, with the exception of added sending headers. > > With Sender-ID, the entity accountable for traffic emerging from a hop > > is _not_ identified. > > The PRA of the traffic is identified, who may not be the same as the > MTA client originating the traffic for the current SMTP session. The PRA may have been outside the prescribed mail channel initially, but this information is lost when transferring through a chain of MTAs. The Purported Responsible Address offers no assurance nor tracks any level of responsibility. This mnemonic should refer to Purported Recent Address instead. > > CSV, however, clearly identifies this entity and thus provides an > > identity that may safely be held accountable. > > It uses different fields to hold a different entity accountable for > different behavior. CSV attempts to hold the accountable entity accountable for the mail sent. There is nothing definite that could be said of Sender-ID. :) > > CSV is very different from Sender-ID in that regard. It seems we agree > > on major points, so I am confused how you can hold this view. > > The paradigm change to hold entities responsible for SMTP traffic is > the same in both proposals. The fields they use, and the > implementation, differ. > > Previously, recipient MTA's had to determine the responsible > entitity by making reasonable implications, which may or not not have > been correct. The proposals here in MARID allow entities to > explicitly state who is to be help accountable. Agreed. > > Sender-ID however does not offer an effective protection in this > > area, while it breaks much of the current mail, hammers DNS, and > > ignores UDP back-off requirements. > > I'm not sure I agree with all that, but I do agree that other > systems within the MARID scope may achieve the MARID goals with less > effort. I would be happy to review these other points. :) -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 16:23: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 QAA04628 for ; Thu, 19 Aug 2004 16:23: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 i7JJrvn9057082; Thu, 19 Aug 2004 12:53: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 i7JJrvOf057081; Thu, 19 Aug 2004 12:53:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJrvFu057075 for ; Thu, 19 Aug 2004 12:53:57 -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 DB19A4149B; Thu, 19 Aug 2004 12:54:01 -0700 (PDT) Subject: RE: change of version string From: Douglas Otis To: Scott Kitterman Cc: MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1092945240.21602.13.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 19 Aug 2004 12:54:00 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-19 at 09:32, Scott Kitterman wrote: > On Wed, 2004-08-11 at 5:59, william(at)elan.net wrote: > > > Perhaps it would be usefull if we allow one type of SPF record to > > reference (include, refer to) another type of SPF record, this would > > eliminate duplication problems in case of long records and avoid > > issues with large dns packet (because of multiple large txt records) > > as well. > > Or perhaps we could say that mail receivers MAY use an v=spf1 records if no > SPF2 record is returned. As I understand it, any query for a TXT record > will return all TXT records for the domain, so if the TXT version of SPF2 is > queried for, the v=spf1 record will be returned if it exists. > > I understand that some are concerned with the difference between 2821 > mail.from and 2822 PRA. I've read all the drafts and as nearly as I can > tell, the mechanisms defined in my v=spf1 record will work perfectly well > for Sender-ID. > > For those, like me, for whom the records would be the same, allowing for > backward use of the earler SPF records would simplify things considerably. > It would also allow for Sender-ID checks to be usefully evaluated much > sooner since a large body of v=spf1 records is already published. > > For those who are concerned about the distinction, but want to use v=spf1, > if they publish an SPF2 record, then they can define that distinction. > > The change I am proposing would be to Page 5 of The Sender-ID Record: Format > and Interpretation, draft-ietf-marid-protocol-02. > > Change: > > A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup > TXT record at the same time, or wait for negative answer. SPF2 type > SHOULD be used if available. > > To: > > A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup > TXT record at the same time, or wait for negative answer. SPF2 type > SHOULD be used if available. If a v=spf1 record is returned from > the TXT record lookup, it MAY be used if and only if no SPF2 (SPF2 > RR or SPF2 TXT) record is returned. > > I believe that would make life simpler for many of us without undue > complication for others. There should be a concern doing this. Those that published v=spf1 records were intending this record to be applied to their RFC2821 MAIL FROM mailbox. This would allow _any_ RFC2822 mailbox to be used. Those publishing this record may have fully expected to retain this freedom, which now you feel obliged not to respect out of expediency. This lack of respect seems to extend to the use of SPF2, as the identifier for Sender-ID. Why not fully depart, instead of this half measure which only seems to obfuscate the fact these algorithms and mechanisms are entirely different. Sender-ID is not even better in many respects. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 16:40: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 QAA06661 for ; Thu, 19 Aug 2004 16:40: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 i7JKI85U060624; Thu, 19 Aug 2004 13:18: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 i7JKI86E060623; Thu, 19 Aug 2004 13:18:08 -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 i7JKI8Lo060603 for ; Thu, 19 Aug 2004 13:18:08 -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 (Email Firewall v6.0.0)); Thu, 19 Aug 2004 13:18:14 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Thu, 19 Aug 2004 13:17:57 -0700 Message-ID: From: "Daryl Odnert" To: "'John Glube'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er Date: Thu, 19 Aug 2004 13:17:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D3BD48C1OS6220533-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48629.9B6929DC" 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_01C48629.9B6929DC Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit John, I understand that Sender ID, as currently written, does not prevent joe jobbing and the associated "blowback" or "backscatter" problem that results from this practice. I disagree with Chris that Sender ID makes this problem significantly worse than it is right now. Why? Because his example assumes that a hacker/spammer/zombie has gained access to an MTA that is willing to accept mail with a reverse-path in the victim's domain. At this point, it is not difficult to construct messages that will be rejected with 5xy errors at the recipient's relay. You don't need the recipient's MTA to have implemented Sender ID testing to make that happen. I think a proposal that would enable both reverse-path and PRA authentication is definitely a worthwhile endeavor. But I wouldn't necessarily throw away the existing Sender ID proposal on the basis that it doesn't solve a problem that the authors chose not to solve in the first place. (Read http://www.ietf.org/internet-drafts/draft-ietf-marid-rationale-00.txt for more insight into that choice.) Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C48629.9B6929DC Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: Point of Order: Incomplete, flawed response to MARID WG = Charter

John,

I understand that Sender ID, as currently written, = does
not prevent joe jobbing and the associated = "blowback" or
"backscatter" problem that results from = this practice.

I disagree with Chris that Sender ID makes this = problem
significantly worse than it is right now.  = Why?  Because
his example assumes that a hacker/spammer/zombie has = gained
access to an MTA that is willing to accept mail = with
a reverse-path in the victim's domain.  At this = point, it
is not difficult to construct messages that will be = rejected
with 5xy errors at the recipient's relay.  You = don't need
the recipient's MTA to have implemented Sender ID = testing
to make that happen.

I think a proposal that would enable both = reverse-path
and PRA authentication is definitely a worthwhile = endeavor.
But I wouldn't necessarily throw away the existing = Sender ID
proposal on the basis that it doesn't solve a = problem that
the authors chose not to solve in the first = place.  (Read
http://www.ietf.org/internet-drafts/draft-ietf-marid-r= ationale-00.txt
for more insight into that choice.)

Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C48629.9B6929DC-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 16:40: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 QAA06664 for ; Thu, 19 Aug 2004 16:40: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 i7JKHJ6v060505; Thu, 19 Aug 2004 13:17: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 i7JKHJIH060504; Thu, 19 Aug 2004 13:17:19 -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 i7JKHI0F060485 for ; Thu, 19 Aug 2004 13:17:18 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 19477 invoked from network); 19 Aug 2004 20:17:18 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 19 Aug 2004 20:17:18 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "Douglas Otis" Cc: "MARID" Subject: RE: change of version string Date: Thu, 19 Aug 2004 16:17:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <1092945240.21602.13.camel@ddev.mail-abuse.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Douglas Otis > Sent: Thursday, August 19, 2004 3:54 PM > To: Scott Kitterman > Cc: MARID > Subject: RE: change of version string > > On Thu, 2004-08-19 at 09:32, Scott Kitterman wrote: > > On Wed, 2004-08-11 at 5:59, william(at)elan.net wrote: > > > > > Perhaps it would be usefull if we allow one type of SPF record to > > > reference (include, refer to) another type of SPF record, this would > > > eliminate duplication problems in case of long records and avoid > > > issues with large dns packet (because of multiple large txt records) > > > as well. > > > > Or perhaps we could say that mail receivers MAY use an v=spf1 > records if no > > SPF2 record is returned. As I understand it, any query for a TXT record > > will return all TXT records for the domain, so if the TXT > version of SPF2 is > > queried for, the v=spf1 record will be returned if it exists. > > > > I understand that some are concerned with the difference between 2821 > > mail.from and 2822 PRA. I've read all the drafts and as nearly as I can > > tell, the mechanisms defined in my v=spf1 record will work > perfectly well > > for Sender-ID. > > > > For those, like me, for whom the records would be the same, allowing for > > backward use of the earler SPF records would simplify things > considerably. > > It would also allow for Sender-ID checks to be usefully evaluated much > > sooner since a large body of v=spf1 records is already published. > > > > For those who are concerned about the distinction, but want to > use v=spf1, > > if they publish an SPF2 record, then they can define that distinction. > > > > The change I am proposing would be to Page 5 of The Sender-ID > Record: Format > > and Interpretation, draft-ietf-marid-protocol-02. > > > > Change: > > > > A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup > > TXT record at the same time, or wait for negative answer. SPF2 type > > SHOULD be used if available. > > > > To: > > > > A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup > > TXT record at the same time, or wait for negative answer. SPF2 type > > SHOULD be used if available. If a v=spf1 record is returned from > > the TXT record lookup, it MAY be used if and only if no SPF2 (SPF2 > > RR or SPF2 TXT) record is returned. > > > > I believe that would make life simpler for many of us without undue > > complication for others. > > There should be a concern doing this. Those that published v=spf1 > records were intending this record to be applied to their RFC2821 MAIL > FROM mailbox. This would allow _any_ RFC2822 mailbox to be used. Those > publishing this record may have fully expected to retain this freedom, > which now you feel obliged not to respect out of expediency. > > This lack of respect seems to extend to the use of SPF2, as the > identifier for Sender-ID. Why not fully depart, instead of this half > measure which only seems to obfuscate the fact these algorithms and > mechanisms are entirely different. Sender-ID is not even better in many > respects. > > -Doug > Anyone who doesn't want their v=spf1 record used for Sender-ID checks can publish an SPF2 record that says spf2.0/pra +all. That's an effective opt-out of Sender-ID. While I agree that the records for SPF Classic and Sender-ID may be different in some cases, I expect that will be the exception. For the bulk of cases, I believe that the same record can be accurately parsed for both. I definitely believe that to be the case for mine. Having one record where one record will do while still allowing for two records where necessary will make life easier for domain owners trying to support one or both efforts. One could also, in theory, say that in the absence of an v=spf1 record, use the SPF2 record if present. Since there is a significant fielded code base of v=spf1 parsers in use, I think that it would make more sense to have Sender-ID parsers use either record when they are deployed. They key point is to make it easier for domain owners to publish. Getting a critical mass of domain owners with records is essential to escape the catch 22 of receivers not checking because no one publishes records and no one publishing records because no one checks. Since there is a significant base of v=spf1 records published, we can gain a lot of momentum by leveraging off of the SPF classic community. Finally, they are generally technically aware early adopters who can reasonably be expected to understand the impacts of 2821 versus 2822 checking and its effect on them. As far as what you call it, I don't care. I just use what's in the drafts. Myself, I wouldn't make any arguements in favor of Sender-ID over classic SPF, but Sender-ID is what's on the table, so that's what I'm trying to address. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 17:19: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 RAA10441 for ; Thu, 19 Aug 2004 17:19: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 i7JKvlD5067492; Thu, 19 Aug 2004 13:57: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 i7JKvlUJ067491; Thu, 19 Aug 2004 13:57:47 -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 i7JKvlfZ067481 for ; Thu, 19 Aug 2004 13:57: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 042DC41497; Thu, 19 Aug 2004 13:57:52 -0700 (PDT) Subject: RE: change of version string From: Douglas Otis To: Scott Kitterman Cc: MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1092949070.21602.52.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 19 Aug 2004 13:57:50 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-19 at 13:17, Scott Kitterman wrote: > Douglas Otis wrote: > > On Thu, 2004-08-19 at 09:32, Scott Kitterman wrote: > > > On Wed, 2004-08-11 at 5:59, william(at)elan.net wrote: > > > > > > > Perhaps it would be usefull if we allow one type of SPF record to > > > > reference (include, refer to) another type of SPF record, this would > > > > eliminate duplication problems in case of long records and avoid > > > > issues with large dns packet (because of multiple large txt records) > > > > as well. > > > > > > Or perhaps we could say that mail receivers MAY use an v=spf1 > > > records if no SPF2 record is returned. As I understand it, any > > > query for a TXT record will return all TXT records for the domain, > > > so if the TXT version of SPF2 is queried for, the v=spf1 record > > > will be returned if it exists. > > > > > > I understand that some are concerned with the difference between > > > 2821 mail.from and 2822 PRA. I've read all the drafts and as > > > nearly as I can tell, the mechanisms defined in my v=spf1 record > > > will work perfectly well for Sender-ID. > > > > > > For those, like me, for whom the records would be the same, > > > allowing for backward use of the earler SPF records would simplify > > > things considerably. It would also allow for Sender-ID checks to > > > be usefully evaluated much sooner since a large body of v=spf1 > > > records is already published. > > > > > > For those who are concerned about the distinction, but want to > > > use v=spf1, if they publish an SPF2 record, then they can define > > > that distinction. > > > > > > The change I am proposing would be to Page 5 of The Sender-ID > > > Record: Format and Interpretation, draft-ietf-marid-protocol-02. > > > > > > Change: > > > A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup > > > TXT record at the same time, or wait for negative answer. SPF2 type > > > SHOULD be used if available. > > > > > > To: > > > A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup > > > TXT record at the same time, or wait for negative answer. SPF2 type > > > SHOULD be used if available. If a v=spf1 record is returned from > > > the TXT record lookup, it MAY be used if and only if no SPF2 (SPF2 > > > RR or SPF2 TXT) record is returned. > > > > > > I believe that would make life simpler for many of us without undue > > > complication for others. > > > > There should be a concern doing this. Those that published v=spf1 > > records were intending this record to be applied to their RFC2821 MAIL > > FROM mailbox. This would allow _any_ RFC2822 mailbox to be used. Those > > publishing this record may have fully expected to retain this freedom, > > which now you feel obliged not to respect out of expediency. > > > > This lack of respect seems to extend to the use of SPF2, as the > > identifier for Sender-ID. Why not fully depart, instead of this half > > measure which only seems to obfuscate the fact these algorithms and > > mechanisms are entirely different. Sender-ID is not even better in many > > respects. > > > > -Doug > > Anyone who doesn't want their v=spf1 record used for Sender-ID checks can > publish an SPF2 record that says spf2.0/pra +all. Why not wait for them to opt-in to Sender-ID? You want mail rejected as a result of this usurping of the record? There may be many that feel Sender-ID records of any kind are not safe, as they rely upon the RFC2822 content, but there is no means for this content to be assured. Blacklisting could make _any_ records for Sender-ID perilous. They may have felt SPF was relatively safe, but feel Sender-ID is not. You offer no recourse as a result of this expediency taken. They may have been expecting to use differing access with this RFC2822 From address you destroy without risking the publishing of Sender-ID records. > That's an effective opt-out of Sender-ID. That is asking for their DNS to be bombarded with Sender-ID spam exploits. That is also asking for their domain to be blacklisted. Some opt-out. :( > While I agree that the records for SPF Classic and Sender-ID may be > different in some cases, I expect that will be the exception. For the > bulk of cases, I believe that the same record can be accurately parsed > for both. I definitely believe that to be the case for mine. That comparison is overlooking how these records are used. Publishing these records was agreeing to how this record was to be applied, and not to just their content. > Having one record where one record will do while still allowing for two > records where necessary will make life easier for domain owners trying to > support one or both efforts. One could also, in theory, say that in the > absence of an v=spf1 record, use the SPF2 record if present. Since there is > a significant fielded code base of v=spf1 parsers in use, I think that it > would make more sense to have Sender-ID parsers use either record when they > are deployed. This has happened because TXT records are being overloaded. What solution is there when the next version of records are to be published? > They key point is to make it easier for domain owners to publish. Getting a > critical mass of domain owners with records is essential to escape the catch > 22 of receivers not checking because no one publishes records and no one > publishing records because no one checks. Since there is a significant base > of v=spf1 records published, we can gain a lot of momentum by leveraging off > of the SPF classic community. Finally, they are generally technically aware > early adopters who can reasonably be expected to understand the impacts of > 2821 versus 2822 checking and its effect on them. This still does not provide a suitable option for saying "Leave me out of Sender-ID!" > As far as what you call it, I don't care. I just use what's in the drafts. > Myself, I wouldn't make any arguments in favor of Sender-ID over classic > SPF, but Sender-ID is what's on the table, so that's what I'm trying to > address. There are potentially serious downsides to Sender-ID and there should not be any auto-magic opt-in. Error on the side of caution. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 17:21:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10612 for ; Thu, 19 Aug 2004 17:21: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 i7JKvq5j067505; Thu, 19 Aug 2004 13:57:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JKvqT8067504; Thu, 19 Aug 2004 13:57:52 -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 i7JKvqFN067498 for ; Thu, 19 Aug 2004 13:57:52 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id C0F4616E0B for ; Thu, 19 Aug 2004 17:06:25 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Solution For Trojans In-Reply-To: Your message of "Thu, 19 Aug 2004 12:39:24 PDT." <1092944364.21514.55.camel@ddev.mail-abuse.org> Date: Thu, 19 Aug 2004 17:06:25 -0400 Message-Id: <20040819210625.C0F4616E0B@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > Perhaps one could describe the PRA algorithm as the MTA considering > prior hops, when the accountable identity is deciphered. Or, as the intermediate hops disclaiming responsibility for the message. I'm not sure it's a good idea for entities in the network to forward traffic they won't accept responsibility for. > With Sender-ID, the accountable entity is based solely upon RFC2822 > message content, this may change at each hop when a header is added, Then the intermediate hops have claimed responsibility for the message, and therefore are claiming to originate the message. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 17:51:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12992 for ; Thu, 19 Aug 2004 17:51:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLRw8P071963; Thu, 19 Aug 2004 14:27:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JLRw1M071962; Thu, 19 Aug 2004 14:27:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLRvYk071955 for ; Thu, 19 Aug 2004 14:27:58 -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 i7JLRuGs020094 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 Aug 2004 17:27:59 -0400 Date: Thu, 19 Aug 2004 17:27:56 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: IETF MARID WG Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 19 Aug 2004, Hallam-Baker, Phillip wrote: > > > I wonder if people are in a rush because they _know_ that if time is > > spent on analysis and hostile testing, that their schemes just won't > > measure up. > > Since Dean has objected to me taking this type of issue up > in private I will take it up on the list. I don't recall making any such objection. I've been quite happy to discuss things off-list with others, so long as they want to engage in rational discussion. > I find the above statement to be unprofessional and defamatory. > Attacking the motives of working group members in this way is > not acceptable. The eliptical method in which the attack is made > does not make it any less an attack. You're one to talk about personal attacks, suggesting that I don't understand the problem, that my opinion doesn't matter, etc. --Dean From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 17:54: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 RAA13185 for ; Thu, 19 Aug 2004 17:54:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLZWQh073029; Thu, 19 Aug 2004 14:35: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 i7JLZWTw073028; Thu, 19 Aug 2004 14:35: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 (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLZW7I073022 for ; Thu, 19 Aug 2004 14:35: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 EDC6041497; Thu, 19 Aug 2004 14:35:36 -0700 (PDT) Subject: Re: Solution For Trojans From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040819210625.C0F4616E0B@mail.nitros9.org> References: <20040819210625.C0F4616E0B@mail.nitros9.org> Content-Type: text/plain Message-Id: <1092951335.21639.11.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 19 Aug 2004 14:35:35 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-19 at 14:06, Alan DeKok wrote: > Douglas Otis wrote: > > Perhaps one could describe the PRA algorithm as the MTA considering > > prior hops, when the accountable identity is deciphered. > > Or, as the intermediate hops disclaiming responsibility for the > message. I'm not sure it's a good idea for entities in the network to > forward traffic they won't accept responsibility for. > > > With Sender-ID, the accountable entity is based solely upon RFC2822 > > message content, this may change at each hop when a header is added, > > Then the intermediate hops have claimed responsibility for the > message, and therefore are claiming to originate the message. I agree with this view. PRA does not represent the accountable entity, if viewed as the MTA being accountable. If authenticated, the EHLO domain properly provides the accountable entity. Message content should not excuse those running the MTA. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 18:20: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 SAA15708 for ; Thu, 19 Aug 2004 18:20: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 i7JLvV7E076696; Thu, 19 Aug 2004 14:57: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 i7JLvVbL076695; Thu, 19 Aug 2004 14:57:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JLvTRV076688 for ; Thu, 19 Aug 2004 14:57:30 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 94216 invoked from network); 19 Aug 2004 21:57:33 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 19 Aug 2004 21:57:33 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "Douglas Otis" Cc: "MARID" Subject: RE: change of version string Date: Thu, 19 Aug 2004 17:57:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <1092949070.21602.52.camel@ddev.mail-abuse.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Douglas Otis > Sent: Thursday, August 19, 2004 4:58 PM > To: Scott Kitterman > Cc: MARID > Subject: RE: change of version string > On Thu, 2004-08-19 at 13:17, Scott Kitterman wrote: > > Douglas Otis wrote: > > > On Thu, 2004-08-19 at 09:32, Scott Kitterman wrote: > > > > On Wed, 2004-08-11 at 5:59, william(at)elan.net wrote: > > > > > > > > > Perhaps it would be usefull if we allow one type of SPF record to > > > > > reference (include, refer to) another type of SPF record, > this would > > > > > eliminate duplication problems in case of long records and avoid > > > > > issues with large dns packet (because of multiple large > txt records) > > > > > as well. > > > > > > > > Or perhaps we could say that mail receivers MAY use an v=spf1 > > > > records if no SPF2 record is returned. As I understand it, any > > > > query for a TXT record will return all TXT records for the domain, > > > > so if the TXT version of SPF2 is queried for, the v=spf1 record > > > > will be returned if it exists. > > > > > > > > I understand that some are concerned with the difference between > > > > 2821 mail.from and 2822 PRA. I've read all the drafts and as > > > > nearly as I can tell, the mechanisms defined in my v=spf1 record > > > > will work perfectly well for Sender-ID. > > > > > > > > For those, like me, for whom the records would be the same, > > > > allowing for backward use of the earler SPF records would simplify > > > > things considerably. It would also allow for Sender-ID checks to > > > > be usefully evaluated much sooner since a large body of v=spf1 > > > > records is already published. > > > > > > > > For those who are concerned about the distinction, but want to > > > > use v=spf1, if they publish an SPF2 record, then they can define > > > > that distinction. > > > > > > > > The change I am proposing would be to Page 5 of The Sender-ID > > > > Record: Format and Interpretation, draft-ietf-marid-protocol-02. > > > > > > > > Change: > > > > A Sender-ID compliant MTA MUST look up SPF2 RR type, it > MAY lookup > > > > TXT record at the same time, or wait for negative > answer. SPF2 type > > > > SHOULD be used if available. > > > > > > > > To: > > > > A Sender-ID compliant MTA MUST look up SPF2 RR type, it > MAY lookup > > > > TXT record at the same time, or wait for negative > answer. SPF2 type > > > > SHOULD be used if available. If a v=spf1 record is returned from > > > > the TXT record lookup, it MAY be used if and only if no > SPF2 (SPF2 > > > > RR or SPF2 TXT) record is returned. > > > > > > > > I believe that would make life simpler for many of us without undue > > > > complication for others. > > > > > > There should be a concern doing this. Those that published v=spf1 > > > records were intending this record to be applied to their RFC2821 MAIL > > > FROM mailbox. This would allow _any_ RFC2822 mailbox to be > used. Those > > > publishing this record may have fully expected to retain this freedom, > > > which now you feel obliged not to respect out of expediency. > > > > > > This lack of respect seems to extend to the use of SPF2, as the > > > identifier for Sender-ID. Why not fully depart, instead of this half > > > measure which only seems to obfuscate the fact these algorithms and > > > mechanisms are entirely different. Sender-ID is not even > better in many > > > respects. > > > > > > -Doug > > > > Anyone who doesn't want their v=spf1 record used for Sender-ID > checks can > > publish an SPF2 record that says spf2.0/pra +all. > > Why not wait for them to opt-in to Sender-ID? You want mail rejected as > a result of this usurping of the record? There may be many that feel > Sender-ID records of any kind are not safe, as they rely upon the > RFC2822 content, but there is no means for this content to be assured. > Blacklisting could make _any_ records for Sender-ID perilous. They may > have felt SPF was relatively safe, but feel Sender-ID is not. You offer > no recourse as a result of this expediency taken. They may have been > expecting to use differing access with this RFC2822 From address you > destroy without risking the publishing of Sender-ID records. > > > That's an effective opt-out of Sender-ID. > > That is asking for their DNS to be bombarded with Sender-ID spam > exploits. That is also asking for their domain to be blacklisted. Some > opt-out. :( Acutally, now that I think about it, spf2.0/pra ?all would be a much safer opt out. Shouldn't get blacklisted over that one any more than you would by publishing nothing. > > While I agree that the records for SPF Classic and Sender-ID may be > > different in some cases, I expect that will be the exception. For the > > bulk of cases, I believe that the same record can be accurately parsed > > for both. I definitely believe that to be the case for mine. > > That comparison is overlooking how these records are used. Publishing > these records was agreeing to how this record was to be applied, and not > to just their content. I agree that v=spf1 publishers would have to look at Sender-ID and decide if they wanted to avoid it. I do think that it shouldn't be a major burden for those savy enough to have already adopted SPF classic. > > Having one record where one record will do while still allowing for two > > records where necessary will make life easier for domain owners > trying to > > support one or both efforts. One could also, in theory, say that in the > > absence of an v=spf1 record, use the SPF2 record if present. > Since there is > > a significant fielded code base of v=spf1 parsers in use, I > think that it > > would make more sense to have Sender-ID parsers use either > record when they > > are deployed. > > This has happened because TXT records are being overloaded. What > solution is there when the next version of records are to be published? > For the next version of the record, the actual RR type ought to be available. One major advantage of using one record for both is to minimize the load on TXT records. > > They key point is to make it easier for domain owners to > publish. Getting a > > critical mass of domain owners with records is essential to > escape the catch > > 22 of receivers not checking because no one publishes records and no one > > publishing records because no one checks. Since there is a > significant base > > of v=spf1 records published, we can gain a lot of momentum by > leveraging off > > of the SPF classic community. Finally, they are generally > technically aware > > early adopters who can reasonably be expected to understand the > impacts of > > 2821 versus 2822 checking and its effect on them. > > This still does not provide a suitable option for saying "Leave me out > of Sender-ID!" > Of course, being left out of both SPF and Sender-ID is trivial. Continue to not publish a record. Yes, it does make it harder to get out of Sender-ID, but not out of SPF. I think that spf2.0/pra ?all would be close enough. > > As far as what you call it, I don't care. I just use what's in > the drafts. > > Myself, I wouldn't make any arguments in favor of Sender-ID over classic > > SPF, but Sender-ID is what's on the table, so that's what I'm trying to > > address. > > There are potentially serious downsides to Sender-ID and there should > not be any auto-magic opt-in. Error on the side of caution. > > -Doug > Why not wait is twofold. First, two help jump-start adoption of the MARID solution (assuming it's Sender-ID) and the second is to simplify record publishing for those of us who will continue with Classic SPF. Most of the commentary I've seen on the list seems to favor a single record for both. There are some that are concerned with that. Here's a way for both groups to have their way. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 20:20: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 UAA21466 for ; Thu, 19 Aug 2004 20:20: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 i7JNunJu094953; Thu, 19 Aug 2004 16:56: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 i7JNun3J094952; Thu, 19 Aug 2004 16:56:49 -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 i7JNumwG094943 for ; Thu, 19 Aug 2004 16:56:48 -0700 (PDT) (envelope-from roy+dated+1095551806.489c19@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7JNwJ2i036987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Aug 2004 23:58:26 GMT (envelope-from roy+dated+1095551806.489c19@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7JNukRW087886 for ; Fri, 20 Aug 2004 00:56:46 +0100 (BST) (envelope-from roy+dated+1095551806.489c19@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7JNukxE087885 for ietf-mxcomp@imc.org; Fri, 20 Aug 2004 00:56:46 +0100 (BST) (envelope-from roy+dated+1095551806.489c19@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 20 Aug 2004 00:56:42 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16677.15929.717736.744858@giles.gnomon.org.uk> Date: Fri, 20 Aug 2004 00:56:41 +0100 To: "John Glube" Cc: "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter In-Reply-To: <018c01c48623$4dccc7e0$6c62fea9@ibmrkydk2ufvdd> References: <018c01c48623$4dccc7e0$6c62fea9@ibmrkydk2ufvdd> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "John" == John Glube writes: John> * Sender-ID does not call for receiving MTAs to do an SMTP John> Mail From check in the absence of PRA. John> However, we know as has been pointed out by doing so, this John> aids in the prevention of one form of 'backscatter' as John> pointed out by Chris and helps to minimize the risk of false John> positives, as has been pointed out by Meng. I'm still very confused. I don't see how giving an SMTP 5xx to mail in response to a forged MAIL FROM helps prevent backscatter. Giving a 5xx response to a forged MAIL FROM pretty much guarantees backscatter (the upstream MTA will bounce the message to the forged MAIL FROM). The only way to prevent backscatter would be to accept and silently discard the message, and that would involve throwing away the long-established principle of reliable mail delivery, permanently harming the Internet infrastructure for short term gain. There seems to be this myth circulating that SPF prevents backscatter because it checks the MAIL FROM. This just doesn't hold water: the effect of SPF is to cause all forged messages to bounce; it increases backscatter. This issue is a red herring. In a world where MAIL FROM is often forged, _all_ 5xx rejections (or indeed 4xx rejections) result in backscatter. There is nothing we (here, in this WG) can do about this. Other people are working on the problem; let's move on. -roy From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 20:56: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 UAA23111 for ; Thu, 19 Aug 2004 20:56: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 i7K0ShxX099458; Thu, 19 Aug 2004 17:28: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 i7K0ShMG099457; Thu, 19 Aug 2004 17:28:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K0SgLQ099443 for ; Thu, 19 Aug 2004 17:28:42 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 (unknown [216.191.52.74]) by mail.greatgulfhomes.com (Postfix) with SMTP id DA04636688B; Thu, 19 Aug 2004 20:37:46 -0400 (EDT) From: To: "'Roy Badami'" , "'John Glube'" Cc: "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter Date: Thu, 19 Aug 2004 20:27:06 -0400 Message-ID: <004901c4864c$70200680$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <16677.15929.717736.744858@giles.gnomon.org.uk> Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit If the sending MTA is a virus with its own SMTP engine, then the 5xx or 4xx DOES prevent backscatter, because the virus does nothing with the error. Similarly, if the sending MTA is a the direct connection from a spammer, backscatter prevented. It is my experience that most viruses with built in MTA engines do direct connect rather then try to relay through third party. If they do relay, they can be tracked and shut down manually (or by heuristics/volume rules on the relay) I am not sure what the normal is for spammer direct connects (from either spammers server, or spammers drone, either way doesn't matter). But I am sure the majority of bad bounces my users get are the result of forged mail-from's of spam and virus infections. Now that I have implemented DNSBL's the spam has gone down a lot, but the virus bounces have not. Ultimately, if the SENDING MTA is the actual source of the forged Mail-from, then spf with a 5xx or 4xx code does stop backscatter. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Roy Badami > Sent: Thursday, August 19, 2004 7:57 PM > To: John Glube > Cc: 'Daryl Odnert'; 'Chris Haynes'; 'Harry Katz'; 'IETF MARID WG' > Subject: RE: Point of Order: Incomplete, flawed response to MARID WG > Charter > > > > >>>>> "John" == John Glube writes: > > John> * Sender-ID does not call for receiving MTAs to do an SMTP > John> Mail From check in the absence of PRA. > > John> However, we know as has been pointed out by doing so, this > John> aids in the prevention of one form of 'backscatter' as > John> pointed out by Chris and helps to minimize the risk of false > John> positives, as has been pointed out by Meng. > > I'm still very confused. > > I don't see how giving an SMTP 5xx to mail in response to a forged > MAIL FROM helps prevent backscatter. Giving a 5xx response to a > forged MAIL FROM pretty much guarantees backscatter (the upstream MTA > will bounce the message to the forged MAIL FROM). > > The only way to prevent backscatter would be to accept and silently > discard the message, and that would involve throwing away the > long-established principle of reliable mail delivery, permanently > harming the Internet infrastructure for short term gain. > > There seems to be this myth circulating that SPF prevents backscatter > because it checks the MAIL FROM. This just doesn't hold water: the > effect of SPF is to cause all forged messages to bounce; it increases > backscatter. > > This issue is a red herring. In a world where MAIL FROM is often > forged, _all_ 5xx rejections (or indeed 4xx rejections) result in > backscatter. There is nothing we (here, in this WG) can do about > this. Other people are working on the problem; let's move on. > > -roy > From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 21:01:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23275 for ; Thu, 19 Aug 2004 21:01:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K0fnE1001341; Thu, 19 Aug 2004 17:41: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 i7K0fnBm001340; Thu, 19 Aug 2004 17:41:49 -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 i7K0fln5001332 for ; Thu, 19 Aug 2004 17:41:48 -0700 (PDT) (envelope-from roy+dated+1095554506.c577ab@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7K0hKrb041729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Aug 2004 00:43:26 GMT (envelope-from roy+dated+1095554506.c577ab@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7K0fkLK088271 for ; Fri, 20 Aug 2004 01:41:46 +0100 (BST) (envelope-from roy+dated+1095554506.c577ab@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7K0fkKC088270 for ietf-mxcomp@imc.org; Fri, 20 Aug 2004 01:41:46 +0100 (BST) (envelope-from roy+dated+1095554506.c577ab@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 20 Aug 2004 01:41:43 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16677.18631.471604.565677@giles.gnomon.org.uk> Date: Fri, 20 Aug 2004 01:41:43 +0100 To: Cc: "'Roy Badami'" , "'John Glube'" , "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter In-Reply-To: <004901c4864c$70200680$2766f30a@development.greatgulfhomes.com> References: <16677.15929.717736.744858@giles.gnomon.org.uk> <004901c4864c$70200680$2766f30a@development.greatgulfhomes.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 >>>>> "terry" == writes: terry> If the sending MTA is a virus with its own SMTP engine, terry> then the 5xx or 4xx DOES prevent backscatter, because the terry> virus does nothing with the error. That's true, but that's equally true of SPF, Sender ID, or any other cause of 5xx errors (and IME one of the biggest causes is "550 User Unknown" responses from old addresses) When there _is_ an upstream MTA, 5xx errors will cause backscatter; when there isn't they won't. SPF is no different from anything else in that respect. The only way that SPF can solve the backscatter problem is if _every_ MTA implements SPF checks, so that there's _never_ an upstream MTA to generate a bounce to a forged MAIL FROM. IMHO you need a pretty high SPF adoption before you will start to see any significant gains in backscatter reduction, and this will just take too long. This seems like a red herring to me. Backscatter is a big problem now, and it's going to get worse. I work for a company that's been on the Internet since 1992 (and had e-mail access since at least 1988). What we see is that the _vast_ majority of delivery attempts are to non-existent users. Sure, a lot of them are just speculative, but we see a *lot* of delivery attempts to e-mail addresses that have long since been disabled, many of which haven't been valid addresses for the best part of a decade. The backscatter problem needs to be solved quickly. There are promising solutions, and there are many people working on the problem. Sure, none of them are completely without pain, but I'm confident that the backscatter problem will be a non-issue long before we reach the level of SPF adoption that would be necessary to make a serious dent in it. Let's move on... -roy From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 21:20: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 VAA23869 for ; Thu, 19 Aug 2004 21:20:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K0uXeR003366; Thu, 19 Aug 2004 17:56:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K0uXpt003365; Thu, 19 Aug 2004 17:56:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K0uWwu003359 for ; Thu, 19 Aug 2004 17:56:32 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 (unknown [216.191.52.74]) by mail.greatgulfhomes.com (Postfix) with SMTP id 5F00236688B; Thu, 19 Aug 2004 21:05:37 -0400 (EDT) From: To: "'Roy Badami'" , Cc: "'John Glube'" , "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter Date: Thu, 19 Aug 2004 20:55:02 -0400 Message-ID: <005e01c48650$53d39f60$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <16677.18631.471604.565677@giles.gnomon.org.uk> Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I agree to move on, but 1 quick note re adoption, those that implement spf will suffer significantly less backscatter, because backscatter from the wrong mta will be rejected. And you may be right spf etc may cause non-spf implementors to receive more backscatter. But all this will likely serve to expedite the adoption of spf, as more people want to be like the other guy who has little/no backscatter. NOTE: Spamassassin clobbers my spam quite well. My users now only suffer from backscatter in the form of forged mail-from. If Sender-ID doesn't use spf or something to reject at the mail-from level, I am not going to waste a milli-second even considering adopting Sender-ID. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: Roy Badami [mailto:roy@gnomon.org.uk] > Sent: Thursday, August 19, 2004 8:42 PM > To: terry@ashtonwoodshomes.com > Cc: 'Roy Badami'; 'John Glube'; 'Daryl Odnert'; 'Chris Haynes'; 'Harry > Katz'; 'IETF MARID WG' > Subject: RE: Point of Order: Incomplete, flawed response to MARID WG > Charter > > > >>>>> "terry" == writes: > > terry> If the sending MTA is a virus with its own SMTP engine, > terry> then the 5xx or 4xx DOES prevent backscatter, because the > terry> virus does nothing with the error. > > That's true, but that's equally true of SPF, Sender ID, or any other > cause of 5xx errors (and IME one of the biggest causes is "550 User > Unknown" responses from old addresses) > > When there _is_ an upstream MTA, 5xx errors will cause backscatter; > when there isn't they won't. SPF is no different from anything else > in that respect. > > The only way that SPF can solve the backscatter problem is if _every_ > MTA implements SPF checks, so that there's _never_ an upstream MTA to > generate a bounce to a forged MAIL FROM. IMHO you need a pretty high > SPF adoption before you will start to see any significant gains in > backscatter reduction, and this will just take too long. > > This seems like a red herring to me. > > Backscatter is a big problem now, and it's going to get worse. I work > for a company that's been on the Internet since 1992 (and had e-mail > access since at least 1988). What we see is that the _vast_ majority > of delivery attempts are to non-existent users. Sure, a lot of them > are just speculative, but we see a *lot* of delivery attempts to > e-mail addresses that have long since been disabled, many of which > haven't been valid addresses for the best part of a decade. > > The backscatter problem needs to be solved quickly. There are > promising solutions, and there are many people working on the problem. > > Sure, none of them are completely without pain, but I'm confident that > the backscatter problem will be a non-issue long before we reach the > level of SPF adoption that would be necessary to make a serious dent > in it. > > Let's move on... > > -roy > From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 21:37:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24841 for ; Thu, 19 Aug 2004 21:37:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K1HZ35007264; Thu, 19 Aug 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 i7K1HZLF007263; Thu, 19 Aug 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 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 i7K1HXH7007254 for ; Thu, 19 Aug 2004 18:17:33 -0700 (PDT) (envelope-from roy+dated+1095556652.41b0d4@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7K1J7Ip045517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Aug 2004 01:19:12 GMT (envelope-from roy+dated+1095556652.41b0d4@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7K1HWbY088866 for ; Fri, 20 Aug 2004 02:17:32 +0100 (BST) (envelope-from roy+dated+1095556652.41b0d4@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7K1HWcX088865 for ietf-mxcomp@imc.org; Fri, 20 Aug 2004 02:17:32 +0100 (BST) (envelope-from roy+dated+1095556652.41b0d4@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 20 Aug 2004 02:17:29 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16677.20777.118805.174875@giles.gnomon.org.uk> Date: Fri, 20 Aug 2004 02:17:29 +0100 To: Cc: "'Roy Badami'" , "'John Glube'" , "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter In-Reply-To: <005e01c48650$53d39f60$2766f30a@development.greatgulfhomes.com> References: <16677.18631.471604.565677@giles.gnomon.org.uk> <005e01c48650$53d39f60$2766f30a@development.greatgulfhomes.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 >>>>> "terry" == writes: terry> I agree to move on, but 1 quick note re adoption, those terry> that implement spf will suffer significantly less terry> backscatter, because backscatter from the wrong mta will be terry> rejected. I think you're mistaken. Backscatter generally comes from legitimate MTAs (as you point out, spammers/viruses themselves don't bother to generate bounces). When a forged message transits a legitimate MTA, and that MTA is unable to deliver (receives a 5xx for whatever reason) it generates a bounce. This bounce is from <>, so SPF will check the HELO. Being a legitimate MTA, it includes its legitimate name in the HELO string. The bounce will pass an SPF check. I say again: SPF does not prevent backscatter (at least not unless every MTA on the planet adopts it). The backscatter issue does not consitute an argument against proceeding with the work on Sender ID and CSV (the WG's current work items) though both will result in backscatter to some extent. -roy From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 22:07:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25856 for ; Thu, 19 Aug 2004 22: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 i7K1kghJ011900; Thu, 19 Aug 2004 18:46: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 i7K1kgYs011899; Thu, 19 Aug 2004 18:46:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K1kf41011890 for ; Thu, 19 Aug 2004 18:46:41 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 (unknown [216.191.52.74]) by mail.greatgulfhomes.com (Postfix) with SMTP id DDE4B3668DC; Thu, 19 Aug 2004 21:55:46 -0400 (EDT) From: To: "'Roy Badami'" , Cc: "'John Glube'" , "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter Date: Thu, 19 Aug 2004 21:45:11 -0400 Message-ID: <006901c48657$55a57500$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <16677.20777.118805.174875@giles.gnomon.org.uk> Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Roy Badami [mailto:roy@gnomon.org.uk] > Sent: Thursday, August 19, 2004 9:17 PM > To: terry@ashtonwoodshomes.com > Cc: 'Roy Badami'; 'John Glube'; 'Daryl Odnert'; 'Chris Haynes'; 'Harry > Katz'; 'IETF MARID WG' > Subject: RE: Point of Order: Incomplete, flawed response to MARID WG > Charter > > > I say again: > > SPF does not prevent backscatter (at least not unless every MTA on the > planet adopts it). SO?! I only care about if certain portions of the internet adopt, specifically those who know my users/have my users addresses in their addressbook. (Read "stop those virus bounces from infected people who know my people") > > The backscatter issue does not consitute an argument against > proceeding with the work on Sender ID and CSV (the WG's current work > items) though both will result in backscatter to some extent. > > -roy > OK. I just reread the charter: http://www.ietf.org/html.charters/marid-charter.html And if MTA autorization: -increases backspatter (you said it, not me) -doesn't stop spam (may reduce only 1 type of spam source, spammers will adapt) -only makes a dent in 1 kind of phishing (can't touch social engineering types) I have been trying to keep up with the group, but perhaps I fell behind: Please help me out: What is "MTA Authorization" aka "Sender ID" good for then? Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 22:13: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 WAA26120 for ; Thu, 19 Aug 2004 22:13: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 i7K1ptNJ012688; Thu, 19 Aug 2004 18:51: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 i7K1pt7Q012687; Thu, 19 Aug 2004 18:51: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 i7K1ptB7012679 for ; Thu, 19 Aug 2004 18:51: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 D40754149B; Thu, 19 Aug 2004 18:51:59 -0700 (PDT) Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter From: Douglas Otis To: terry@ashtonwoodshomes.com Cc: "'Roy Badami'" , "'John Glube'" , "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" In-Reply-To: <005e01c48650$53d39f60$2766f30a@development.greatgulfhomes.com> References: <005e01c48650$53d39f60$2766f30a@development.greatgulfhomes.com> Content-Type: text/plain Message-Id: <1092966718.22201.20.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 19 Aug 2004 18:51: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 Thu, 2004-08-19 at 17:55, terry@ashtonwoodshomes.com wrote: > I agree to move on, but 1 quick note re adoption, those that implement spf will suffer significantly > less backscatter, because backscatter from the wrong mta will be rejected. > > And you may be right spf etc may cause non-spf implementors to receive more backscatter. > > But all this will likely serve to expedite the adoption of spf, as more people want to be like the > other guy who has little/no backscatter. This Back-door issue will improve commensurate with adoption of a solution, as spammers are not often the direct source of this traffic, but instead comes from sites at the end of a relay that would otherwise not wish to send this traffic. Few solutions have an impact that exceeds adoption. That a solution does not TOTALLY prevent a problem without 100% adoption and therefore is a reason to dismiss such for consideration seems absurd. To say this is an unrelated problem, or one to be solved differently, seems to overlook the relationship of the information needed to solve each issue separately. This problem can be related to the information of the mail channel, or to solutions for the forwarding problem created by Sender-ID, as example. Of course, the reaction to not being allowed in the Front-door, there is always the Back-door being the Return-Path now being ignored. Both doors need defended as closing one, will increase the traffic through the other. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 22:33: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 WAA26930 for ; Thu, 19 Aug 2004 22:33: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 i7K25pNm014769; Thu, 19 Aug 2004 19:05: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 i7K25pjS014768; Thu, 19 Aug 2004 19:05:51 -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 i7K25oCO014760 for ; Thu, 19 Aug 2004 19:05:50 -0700 (PDT) (envelope-from roy+dated+1095559549.e37d0d@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7K27Omb051019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Aug 2004 02:07:30 GMT (envelope-from roy+dated+1095559549.e37d0d@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7K25ngY089778 for ; Fri, 20 Aug 2004 03:05:49 +0100 (BST) (envelope-from roy+dated+1095559549.e37d0d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7K25nbJ089777 for ietf-mxcomp@imc.org; Fri, 20 Aug 2004 03:05:49 +0100 (BST) (envelope-from roy+dated+1095559549.e37d0d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 20 Aug 2004 03:05:47 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16677.23674.451705.626167@giles.gnomon.org.uk> Date: Fri, 20 Aug 2004 03:05:46 +0100 To: Cc: "'Roy Badami'" , "'John Glube'" , "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter In-Reply-To: <006901c48657$55a57500$2766f30a@development.greatgulfhomes.com> References: <16677.20777.118805.174875@giles.gnomon.org.uk> <006901c48657$55a57500$2766f30a@development.greatgulfhomes.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 >>>>> "terry" == writes: terry> SO?! I only care about if certain portions of the internet terry> adopt, specifically those who know my users/have my users terry> addresses in their addressbook. (Read "stop those virus terry> bounces from infected people who know my people") Well, if every virus (or spammer) who has the e-mail address of one of your users is sending mail out through an ISP that implements SPF checks on their outbound mail relays, then yes, that would make a significant dent in amount of backscatter that your users receive. I'm ignoring spammers who send mail out through open relays; they're unlikely to implement SPF checks, but you can hope to block many of them through DNSBLs... terry> I have been trying to keep up with the group, but perhaps I terry> fell behind: Please help me out: What is "MTA terry> Authorization" aka "Sender ID" good for then? It's a tool; it's not a panacea. Authentication doesn't stop spam, but it enables technologies that have promise in attacking the spam problem (accreditation and reputation systems). It may not be a panacea against phishing, but it is a useful tool in the war. It's also a useful tool to stop people sending mail pretending to be me. Many corporates care about the fact that people are receiving spam and viruses claiming to be from them, and many non-technical users actually believe that the company sent them the spam or virus. These are early days for sender authentication schemes. Maybe they'll be useful, maybe they won't. Personally, I think they will be, though they won't be the anti-spam panacea that some people seem to believe. As I see it, the purpose of this WG is to give us a MARID standard to deploy and test. Until we have that, know one will know for sure how well MARID will (or won't) fare in the real world. -roy From owner-ietf-mxcomp@mail.imc.org Thu Aug 19 23:09: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 XAA28730 for ; Thu, 19 Aug 2004 23:09: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 i7K2l25N019905; Thu, 19 Aug 2004 19:47: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 i7K2l28w019904; Thu, 19 Aug 2004 19:47:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K2l1Wd019890 for ; Thu, 19 Aug 2004 19:47:01 -0700 (PDT) (envelope-from roy+dated+1095562019.c97d23@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7K2mZ4h056056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Aug 2004 02:48:41 GMT (envelope-from roy+dated+1095562019.c97d23@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7K2kx5Z090181 for ; Fri, 20 Aug 2004 03:46:59 +0100 (BST) (envelope-from roy+dated+1095562019.c97d23@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7K2kxMa090180 for ietf-mxcomp@imc.org; Fri, 20 Aug 2004 03:46:59 +0100 (BST) (envelope-from roy+dated+1095562019.c97d23@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 20 Aug 2004 03:46:56 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16677.26143.880524.542605@giles.gnomon.org.uk> Date: Fri, 20 Aug 2004 03:46:55 +0100 To: Douglas Otis Cc: terry@ashtonwoodshomes.com, "'Roy Badami'" , "'John Glube'" , "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter In-Reply-To: <1092966718.22201.20.camel@ddev.mail-abuse.org> References: <005e01c48650$53d39f60$2766f30a@development.greatgulfhomes.com> <1092966718.22201.20.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: This will be my last post on this topic. I think I've made my points as clearly as I can; beyond that we'll just have to agree to differ. I think this seems to be intended as a reply to me, rather than a reply to Terry, so I'll reply to it. Douglas> This Back-door issue will improve commensurate with Douglas> adoption of a solution, as spammers are not often the Douglas> direct source of this traffic, but instead comes from Douglas> sites at the end of a relay that would otherwise not wish Douglas> to send this traffic. I'm not really sure I know what you mean by 'back door', 'front door' and 'at the end of a relay'. Although mail may transit many MTAs, most mail typically goes directly from a final outbound MTA in the originating administrative domain to an initial inbound MTA at the receiving adminsitrative domain. Either the outbound administrative domain implements checks on outgoing mail, or unwanted/invalid mail will be rejected by the MTA in the recipient's adminitrative domain, causing the outbound MTA to generate a bounce. This property is common to _all_ solutions that mandate or suggest rejecting unwanted messages at the SMTP level. To my knowledge, all proposals on the table allow SMTP rejection, and as far as I can see their behaviour with respect to backscatter will be very similar. Douglas> Few solutions have an impact that exceeds adoption. That Douglas> a solution does not TOTALLY prevent a problem without Douglas> 100% adoption and therefore is a reason to dismiss such Douglas> for consideration seems absurd. I'm not arguing that. I'm arguing that even a MARID solution that validates MAIL FROM (such as SPF) is unlikely to have _any_ significant affect on the backscatter problem until it reaches _very_ high levels of adoption. More to the point, it needs adoption on ISPs outbound relays, and at the moment interest seems to be more in validating _incoming_ mail. Douglas> To say this is an unrelated problem, or one to be solved Douglas> differently, seems to overlook the relationship of the Douglas> information needed to solve each issue separately. Well, I believe largely it is. IME the main cause of backscatter is bounces due to spam or viruses sent to addresses that no longer exist (resulting in 550 User Unknown). In many cases the inbound relay in the receiving administrative domain rejects the message with 550, resulting in the outbound relay of the origninating administrative domain generating a bounce. However, in a large number of cases the bounce is actually generated by the receiving administrative domain _after_ the message has been accepted by the initial inbound relay. There are two main reasons why this happens (and whether you like it or not, this isn't going to change any time soon). The first is that the architecture of some widely used MTAs doesn't allow them to perform SMTP-time checks for unknown users. qmail and Lotus Notes spring to mind. qmail is widely used by ISPs, and Lotus Notes has significant adoption in large corporates. The second is the design of large mail clusters is ISPs or complex mail routing environments in large corporates. In many cases the initial inbound relay doesn't know that the validity of the address, but simply forwards the message to other internal MTAs based on the domain (or subdomain). Hence, when a 550 User Unknown is generated, it's the receiving domain that's forced to generate a bounce (regardless of the choice of MTA software). So yes, I think that the backscatter problem is largely unrelated to the work we are doing here. Some solutions may make the problem marginally worse; some may even make things very marginally better (though I'm dubious). The only things that will make things substantially better are either mandatory checks on outbound mail from all (or the majority) or ISPs, or solutions where the bounce is validated by the recipient (such as BATV, SES, Message-ID tracking schemes, etc). I don't think the former will happen quickly enough to prevent widespread adoption of the latter. -roy From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 00:38:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02740 for ; Fri, 20 Aug 2004 00:38:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K4FhZe032937; Thu, 19 Aug 2004 21:15: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 i7K4Fhog032936; Thu, 19 Aug 2004 21:15:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K4Ff3Z032926 for ; Thu, 19 Aug 2004 21:15:42 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1By0oU-0005Qe-HL for ietf-mxcomp@imc.org; Thu, 19 Aug 2004 23:15:46 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Thu, 19 Aug 2004 22:27:54 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 18 Aug 2004 14:58:55 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Chart er 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 "Hallam-Baker, Phillip" writes: >> A "draft" is >> what we have now. A "draft" is worked on, edited, and finally moves to >> "Proposed Standard". A "Proposed Standard" moves to "Draft >> Standard". It does not move to "draft" ordinarilly. > > There is no code required at all at this point. We have multiple > independent implementations that provide proof of concept. The > creation of compliant versions is dependent on progress to > Proposed Standard. While working code is not always required, that doesn't mean the IESG will not require it. I'm sure that many people have read RFC2026 at least once, but I figured I'd snip out this section on what it takes to qualify for an RFC starting on the standard-track. 4.1.1 Proposed Standard The entry-level maturity for the standards track is "Proposed Standard". [...] A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. 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. I think that MARID may well be considered to have a "significant operational impact on the Internet", and thus the IESG may require "implementation and/or operational experience". At a minimum, our RFCs will need to be "well-understood". While we may not need a full-blown implementation, I personally wouldn't consider an algorithm to be "well-understood" if there at least some dry runs on real data from multiple sources. While there have been a couple of dry runs by both Andy Newton and Mark Lentczner, they were both tiny (personal mail boxes). They also both showed that the PRA may well have a far greater error rate than SPF-classic. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 00:38: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 AAA02741 for ; Fri, 20 Aug 2004 00:38:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K4FqtH032960; Thu, 19 Aug 2004 21:15: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 i7K4FqlZ032959; Thu, 19 Aug 2004 21:15: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 i7K4FpAX032953 for ; Thu, 19 Aug 2004 21:15: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 1By0od-0005Rj-3R for ietf-mxcomp@imc.org; Thu, 19 Aug 2004 23:15:58 -0500 To: "IETF MARID WG" References: <200408161919.PAA24682@ietf.org> <20040818215247.GE50011@verdi> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 19 Aug 2004 23:11:03 -0500 In-Reply-To: <20040818215247.GE50011@verdi> (John Leslie's message of "Wed, 18 Aug 2004 17:52:47 -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: I-D ACTION:draft-ietf-marid-protocol-01.txt 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 <20040818215247.GE50011@verdi> John Leslie writes: > I recognize how hard it is to put together a spec: in no way do I > wish to belittle the work that went into this. But RFCs are forever. > (Please be assured I was at least this picayune with Dave and Doug's > drafts.) Thanks for the review John! I hope many of your points make it into a new draft. > ] 2.1.8 Minor Version > ] This document only specifies records with a minor version of "0". > ] All published records MUST start with "spf2.0/pra". > ] > ] Future versions of this document may define other minor versions to > ] be used. > > This leaves me confused as to how we could manage a transition to > the next minor version. I recommend giving careful thought to that > expandability issue. The creation of a minor version number was mandated during the IETF-60 session. No semantics of what the minor version number should do were given. I've talked with both Mark and Meng about this, and we all agree that we can't think of any use for a minor version, which was why it wasn't there in the first place. > ] 4.2 "include" > > There's a lot of room for confusion between "include" and "redirect". > If one looks long enough, it becomes clear that the basic difference > is that "include" returns, thus can generate only four conditions, > while "redirect" doesn't return, thus can generate all seven. > > I think it would help to say so in as many words. I'm not sure what you mean by "four conditions", but I don't think your understanding is correct. An include: can cause both PermError and TempError, and if there is a match, it can generate any of Pass, Fail, SoftFail and Neutral. Personally, I think that "include" is a really bad name for this mechanism. I think a much better name would be something like "if-pass". I've seen a lot of people get tripped up by thinking that the include mechanism effectively includes another record, which it doesn't. Since we are going to have to republish everything anyway, it would be possible to rename the the include mechanism without causing any problems. > ] 4.3 "a" > > Here we get into serious IPv4 vs. IPv6 territory. > > I assume that if is v4, one implements an "A" lookup, while > if is v6, one implements an "AAAA" lookup. It wouldn't hurt, IMHO, > to say so explicitly. Up in section 4., there is the following text: When any mechanisms fetches host addresses to compare with , when is an IPv4 address, A records are fetched, when is an IPv6 address, AAAA records are fetched. I tend to agree that this should be made more explicit > ] 6.1 Unrecognized Mechanisms and Modifiers > ] New mechanisms can only be introduced by new versions of this > ] document. > > While I _can_ wrap my mind about the idea that we have a > field which MUST always be ignored, Yeah, I guess if someone can come up with a very clear purpose for the minor version, I think it will just be a forever-wart caused people who happened to go to the IETF-60 session and didn't really think things through. > [...], I'm having trouble wrapping my > mind around the idea that we MAY introduce new mechanisms, but all > receivers that haven't been updated yet MUST fail to evaluate our > SPF2 records in a useful way. The whole "unknown mechanism" logic in for SPF and SenderID is totally bogus. There is *nothing* that can be done with unknown mechanisms that can't be better done with unknown modifiers. Worse, they cause confusion and allow for typos to cause sporadic failures. For example, if someone publishes "spf2.0/pra mx ipv4:1.2.3.4 -all" they will never get to the -all. If most of the valid email comes from the MX IP addresses, this error will not show up most of the time. This is actually a very common error in SPF records. The result of this "unknown mechanism" stuff is that SenderID will be less reliable, with zero upside. > ] 6.2 Processing Limits > ]... > ] MTAs or other processors MAY also impose a limit on the maximum > ] amount of elapsed time to evaluate check_host(). I have to admit that I'm very disappointed that these processing limits have not been improved. Right now the only way a SenderID implementation can prevent DoS attacks against third parties is to not be RFC compliant. The DoS problem isn't with the domain owner generating records that require too many DNS lookups on their server. Domain owners will quickly figure out that that is a bad idea. The DoS problem isn't with the receiver of the email. If SenderID checking is too expensive, they will simply become non-RFC complaint and abort the checks. The problem is that a malicious domain owner can set up SenderID records that cause traffic to a third party victim. Then, by using some simple SMTP sessions, the malicious can greatly amplify their bandwidth by generating bogus DNS request and use the receiving MTA to hide who is actually doing the attacks. The load created on each individual receiving MTA can easily be made low enough that they will not notice that they are being used as part of an attack. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 00: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 AAA03271 for ; Fri, 20 Aug 2004 00:52:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K4XAqa035345; Thu, 19 Aug 2004 21:33: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 i7K4XAn5035344; Thu, 19 Aug 2004 21:33:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K4X93L035338 for ; Thu, 19 Aug 2004 21:33:09 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7K4X0NM027842 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 20 Aug 2004 00:33:00 -0400 Date: Fri, 20 Aug 2004 00:33:00 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Roy Badami cc: terry@ashtonwoodshomes.com, "'John Glube'" , "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter In-Reply-To: <16677.20777.118805.174875@giles.gnomon.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 20 Aug 2004, Roy Badami wrote: > >>>>> "terry" == writes: > > terry> I agree to move on, but 1 quick note re adoption, those > terry> that implement spf will suffer significantly less > terry> backscatter, because backscatter from the wrong mta will be > terry> rejected. Regards to Terry point: Backscatter from the MTA would not be rejected since it is a message _to_ the backscatter victim _from_ the MTA. Even if both MTAs participate in SPF, the SPF check should find the MTA's mailer delivery system address to be authorized to that MTA. > I think you're mistaken. Backscatter generally comes from legitimate > MTAs (as you point out, spammers/viruses themselves don't bother to > generate bounces). > > When a forged message transits a legitimate MTA, and that MTA is > unable to deliver (receives a 5xx for whatever reason) it generates a > bounce. This bounce is from <>, so SPF will check the HELO. Being a > legitimate MTA, it includes its legitimate name in the HELO string. > The bounce will pass an SPF check. Exactly right. It is probably from postmaster, but could be from <>. Every user everywhere is the customer of an ISP or a company with an MTA. _All_ spam is sent by customers of someone. So _all_ abuse has a relay that will just relay email. An inside "closed" relay is "open" to anyone inside the network. If we assume that anti-trust laws will require ISPs to permit other ISPs to provide services to unbundled email, then SPF will have no effect at all: Ever. If that isn't the case, then _every_ forged email results in backscatter: _All_, _100%_ SPF and many other schemes assumes that the abusers won't alter their habits. The goal of the abuser is to abuse. Of course they are going to alter their sending habits. This has happened again and again. > I say again: > > SPF does not prevent backscatter (at least not unless every MTA on the > planet adopts it). > > The backscatter issue does not consitute an argument against > proceeding with the work on Sender ID and CSV (the WG's current work > items) though both will result in backscatter to some extent. > > -roy > > From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 01:07: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 BAA04088 for ; Fri, 20 Aug 2004 01:07: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 i7K4lXe2037608; Thu, 19 Aug 2004 21:47: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 i7K4lXel037607; Thu, 19 Aug 2004 21:47:33 -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 i7K4lWau037599 for ; Thu, 19 Aug 2004 21:47:33 -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 i7K4lUYb028113 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 20 Aug 2004 00:47:30 -0400 Date: Fri, 20 Aug 2004 00:47:30 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Roy Badami cc: terry@ashtonwoodshomes.com, "'John Glube'" , "'Daryl Odnert'" , "'Chris Haynes'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter In-Reply-To: <16677.23674.451705.626167@giles.gnomon.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 20 Aug 2004, Roy Badami wrote: > I'm ignoring spammers who send mail out through open relays; they're > unlikely to implement SPF checks, but you can hope to block many of > them through DNSBLs... This isn't right. Not to /open/ the open relay question, but see http://www.av8.net/openrelay.html I realize that many people disagree with that, but courts and lawyers have agreed with us. So, I won't argue this if you disagree. But if you didn't know, it may be interesting. For abusers, there is no difference between an ISP's closed relays and open relays, unless they are self-described anti-spammers who think that by abusing the relay they will get it closed or something. Closed relays are "open" to those using the network's IP Address space. All abusers everywhere have one or more relays available to them, because they are "customers" right up until they aren't. There is one difference between open and closed relays since the open relay blacklists closed down: its not so easy to find open relays to abuse. Though we and other ISPs found some time ago that blocking the blacklist scanning stopped open relay abuse. But networks can't hide their closed relays from their customers. --Dean From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 02:02: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 CAA09350 for ; Fri, 20 Aug 2004 02:02: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 i7K5g5C3046616; Thu, 19 Aug 2004 22:42: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 i7K5g5M0046615; Thu, 19 Aug 2004 22:42:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mynah.mail.pas.earthlink.net (mynah.mail.pas.earthlink.net [207.217.120.228]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K5g43q046605 for ; Thu, 19 Aug 2004 22:42:04 -0700 (PDT) (envelope-from tripp@corp.earthlink.net) Received: from user-11fanmm.dsl.mindspring.com ([66.245.94.214] helo=[192.168.0.2]) by mynah.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 4.34) id 1By2AG-0001HN-Cv for ietf-mxcomp@imc.org; Thu, 19 Aug 2004 22:42:12 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <200408161919.PAA24682@ietf.org> <20040818215247.GE50011@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tripp Cox Subject: Re: I-D ACTION:draft-ietf-marid-protocol-01.txt Date: Fri, 20 Aug 2004 01:42:09 -0400 To: "IETF MARID WG" X-Mailer: Apple Mail (2.619) X-ELNK-Trace: 3507b2fe2d9b3ca5cc16ce54e02836f04d269a8f2f0f5df82203075f410709ae350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.94.214 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 20, 2004, at 12:11 AM, wayne wrote: > > The creation of a minor version number was mandated during the IETF-60 > session. No semantics of what the minor version number should do were > given. I've talked with both Mark and Meng about this, and we all > agree that we can't think of any use for a minor version, which was > why it wasn't there in the first place. As SPF 2.0 is a policy that speaks only to how to deal with the PRA, I could see a minor version being useful if additional policy classes are added. For example, today: example.com. IN SPF2 "spf2.0/pra mx a:smtp.example.com ?all" Tomorrow: example.com. IN SPF2 "spf2.1/pra mx a:smtp.example.com ?all" IN SPF2 "spf2.1/csa mx a:smtp.example.com a:listserv.example.com -all" 4.3.2.1.IN-ADDR.ARPA IN SPF2 "spf2.1/mta a:smtp.example.com" Where pra is the policy a receiver should apply when performing authorization based on the PRA, csa on the EHLO domain, and mta on the client IP. Perhaps a major version change would be in order if, say, SPF were to adopt an XML or binary record structure in the DNS. Perhaps also if the existing language's mechanisms are modified. From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 09:13: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 JAA11415 for ; Fri, 20 Aug 2004 09:13: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 i7KCmMl2013390; Fri, 20 Aug 2004 05:48: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 i7KCmMvS013389; Fri, 20 Aug 2004 05:48: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 i7KCmL2L013383 for ; Fri, 20 Aug 2004 05:48: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 1By8oY-00031V-7j for ietf-mxcomp@imc.org; Fri, 20 Aug 2004 07:48:21 -0500 To: "IETF MARID WG" References: <200408161919.PAA24682@ietf.org> <20040818215247.GE50011@verdi> From: wayne Reply-To: "IETF MARID WG" Date: Fri, 20 Aug 2004 07:48:14 -0500 In-Reply-To: (Tripp Cox's message of "Fri, 20 Aug 2004 01:42:09 -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: Allowing other scopes on SPF2 records (Was: I-D ACTION:draft-ietf-marid-protocol-01.txt) 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 Tripp Cox writes: > On Aug 20, 2004, at 12:11 AM, wayne wrote: >> >> The creation of a minor version number was mandated during the IETF-60 >> session. No semantics of what the minor version number should do were >> given. I've talked with both Mark and Meng about this, and we all >> agree that we can't think of any use for a minor version, which was >> why it wasn't there in the first place. > > As SPF 2.0 is a policy that speaks only to how to deal with the PRA, I > could see a minor version being useful if additional policy classes > are added. There is no need to use the minor version for the ability to extend the SPF2 records to different scopes. The current marid-protocol I-D gives the following ABNF for the version token: version = "spf2." ver-minor "/pra" [ ver-ext ] ver-minor = 1*DIGIT ver-ext = "," *VCHAR So, things like "spf2.0/pra,mailfrom" and "spf2.0/pra,helo" are perfectly valid. Personally, I would *really* like to see this changed to use the following ABNF: version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) ver-minor = 1*DIGIT ver-scope = "pra" / name Where name is already defined as: name = alpha *( alpha / digit / "-" / "_" / "." ) This would mean that SPF2 records would not *have* to be used for the PRA. It would also allow SPF2 records to be used for SPF-classic usage. For the vast majority of domains that have the same policies for both the PRA usage and the SPF usage, people could publish: SPF2 "spf2.0/spf,pra ..." -wayne From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 09: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 JAA12620 for ; Fri, 20 Aug 2004 09:38: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 i7KDBRAx016929; Fri, 20 Aug 2004 06:11: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 i7KDBRDM016928; Fri, 20 Aug 2004 06:11:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KDBQhi016901 for ; Fri, 20 Aug 2004 06:11:27 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7KDBKM4020155 for ; Fri, 20 Aug 2004 14:11:20 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7KDBJat020153; Fri, 20 Aug 2004 14:11:19 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Charter References: <16677.15929.717736.744858@giles.gnomon.org.uk> <004901c4864c$70200680$2766f30a@development.greatgulfhomes.com> <16677.18631.471604.565677@giles.gnomon.org.uk> From: Graham Murray Date: Fri, 20 Aug 2004 14:11:19 +0100 In-Reply-To: <16677.18631.471604.565677@giles.gnomon.org.uk> (Roy Badami's message of "Fri, 20 Aug 2004 01:41:43 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Roy Badami writes: > When there _is_ an upstream MTA, 5xx errors will cause backscatter; > when there isn't they won't. SPF is no different from anything else > in that respect. If the upstream MTA (and any MTAs upstream of it) also implements SPF (or whatever other protocol) then the 5xx error will be sent to the originator and there would be no back scatter as the mail would be rejected at the first relay. From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 10: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 KAA17588 for ; Fri, 20 Aug 2004 10: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 i7KEIU4s027105; Fri, 20 Aug 2004 07: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 i7KEIUqh027104; Fri, 20 Aug 2004 07:18:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts25-srv.bellnexxia.net (tomts25.bellnexxia.net [209.226.175.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KEITm0027089 for ; Fri, 20 Aug 2004 07:18:30 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([65.93.207.100]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040820141828.QKRR7925.tomts25-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 20 Aug 2004 10:18:28 -0400 From: "John Glube" To: "'Harry Katz'" , "'Chris Haynes'" Cc: "'Nate Leon'" , Subject: RE: Forged Sender (Resent-From) attacks Date: Fri, 20 Aug 2004 10:20:05 -0400 Message-ID: <01ac01c486c0$ca404930$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7KEIUm0027099 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit From: Harry Katz Sent: August 19, 2004 2:30 PM >The point I'm trying to make, and which has been made many >times before, is that there is a semantic difference >between the 2821 MAIL FROM address and the 2822 headers. >So maybe I should have said "the IP addresses of servers >authorized to transmit mail on behalf of the domain that >receives your bounce messages." While recognizing this semantic difference, can we put together a BCP as you propose, which suggests receivers do at least these two things: * Do a check of the 2821 MAIL FROM address to see whether it is malformed and if it is to reject the data transfer. (I believe you have already proposed this part.) * In the absence of PRA at the data transfer stage, do a 2821 MAIL FROM address check using SPF records and if the 2821 MAIL FROM address is spoofed, reject the message at the data transfer stage. (This would pick up the concerns others have expressed.) In the first case, since there is an invalid or malformed 2821 MAIL FROM address and in the second case, since there is a spoofed 2821 MAIL FROM address, the only question is what form of rejection notice should be sent and to whom should it be sent? I would suggest in the first case, since it can be said the message is a nullity, no rejection notice is required. Chris has suggested in the second case, since this message is also a nullity, no rejection notice is required. Although I tend to agree, my concern is that a spoofed 2821 MAIL From address could be the result of mis-configured SPF record and not deliberate spoofing by a spammer. (We have already seen examples of this in the field.) As a result would not a simple 55x message with the content as suggested by the SPF draft protocols suffice to alert someone of the potential problem? I am putting forward these comments as suggestions for discussion purposes, so that the proposal of a BCP can be moved forward allowing folks to square the circle. :-) John P.S. There has been a suggestion put by both Scott and Wayne in the Point of Order discussion concerning how to deal with the two version string question. I simply note these suggestions for your consideration. Cheers, John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 12:16: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 MAA24418 for ; Fri, 20 Aug 2004 12:16: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 i7KFrOVJ040502; Fri, 20 Aug 2004 08:53: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 i7KFrOaG040501; Fri, 20 Aug 2004 08:53:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mynah.mail.pas.earthlink.net (mynah.mail.pas.earthlink.net [207.217.120.228]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFrO2k040495 for ; Fri, 20 Aug 2004 08:53:24 -0700 (PDT) (envelope-from tripp@corp.earthlink.net) Received: from user-11fanmm.dsl.mindspring.com ([66.245.94.214] helo=[192.168.0.2]) by mynah.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 4.34) id 1ByBhn-0002gz-Dk for ietf-mxcomp@imc.org; Fri, 20 Aug 2004 08:53:27 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <200408161919.PAA24682@ietf.org> <20040818215247.GE50011@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <113A2FBA-F2C1-11D8-A1ED-000A95BDB38A@corp.earthlink.net> Content-Transfer-Encoding: 7bit From: Tripp Cox Subject: Re: Allowing other scopes on SPF2 records (Was: I-D ACTION:draft-ietf-marid-protocol-01.txt) Date: Fri, 20 Aug 2004 11:53:23 -0400 To: "IETF MARID WG" X-Mailer: Apple Mail (2.619) X-ELNK-Trace: 3507b2fe2d9b3ca5cc16ce54e02836f0b44f110e0743546d2ae8e2002bcac13b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.94.214 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 20, 2004, at 8:48 AM, wayne wrote: > > Personally, I would *really* like to see this changed to use the > following ABNF: > > > version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) > ver-minor = 1*DIGIT > ver-scope = "pra" / name > > Where name is already defined as: > > name = alpha *( alpha / digit / "-" / "_" / "." ) I agree. Implementors may want to use SPF2 records for a number of reasons, which may or may not include PRA policy expression. If one explicitly desires to not publish a PRA policy (e.g. for IPR reasons) and still use SPF2, such usage may break implementations expecting the presently-defined SPF2.0 version records. How would you propose that we handle changes made to the SPF record directives and/or syntax? Let's say, for example, that the macro language is extended. In this case, legacy SPF2.0 parsers could be confused when encountering unexpected macro strings. Would we address that by making an increase in the major version number? Would it still be useful for the publisher to somehow advertise which scopes its record does/does not support, or is the mere presence or absence of them in the record sufficient? In any case, I see no harm in leaving in the minor version number. Perhaps we'll never need it, but it is easier to put it in now than later. Tripp From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 12:22: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 MAA24655 for ; Fri, 20 Aug 2004 12:22: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 i7KFvod9041062; Fri, 20 Aug 2004 08:57: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 i7KFvo81041061; Fri, 20 Aug 2004 08:57:50 -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 i7KFvkHj041032 for ; Fri, 20 Aug 2004 08:57:46 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ByBlw-0001aa-00 for ; Fri, 20 Aug 2004 17:57:44 +0200 Received: from a064124.dialin.hansenet.de ([213.191.64.124]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Aug 2004 17:57:44 +0200 Received: from nobody by a064124.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Aug 2004 17:57:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Allowing other scopes on SPF2 records Date: Fri, 20 Aug 2004 17:56:58 +0200 Organization: Lines: 17 Message-ID: <41261F4A.2AE2@xyzzy.claranet.de> References: <200408161919.PAA24682@ietf.org> <20040818215247.GE50011@verdi> 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: a064124.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 wayne wrote: > This would mean that SPF2 records would not *have* to be used for the > PRA. It would also allow SPF2 records to be used for SPF-classic > usage. For the vast majority of domains that have the same policies > for both the PRA usage and the SPF usage, people could publish: > SPF2 "spf2.0/spf,pra ..." Nice idea. I also like your proposal to rename include: to "if-pass:" (or similar). Maybe now is also the time to drop SOFTFAIL, UNKNOWN should be good enough, and "exists:" allows debugging without the active help of the recipient. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 13:03:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27755 for ; Fri, 20 Aug 2004 13:03:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGedJu046768; Fri, 20 Aug 2004 09:40: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 i7KGedFn046767; Fri, 20 Aug 2004 09:40:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGecif046761 for ; Fri, 20 Aug 2004 09:40:38 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ByCRT-0002sB-00 for ; Fri, 20 Aug 2004 18:40:41 +0200 Received: from 212.82.251.211 ([212.82.251.211]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Aug 2004 18:40:39 +0200 Received: from nobody by 212.82.251.211 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Aug 2004 18:40:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Charter Date: Fri, 20 Aug 2004 18:40:10 +0200 Organization: Lines: 27 Message-ID: <4126296A.54B3@xyzzy.claranet.de> References: <16677.15929.717736.744858@giles.gnomon.org.uk> <004901c4864c$70200680$2766f30a@development.greatgulfhomes.com> <16677.18631.471604.565677@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: 212.82.251.211 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 Roy Badami wrote: > The only way that SPF can solve the backscatter problem is > if _every_ MTA implements SPF checks, so that there's _never_ > an upstream MTA to generate a bounce to a forged MAIL FROM. No, that's not the idea. At the moment spammers still forge my addresses @xyzzy. As soon as some big providers implement SPF (e.g. using SpamAssassin 3.x) the spammers will stop to forge @xyzzy, because they want to reach all of their unhappy "customers". The rest of the world minus say AOL and Hotmail is not good enough for a professioal spammer. > this will just take too long Learning new tricks may take a while for spammers, but not that long. A smart SPF solution could automatically block an IP if it generates a SPF FAIL. > Backscatter is a big problem now Indeed. And PRA does not address it. > The backscatter problem needs to be solved quickly. Classic SPF solves it. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 13:22: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 NAA29339 for ; Fri, 20 Aug 2004 13:22:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KH1aZk049625; Fri, 20 Aug 2004 10:01:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KH1aep049624; Fri, 20 Aug 2004 10:01:36 -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 i7KH1Z11049614 for ; Fri, 20 Aug 2004 10:01:35 -0700 (PDT) (envelope-from roy+dated+1095613289.9d3bea@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7KH3EHD052979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Aug 2004 17:03:20 GMT (envelope-from roy+dated+1095613289.9d3bea@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7KH1TJ0093829 for ; Fri, 20 Aug 2004 18:01:29 +0100 (BST) (envelope-from roy+dated+1095613289.9d3bea@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7KH1Twv093828 for ietf-mxcomp@imc.org; Fri, 20 Aug 2004 18:01:29 +0100 (BST) (envelope-from roy+dated+1095613289.9d3bea@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 20 Aug 2004 18:01:28 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16678.11880.413392.635724@giles.gnomon.org.uk> Date: Fri, 20 Aug 2004 18:01:28 +0100 To: Frank Ellermann Cc: ietf-mxcomp@imc.org Subject: Re: Point of Order: Incomplete, flawed response to MARID WG Charter In-Reply-To: <4126296A.54B3@xyzzy.claranet.de> References: <16677.15929.717736.744858@giles.gnomon.org.uk> <004901c4864c$70200680$2766f30a@development.greatgulfhomes.com> <16677.18631.471604.565677@giles.gnomon.org.uk> <4126296A.54B3@xyzzy.claranet.de> 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 >>>>> "Frank" == Frank Ellermann writes: Frank> As soon as some big providers implement SPF (e.g. using Frank> SpamAssassin 3.x) the spammers will stop to forge @xyzzy, Frank> because they want to reach all of their unhappy Frank> "customers". The smart spammers will. Though whether there will still be enough dumb spammers out to cause lots of backscatter is less clear to me. -roy From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 13:31:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00340 for ; Fri, 20 Aug 2004 13:31: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 i7KH98sd050567; Fri, 20 Aug 2004 10:09:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KH98GF050566; Fri, 20 Aug 2004 10:09:08 -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 i7KH96Kb050548 for ; Fri, 20 Aug 2004 10:09:07 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ByCt3-0003ea-00 for ; Fri, 20 Aug 2004 19:09:09 +0200 Received: from 212.82.251.211 ([212.82.251.211]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Aug 2004 19:09:09 +0200 Received: from nobody by 212.82.251.211 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Aug 2004 19:09:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: change of version string Date: Fri, 20 Aug 2004 19:07:40 +0200 Organization: Lines: 22 Message-ID: <41262FDC.4852@xyzzy.claranet.de> References: <1092945240.21602.13.camel@ddev.mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.211 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 Scott Kitterman wrote: > publish an SPF2 record that says spf2.0/pra +all. That's an > effective opt-out of Sender-ID. ............^^^^^^^ v=spf1 means MAIL FROM only, and nothing else, no united PRA - SUBMITTER - Caller-Id - Domain Key stuff. There's no need to "opt out" from something when you never opted-in before. If you want to "opt-in" to these schemes you're free to try it. Maybe it works for you, I doubt it, and I'm sure that PRA won't work for me. > we can gain a lot of momentum by leveraging off of the SPF > classic community Deliberately misinterpreting sender policies would be abuse. Wayne's idea "spf2/pra,spf" vs. "spf2/spf" is better, only the latter is compatible with v=spf1. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 13:46: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 NAA01424 for ; Fri, 20 Aug 2004 13:46: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 i7KHQkKs052968; Fri, 20 Aug 2004 10: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 i7KHQkAj052967; Fri, 20 Aug 2004 10: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 i7KHQfKB052944 for ; Fri, 20 Aug 2004 10:26: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 16B7316E0B for ; Fri, 20 Aug 2004 13:35:13 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Solution For Trojans In-Reply-To: Your message of "Thu, 19 Aug 2004 14:35:35 PDT." <1092951335.21639.11.camel@ddev.mail-abuse.org> Date: Fri, 20 Aug 2004 13:35:13 -0400 Message-Id: <20040820173513.16B7316E0B@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > I agree with this view. PRA does not represent the accountable entity, > if viewed as the MTA being accountable. I don't think PRA is trying to hold the current sending MTA accountable. > If authenticated, the EHLO domain properly provides the accountable > entity. For what? Validating EHLO ensures that you know someone's accountable, but what for? The MAIL FROM may have a different domain than EHLO, and the message body may have something else entirely. There are multiple accountable entities. Sorting out who they are, what they do, and how they interact is problematic. e.g. EHLO accountability: The sending MTA is part of an administrative system which is well-known, and understands that the MTA is sending messages. MAIL FROM accountability: Someone accepts responsibility for the bounces. "From:" accountability: with something like PGP signatures, an individual is claiming responsibility for the message content The different kinds of accountability are used at different stages of passing the email message, and do different things. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 14:59: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 OAA05996 for ; Fri, 20 Aug 2004 14:59: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 i7KIbZsY064418; Fri, 20 Aug 2004 11:37: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 i7KIbZLx064417; Fri, 20 Aug 2004 11:37:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KIbZvY064411 for ; Fri, 20 Aug 2004 11:37:35 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 7E8FA414B5; Fri, 20 Aug 2004 11:37:39 -0700 (PDT) Subject: RE: change of version string From: Douglas Otis To: Scott Kitterman Cc: MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1093027058.22717.129.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 20 Aug 2004 11:37:38 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-19 at 14:57, Scott Kitterman wrote: > Douglas Otis wrote: > > On Thu, 2004-08-19 at 13:17, Scott Kitterman wrote: > > > > > Anyone who doesn't want their v=spf1 record used for Sender-ID > > > checks can publish an SPF2 record that says spf2.0/pra +all. > > > > Why not wait for them to opt-in to Sender-ID? You want mail > > rejected as a result of this usurping of the record? There may be > > many that feel Sender-ID records of any kind are not safe, as they > > rely upon the RFC2822 content, but there is no means for this > > content to be assured. Blacklisting could make _any_ records for > > Sender-ID perilous. They may have felt SPF was relatively safe, but > > feel Sender-ID is not. You offer no recourse as a result of this > > expediency taken. They may have been expecting to use differing > > access with this RFC2822 From address you destroy without risking > > the publishing of Sender-ID records. > > > > > That's an effective opt-out of Sender-ID. > > > > That is asking for their DNS to be bombarded with Sender-ID spam > > exploits. That is also asking for their domain to be blacklisted. > > Some opt-out. :( > > Actually, now that I think about it, spf2.0/pra ?all would be a much > safer opt out. Shouldn't get blacklisted over that one any more than > you would by publishing nothing. If there is a filtering advantage for referencing a Sender-ID record, even an '?' "open" record, then this type of record becomes a means for spam exploits. This also puts the DNS server at risk of being overloaded. Regardless of the scenario, publishing an "open" record of _any_ type is not without risk. It could also lead to this Sender-ID domain becoming blacklisted, if this record is abused. An "open" record can easily be abused. Such "open" lists should be struck as offering an irresponsible option, once repudiation is considered being done either through rejection or filtering. Filtering is much more insidious. :( > > > While I agree that the records for SPF Classic and Sender-ID may > > > be different in some cases, I expect that will be the exception. > > > For the bulk of cases, I believe that the same record can be > > > accurately parsed for both. I definitely believe that to be the > > > case for mine. > > > > That comparison is overlooking how these records are used. > > Publishing these records was agreeing to how this record was to be > > applied, and not to just their content. > > I agree that v=spf1 publishers would have to look at Sender-ID and > decide if they wanted to avoid it. I do think that it shouldn't be a > major burden for those savy enough to have already adopted SPF > classic. The burden can not be avoided, when a Sender-ID record must be published as a means to exclude the SPF record being assumed valid for Sender-ID. If a message is relayed to the recipient, then it could become promoted, likely by means of a Resent-From header, that will soon become ubiquitous at relays, as a result of Sender-ID. Some may then adopt a evaluation strategy that attempts to deduce the original PRA identity for assessing repudiations, as this method falls completely apart. > > > Having one record where one record will do while still allowing > > > for two records where necessary will make life easier for domain > > > owners trying to support one or both efforts. One could also, in > > > theory, say that in the absence of an v=spf1 record, use the SPF2 > > > record if present. Since there is a significant fielded code base > > > of v=spf1 parsers in use, I think that it would make more sense to > > > have Sender-ID parsers use either record when they are deployed. > > > > This has happened because TXT records are being overloaded. What > > solution is there when the next version of records are to be > > published? > > For the next version of the record, the actual RR type ought to be > available. One major advantage of using one record for both is to > minimize the load on TXT records. This two record types for a set of information is bad. Already there is a high level of DNS traffic for this scheme, and now this requires two record paths be checked. Will the record sets always match? Could be a means to confuse checking schemes that do not check both records? > > > They key point is to make it easier for domain owners to > > > publish. Getting a critical mass of domain owners with records is > > > essential to escape the catch 22 of receivers not checking because > > > no one publishes records and no one publishing records because no > > > one checks. Since there is a significant base of v=spf1 records > > > published, we can gain a lot of momentum by leveraging off of the > > > SPF classic community. Finally, they are generally technically > > > aware early adopters who can reasonably be expected to understand > > > the impacts of 2821 versus 2822 checking and its effect on them. > > > > This still does not provide a suitable option for saying "Leave me out > > of Sender-ID!" > > Of course, being left out of both SPF and Sender-ID is trivial. > Continue to not publish a record. Yes, it does make it harder to get > out of Sender-ID, but not out of SPF. I think that spf2.0/pra ?all > would be close enough. This is not the same as no record. This is saying, "Anyone and everyone, use this record if you wish to claim my domain in your mailbox address as having Sender-ID '?' status." This could be worse than no record, as it implies acceptance of this "open" Sender-ID record status. > > > As far as what you call it, I don't care. I just use what's in > > > the drafts. Myself, I wouldn't make any arguments in favor of > > > Sender-ID over classic SPF, but Sender-ID is what's on the table, > > > so that's what I'm trying to address. > > > > There are potentially serious downsides to Sender-ID and there should > > not be any auto-magic opt-in. Error on the side of caution. > > Why not wait is twofold. First, two help jump-start adoption of the > MARID solution (assuming it's Sender-ID) and the second is to simplify > record publishing for those of us who will continue with Classic SPF. There should not be any need to "jump start" a scheme that proves effective deterring abuse. As Sender-ID does not provide an effective or safe means for abating abuse, this is more likely the reason for adding a grandfather clause that seeks to ignore intent of the record. This linked DNS record scheme seems well aimed destroying both DNS and mail. A dedicated server could offer much shorter responses than crazy lists of DNS records. Part of a philosophy, "Break it, and you bought it?" What is the next proprietary scheme for mail and DNS? > Most of the commentary I've seen on the list seems to favor a single > record for both. There are some that are concerned with that. Here's > a way for both groups to have their way. This is still overloading records. Sender-ID will assume ownership of TXT, regardless of wording in the standard. This is a problem already burdened with potentially hundreds of DNS record lookups. :( -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 15:30: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 PAA08798 for ; Fri, 20 Aug 2004 15:30: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 i7KJ8e4X068858; Fri, 20 Aug 2004 12:08: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 i7KJ8eWY068857; Fri, 20 Aug 2004 12:08:40 -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 i7KJ8dZF068841 for ; Fri, 20 Aug 2004 12:08:39 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 92025 invoked from network); 20 Aug 2004 19:08:41 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 20 Aug 2004 19:08:41 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "Douglas Otis" Cc: "MARID" Subject: RE: change of version string Date: Fri, 20 Aug 2004 15:08:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <1093027058.22717.129.camel@ddev.mail-abuse.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Douglas Otis > Sent: Friday, August 20, 2004 2:38 PM > To: Scott Kitterman > Cc: MARID > Subject: RE: change of version string > On Thu, 2004-08-19 at 14:57, Scott Kitterman wrote: > > Douglas Otis wrote: > > > On Thu, 2004-08-19 at 13:17, Scott Kitterman wrote: > > > > > > > Anyone who doesn't want their v=spf1 record used for Sender-ID > > > > checks can publish an SPF2 record that says spf2.0/pra +all. > > > > > > Why not wait for them to opt-in to Sender-ID? You want mail > > > rejected as a result of this usurping of the record? There may be > > > many that feel Sender-ID records of any kind are not safe, as they > > > rely upon the RFC2822 content, but there is no means for this > > > content to be assured. Blacklisting could make _any_ records for > > > Sender-ID perilous. They may have felt SPF was relatively safe, but > > > feel Sender-ID is not. You offer no recourse as a result of this > > > expediency taken. They may have been expecting to use differing > > > access with this RFC2822 From address you destroy without risking > > > the publishing of Sender-ID records. > > > > > > > That's an effective opt-out of Sender-ID. > > > > > > That is asking for their DNS to be bombarded with Sender-ID spam > > > exploits. That is also asking for their domain to be blacklisted. > > > Some opt-out. :( > > > > Actually, now that I think about it, spf2.0/pra ?all would be a much > > safer opt out. Shouldn't get blacklisted over that one any more than > > you would by publishing nothing. > > If there is a filtering advantage for referencing a Sender-ID record, > even an '?' "open" record, then this type of record becomes a means for > spam exploits. This also puts the DNS server at risk of being > overloaded. Regardless of the scenario, publishing an "open" record of > _any_ type is not without risk. It could also lead to this Sender-ID > domain becoming blacklisted, if this record is abused. An "open" record > can easily be abused. Such "open" lists should be struck as offering an > irresponsible option, once repudiation is considered being done either > through rejection or filtering. Filtering is much more insidious. :( > > > > They key point is to make it easier for domain owners to > > > > publish. Getting a critical mass of domain owners with records is > > > > essential to escape the catch 22 of receivers not checking because > > > > no one publishes records and no one publishing records because no > > > > one checks. Since there is a significant base of v=spf1 records > > > > published, we can gain a lot of momentum by leveraging off of the > > > > SPF classic community. Finally, they are generally technically > > > > aware early adopters who can reasonably be expected to understand > > > > the impacts of 2821 versus 2822 checking and its effect on them. > > > > > > This still does not provide a suitable option for saying "Leave me out > > > of Sender-ID!" > > > > Of course, being left out of both SPF and Sender-ID is trivial. > > Continue to not publish a record. Yes, it does make it harder to get > > out of Sender-ID, but not out of SPF. I think that spf2.0/pra ?all > > would be close enough. > > This is not the same as no record. This is saying, "Anyone and > everyone, use this record if you wish to claim my domain in your mailbox > address as having Sender-ID '?' status." This could be worse than no > record, as it implies acceptance of this "open" Sender-ID record status. > Upon reflection, I think that Wayne's proposal is better. It meets my goal of only having to publish one record without the downsides that you point out here. Being able to only publish one record (what I proposed) would be great. Being able to publish one record the describes what scope it is intended for is better. It will take a little longer since the currently deployed SPF parsers will have to be upgraded to read the new record type, but I suspect the advantages are worth it. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 15:43: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 PAA09363 for ; Fri, 20 Aug 2004 15: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 i7KJNXk2071300; Fri, 20 Aug 2004 12: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 i7KJNXC3071299; Fri, 20 Aug 2004 12:23:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KJNXc3071293 for ; Fri, 20 Aug 2004 12:23:33 -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 501CF414BA; Fri, 20 Aug 2004 12:23:37 -0700 (PDT) Subject: Re: Solution For Trojans From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040820173513.16B7316E0B@mail.nitros9.org> References: <20040820173513.16B7316E0B@mail.nitros9.org> Content-Type: text/plain Message-Id: <1093029816.22717.176.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 20 Aug 2004 12:23:36 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-20 at 10:35, Alan DeKok wrote: > Douglas Otis wrote: > > > I agree with this view. PRA does not represent the accountable entity, > > if viewed as the MTA being accountable. > > I don't think PRA is trying to hold the current sending MTA > accountable. I agree. The PRA does not authenticate the MTA as a means to identify those administering polices to control mail. > > If authenticated, the EHLO domain properly provides the accountable > > entity. > > For what? Validating EHLO ensures that you know someone's > accountable, but what for? The MTA administrator should be seen as accountable for the stream of mail, irrespective of message content. If there is a problem, only this entity is capable of taking steps to curtail abuse. > The MAIL FROM may have a different domain than EHLO, and the message > body may have something else entirely. > > There are multiple accountable entities. Sorting out who they are, > what they do, and how they interact is problematic. e.g. > > EHLO accountability: > The sending MTA is part of an administrative > system which is well-known, and understands > that the MTA is sending messages. The EHLO domain entity is granting access to the mail channel and they have logs to sort out who did what. If networks are to be protected from those wishing to abuse the system, only this entity is capable of taking effective action to abate this traffic. The authenticated EHLO domain should be visible to the user at the MUA. After all, this is where trust is being placed. > MAIL FROM accountability: > Someone accepts responsibility for the bounces. I see this as closing the "back-door". There will always be some MTA at the end of a relay chain. Being able to detect return addresses as bogus, perhaps by way of the BATV proposal, would avoid this type of spoof bounce abuse, often used by Trojans and spammers. This would be a secondary level protection after checking against the EHLO domain for a history of abuse. This allows two opportunities to stop this illicit technique. > "From:" accountability: > With something like PGP signatures, an individual is claiming > responsibility for the message content. Absolutely. I agree digital signatures would be a proper means to protect the author. Making the authenticated EHLO domain visible together with the From, would be a significant improvement over the current situation. Digital signatures would be the next logical step. Sender-ID does not provide author protection, as it makes a false assumption RFC2822 content is secure and allows header overrides. Nor does Sender-ID identify the MTA administration. Nor does Sender-ID protect the return-path. :( > The different kinds of accountability are used at different stages > of passing the email message, and do different things. Agreed. But the intent of the MARID charter was to find a means to authenticate the MTA using DNS records. Only checking the EHLO does this. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 15:59: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 PAA10138 for ; Fri, 20 Aug 2004 15:59: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 i7KJc9xc073949; Fri, 20 Aug 2004 12:38:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KJc9AZ073948; Fri, 20 Aug 2004 12:38:09 -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 i7KJc9q2073942 for ; Fri, 20 Aug 2004 12:38:09 -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 DD79B4149B for ; Fri, 20 Aug 2004 12:38:13 -0700 (PDT) Subject: Re: Allowing other scopes on SPF2 records (Was: I-D ACTION:draft-ietf-marid-protocol-01.txt) From: Douglas Otis To: IETF MARID WG In-Reply-To: References: <200408161919.PAA24682@ietf.org> <20040818215247.GE50011@verdi> Content-Type: text/plain Message-Id: <1093030692.22717.190.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 20 Aug 2004 12:38:12 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-20 at 05:48, wayne wrote: > In Tripp Cox writes: > > > On Aug 20, 2004, at 12:11 AM, wayne wrote: > >> > >> The creation of a minor version number was mandated during the IETF-60 > >> session. No semantics of what the minor version number should do were > >> given. I've talked with both Mark and Meng about this, and we all > >> agree that we can't think of any use for a minor version, which was > >> why it wasn't there in the first place. > > > > As SPF 2.0 is a policy that speaks only to how to deal with the PRA, I > > could see a minor version being useful if additional policy classes > > are added. > > There is no need to use the minor version for the ability to extend > the SPF2 records to different scopes. > > The current marid-protocol I-D gives the following ABNF for the > version token: > > version = "spf2." ver-minor "/pra" [ ver-ext ] > ver-minor = 1*DIGIT > ver-ext = "," *VCHAR > > So, things like "spf2.0/pra,mailfrom" and "spf2.0/pra,helo" are > perfectly valid. There is a way to define the mail channel with a single DNS lookup, but this TXT script seems like a dog with a bone. If there is to be extensions considered, then excluding PRA should be one such consideration, if nothing else then to be excluded from repudiations based upon RFC2822 content. This also helps prevent the need for "open" lists to allow the use of a return mailbox. I can see many reasons for not including PRA. So should "spf2.0/mailfrom" as example. version = "spf2." ver-minor [scope] ver-minor = 1*DIGIT scope = "/" *VCHAR "," -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 17: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 RAA14605 for ; Fri, 20 Aug 2004 17: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 i7KKsx7n085331; Fri, 20 Aug 2004 13:54: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 i7KKsxU1085330; Fri, 20 Aug 2004 13:54:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from icicle.pobox.com (icicle.pobox.com [207.8.226.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KKswOO085324 for ; Fri, 20 Aug 2004 13:54:58 -0700 (PDT) (envelope-from SRS0=CwgU=LK=dumbo.pobox.com=mengwong@bounce2.pobox.com) Received: from emerald.pobox.com (emerald.pobox.com [207.8.226.12]) by icicle.pobox.com (Postfix) with ESMTP id 1651D11B179; Fri, 20 Aug 2004 16:55:01 -0400 (EDT) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id E2456132CF8; Fri, 20 Aug 2004 16:54:54 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 89C3C4DF; Fri, 20 Aug 2004 16:54:59 -0400 (EDT) Date: Fri, 20 Aug 2004 16:54:59 -0400 From: Meng Weng Wong To: Roy Badami Cc: Chris Haynes , IETF MARID WG Subject: blowback and SPF classic Message-ID: <20040820205459.GN28401@dumbo.pobox.com> References: <058901c485c1$9299c5b0$0200000a@ringo> <16676.44440.161225.346881@giles.gnomon.org.uk> <072b01c48605$87d1ab40$0200000a@ringo> <16676.60586.22401.296538@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16676.60586.22401.296538@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 19, 2004 at 07:08:42PM +0100, Roy Badami wrote: | | Really? draft-mengwong-spf-01 permits rejection of a message with a | 550 reply code if the SPF check fails, and that's what most | implementations seem to do. | | If you reject an SMTP transaction due to an SPF failure, then the | up-stream MTA is likely to generate a bounce to a forged address. 1) If the sender is an MTA sending on behalf of a legitimate sender, then the rejection is, in spirit, a false positive. The rejection is a good thing because it informs the legitimate sender that their message didn't get through. 2) If the SMTP sender is a virus, then the rejection does not cause a nondelivery notification, and there is no problem. 3) If the sender is an MTA sending on behalf of a virus, the nondelivery notification is generated by that MTA, and it's the fault of that MTA for being gullible. If the message had been rejected for some reason other than SPF, for example due to over-quota at final delivery, the forged sender gets backscatter anyway. | As far as I can see, all MARID schemes are likely to increase | backscatter. In fact, anything that cause more mail to be SMTP | rejected will increase backscatter. Scenarios 1 and 2 are desirable. Scenario 3 is no worse than the current situation. Scenario 4 is avoided: the SMTP sender is a virus, the receiving MTA accepts the message, and sends a message to a bogus return path. The benefit from stopping 4, plus the benefits of 1 and 2, are worth the costs of 3, which is net no worse than the "priors" anyway. Therefore a scheme which checks mail-from is not proven to increase backscatter, and it is not true that anything that causes more mail to be SMTP rejected will increase backscatter. From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 19: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 TAA23030 for ; Fri, 20 Aug 2004 19: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 i7KNK5PL006717; Fri, 20 Aug 2004 16:20:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KNK5o4006716; Fri, 20 Aug 2004 16:20:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KNK5UW006710 for ; Fri, 20 Aug 2004 16:20:05 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 20F4F414BA for ; Fri, 20 Aug 2004 16:20:11 -0700 (PDT) Subject: Back-Door Bounce strategy prevention From: Douglas Otis To: IETF MARID WG In-Reply-To: <20040820205459.GN28401@dumbo.pobox.com> References: <058901c485c1$9299c5b0$0200000a@ringo> <16676.44440.161225.346881@giles.gnomon.org.uk> <072b01c48605$87d1ab40$0200000a@ringo> <16676.60586.22401.296538@giles.gnomon.org.uk> <20040820205459.GN28401@dumbo.pobox.com> Content-Type: text/plain Message-Id: <1093044009.22717.261.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 20 Aug 2004 16:20: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 When the Front-Door is locked, they'll use the Back-Door left open. RFC2821 MAIL FROM protections in general terms: 1) MAIL FROM checked before accepted: a- caused by a virus - Good Reject b- illicit spam technique - Good Reject c- channel config error - Good Reject d- other rejections - Good Reject 2) MAIL FROM checked after accepted, but before bounce: a- caused by a virus, checked against prescribed channel - Bad Send b- caused by a virus, checked with local-part signature - Good Drop c- illicit spam, checked against prescribed channel - Bad Send d- illicit spam, checked against local-part signature - Good Drop e- channel config error, checked against prescribed channel - Good Send f- other rejections - Good Send 3) RCPT TO Bounce: a- caused by virus, checked against prescribed channel - Bad Accept b- caused by virus, checked against local-part signature - Good Reject c- illicit spam, checked against prescribed channel - Bad Accept d- illicit spam, checked against local-part signature - Good Reject e- channel config error, checked against prescribed channel - Unknown f- other rejections, checked against prescribed channel - Unknown g- other rejections, checked against local-part signature - Good Accept 1) MAIL FROM checks prior to acceptance is always good and will lower the amount of bounce traffic that may occur for other reasons at subsequent processes such as virus filtering or unknown recipient at subsequent MTAs. Its all good. 2) MAIL FROM checks after acceptance depends heavily upon the type of checking. If the check is based upon a prescribed mail channel, then due to a likelihood of this prescription being wrong, the bounce should be sent. Proper practices should be able to avoid this problem, unless the overhead is considered too great for the check to be done for each message. If the check is based upon a local-part signature, then when this check is made is less critical. 3) The RCPT TO / MAIL FROM bounce depends fully upon the check made. It also illustrates far end cooperation is not needed for the case where the local-part signature is checked. Combined with a nounce, this check can limit the number of replays somewhat, in addition to expiry timeout. A channel check could help reduce a potential local-part signature replay problem. This breakdown assumes illicit use will ensure the defeat of a channel check. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 23:32: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 XAA03945 for ; Fri, 20 Aug 2004 23:32: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 i7L365oj035965; Fri, 20 Aug 2004 20:06: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 i7L365Tx035964; Fri, 20 Aug 2004 20:06:05 -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 i7L362Hg035943 for ; Fri, 20 Aug 2004 20:06:02 -0700 (PDT) (envelope-from roy+dated+1095649556.75503b@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7L37nsj017144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 21 Aug 2004 03:07:56 GMT (envelope-from roy+dated+1095649556.75503b@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7L35ubj016729 for ; Sat, 21 Aug 2004 04:05:56 +0100 (BST) (envelope-from roy+dated+1095649556.75503b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7L35uFR016728 for ietf-mxcomp@imc.org; Sat, 21 Aug 2004 04:05:56 +0100 (BST) (envelope-from roy+dated+1095649556.75503b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 21 Aug 2004 04:05:56 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16678.48147.577043.441761@giles.gnomon.org.uk> Date: Sat, 21 Aug 2004 04:05:55 +0100 To: Frank Ellermann Cc: ietf-mxcomp@imc.org Subject: Re: change of version string In-Reply-To: <41262FDC.4852@xyzzy.claranet.de> References: <1092945240.21602.13.camel@ddev.mail-abuse.org> <41262FDC.4852@xyzzy.claranet.de> 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 >>>>> "Frank" == Frank Ellermann writes: Frank> ............^^^^^^^ v=spf1 means MAIL FROM only, and Frank> nothing else, Actually, v=spf1 means a mandatory check on MAIL FROM, a mandatory check on HELO when MAIL FROM doesn't contain a domain (which generally boils down to just the MAIL FROM:<> case for all but the most liberal recipients) and an optional check on HELO in other circumstances. I would be quite keen on future work to allow MAIL FROM checks within Sender ID (though now is the time to ensure that the versioning system allows that in a clean way, not the time to spec that work). I'm less convinced that merging HELO checks into Sender ID is the right way to go. But now is not the time to discuss that, either (and as CSV is a WG work item which adresses the HELO identity, we can have that discussion once Sender ID is out the door). -roy From owner-ietf-mxcomp@mail.imc.org Fri Aug 20 23:37: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 XAA04122 for ; Fri, 20 Aug 2004 23:37: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 i7L3LqxA038048; Fri, 20 Aug 2004 20:21:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L3Lqwn038047; Fri, 20 Aug 2004 20:21: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 i7L3LoAL038024 for ; Fri, 20 Aug 2004 20:21:50 -0700 (PDT) (envelope-from roy+dated+1095650510.8012dc@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7L3Ngw0023578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 21 Aug 2004 03:23:48 GMT (envelope-from roy+dated+1095650510.8012dc@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7L3LoLB016950 for ; Sat, 21 Aug 2004 04:21:50 +0100 (BST) (envelope-from roy+dated+1095650510.8012dc@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7L3LomE016949 for ietf-mxcomp@imc.org; Sat, 21 Aug 2004 04:21:50 +0100 (BST) (envelope-from roy+dated+1095650510.8012dc@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 21 Aug 2004 04:21:50 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16678.49102.103191.523997@giles.gnomon.org.uk> Date: Sat, 21 Aug 2004 04:21:50 +0100 To: "IETF MARID WG" Subject: Allowing other scopes on SPF2 records (Was: I-D ACTION:draft-ietf-marid-protocol-01.txt) In-Reply-To: References: <200408161919.PAA24682@ietf.org> <20040818215247.GE50011@verdi> 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: Personally, I would *really* like to see this changed to use the following ABNF: version = "spf2." ver-minor "/" ver-scope *( "," ver-scope ) ver-minor = 1*DIGIT ver-scope = "pra" / name Where name is already defined as: name = alpha *( alpha / digit / "-" / "_" / "." ) I like this proposal; I think it is more flexible than what we currently have in the drafts. I think I'd prefer ver-token to ver-scope -- at this point there's no need to suggest a particular use for the extention mechanism, even by implication, and there may be other uses we haven't yet though of that will make us regret the ver-scope name. The idea would be that only records with 'pra' present as a ver-token would be considered by the Sender ID draft. Yes, a future standard can always stop Sender ID from interpreting the record by changing the version string incompatibly (eg by bumping the major version) but this approach gives more flexibility in terms of the way that the Sender ID can be extended... -roy From owner-ietf-mxcomp@mail.imc.org Sat Aug 21 11:03:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17070 for ; Sat, 21 Aug 2004 11:03:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LEhG6l046345; Sat, 21 Aug 2004 07: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 i7LEhGBI046343; Sat, 21 Aug 2004 07:43:16 -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 i7LEhFa1046332 for ; Sat, 21 Aug 2004 07:43:15 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040821144306.QAPI7925.tomts25-srv.bellnexxia.net@ibmrkydk2ufvdd>; Sat, 21 Aug 2004 10:43:06 -0400 From: "John Glube" To: "'Daryl Odnert'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter Date: Sat, 21 Aug 2004 10:43:06 -0400 Message-ID: <004601c4878d$2bb1af20$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7LEhFa1046333 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Daryl, I appreciate your suggestion that: >I think a proposal that would enable both reverse-path and >PRA authentication is definitely a worthwhile endeavor. I also appreciate your comment that: >But I wouldn't necessarily throw away the existing Sender >ID proposal on the basis that it doesn't solve a problem >that the authors chose not to solve in the first place. >(Read http://www.ietf.org/internet-drafts/draft-ietf-marid->rationale-0 0.txt for more insight into that choice.) The approach of using a best current practice document to 'bridge' the gap is probably the most workable solution. My concern is that the good faith proposal put forward by Harry in suggesting a BCP that only deals with checking for malformed SMTP mail from addresses at the data stage does not go far enough. I appreciate from a design perspective there is a strong view the semantic differences between "the 2821 MAIL FROM address and the 2822 headers" should not be bridged through Sender ID or any related BCP. See the RE: Forged Sender (Resent-From) attacks thread. I certainly applaud the proposed effort as outlined in the Sender ID Framework Overview' as found on the Aug 20th version of: http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx My concern is that this overview does not accommodate the proposal of doing a malformed SMTP mail from check and an SMTP mail from check in the absence of PRA at the data stage. In fairness, I am having difficulty understanding the rational for not crafting a BCP which accommodates the suggestion of doing an SMTP mail from address check in the absence of PRA. Without this accommodation, we run the significant risk of an environment of two solitudes developing between those system administrators who support Sender-ID and the SPF community of system administrators. (I trust in only referencing system administrators I have not offended others who are involved in this overall effort. I am simply suggesting those who have to implement and administer what ever is proposed is the core audience.) I suggest that MS and those who support Sender-ID need to reflect strongly on whether this is an ideal outcome. If it is not, then I would urge MS and those who support Sender-ID to come forward with a best current practice document which accommodates the concerns I and others have raised. On the other hand, if it is felt system administrators and others, being the folks who will put into practice what is proposed by MARID will simply follow suit once Sender-ID is approved as an IAB protocol, then perhaps there is no need to change course. Personally, I think this is a mistaken presumption, but then only time will tell. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Sat Aug 21 20:13: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 UAA12267 for ; Sat, 21 Aug 2004 20:13: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 i7LNoFgP038460; Sat, 21 Aug 2004 16:50: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 i7LNoFuw038459; Sat, 21 Aug 2004 16:50:15 -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 i7LNoE3k038443 for ; Sat, 21 Aug 2004 16:50:15 -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 i7LNo9cv010690 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 21 Aug 2004 19:50:15 -0400 Date: Sat, 21 Aug 2004 19:50:09 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: ietf-mxcomp@imc.org Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter (fwd) 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: Someone was saying on-list that the objective of SPF isn't to reduce spam. I was just discussing that subject off-list. If MTA authorization doesn't reduce spam, there is little purpose to the MARID WG, as the MARID charter indicates. --Dean ---------- Forwarded message ---------- Date: Wed, 18 Aug 2004 10:48:55 -0400 (EDT) From: Dean Anderson To: Alan DeKok Subject: Re: How is SPF different from RMX? On Tue, 17 Aug 2004, Alan DeKok wrote: > > Yep. But so far you haven't met any goal of reducing spam. > > Since that was never the goal in the first place, I can't for the > life of me figure out why you keep repeating that. You're not stupid, > so you must have understood that was never the goal: I said so, and > the RMX, etc. documents said so. I guess the only answer is that you > are saying this for non-reality-based reasons. FYI: from the MARID charter http://www.ietf.org/html.charters/marid-charter.html "This will help combat a certain class of domain forgery common in spam. The solution chosen, however, should be generally useful for others which might check this authorization data. This working group is being chartered after extensive discussion of the issues in the IRTF's Anti-spam Research Group, and it is presumed that all active participants will be familiar with the documents produced there which describe the problem. It is not, however, an extension of that research group; it has no general writ to study spam or to produce specifications on the topic. It will not consider anti-spam abatement measures outside of the area of MTA authorization." Reducing spam is a goal of the MARID group. Failure to achieve that goal is a failure of MARID. As my examples show, Email forgery is still possible. --Dean From owner-ietf-mxcomp@mail.imc.org Sat Aug 21 20: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 UAA13584 for ; Sat, 21 Aug 2004 20:56:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7M0aE8L046442; Sat, 21 Aug 2004 17:36: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 i7M0aECs046441; Sat, 21 Aug 2004 17:36:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from icicle.pobox.com (icicle.pobox.com [207.8.226.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7M0aDdm046431 for ; Sat, 21 Aug 2004 17:36:14 -0700 (PDT) (envelope-from SRS0=DpHK=LM=dumbo.pobox.com=mengwong@bounce2.pobox.com) Received: from emerald.pobox.com (emerald.pobox.com [207.8.226.12]) by icicle.pobox.com (Postfix) with ESMTP id B9D3F11B0A4 for ; Sat, 21 Aug 2004 20:36:17 -0400 (EDT) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 70FF5132CD1 for ; Sat, 21 Aug 2004 20:36:06 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id A939E4EA; Sat, 21 Aug 2004 20:36:16 -0400 (EDT) Date: Sat, 21 Aug 2004 20:36:16 -0400 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: SPF is not an antispam technology Message-ID: <20040822003616.GO28401@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 Sat, Aug 21, 2004 at 07:50:09PM -0400, Dean Anderson wrote: | | Someone was saying on-list that the objective of SPF isn't to reduce spam. SPF/MARID/SenderID are not antispam technologies in the same way that flour is not food. From owner-ietf-mxcomp@mail.imc.org Sun Aug 22 15:46: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 PAA14921 for ; Sun, 22 Aug 2004 15:46: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 i7MJDQrm014783; Sun, 22 Aug 2004 12:13:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7MJDQpA014782; Sun, 22 Aug 2004 12:13:26 -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 i7MJDPSt014771 for ; Sun, 22 Aug 2004 12:13:26 -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 i7MJDDuj007581 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 22 Aug 2004 15:13:16 -0400 Date: Sun, 22 Aug 2004 15:13:13 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Meng Weng Wong cc: ietf-mxcomp@imc.org Subject: Re: SPF is not an antispam technology In-Reply-To: <20040822003616.GO28401@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, 21 Aug 2004, Meng Weng Wong wrote: > > On Sat, Aug 21, 2004 at 07:50:09PM -0400, Dean Anderson wrote: > | > | Someone was saying on-list that the objective of SPF isn't to reduce spam. > > SPF/MARID/SenderID are not antispam technologies in the same > way that flour is not food. Flour is food, so I'm not sure what you mean by that. Perhaps you mean that flour must be processed/baked somehow before it is food. But if the flour is inedible, because it was handled improperly and spoiled, then it can't be processed into food, and your "food program" has failed. I guess the metaphor works: We would still be upset with the people for mishandling the flour, because the purpose of having flour is to produce food, and if food can't be produced, we'll still starve. Likewise, if spam isn't stopped by SPF/SenderID/MARID, then those projects will have failed. --Dean From owner-ietf-mxcomp@mail.imc.org Sun Aug 22 16:05: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 QAA15819 for ; Sun, 22 Aug 2004 16:05:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MJcMCr018147; Sun, 22 Aug 2004 12:38: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 i7MJcMNt018145; Sun, 22 Aug 2004 12:38: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 i7MJcLHs018137 for ; Sun, 22 Aug 2004 12:38: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 i7MJjg6C025742; Sun, 22 Aug 2004 12:45:42 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7MJjg4r025739; Sun, 22 Aug 2004 12:45:42 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 22 Aug 2004 12:45:42 -0700 (PDT) From: "william(at)elan.net" To: Dean Anderson cc: Meng Weng Wong , Subject: Re: SPF is not an antispam technology In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 22 Aug 2004, Dean Anderson wrote: > Likewise, if spam isn't stopped by SPF/SenderID/MARID, then those projects > will have failed. No, the projecs will fail if they are unable in serious way to stop forgery and phishing. If they help with stopping spam, that will be an extra bonus. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sun Aug 22 17:02: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 RAA18800 for ; Sun, 22 Aug 2004 17:02: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 i7MKWFfX025256; Sun, 22 Aug 2004 13:32:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7MKWFwE025253; Sun, 22 Aug 2004 13:32:15 -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 i7MKWEMu025242 for ; Sun, 22 Aug 2004 13:32:14 -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 i7MKW9CB009027 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 22 Aug 2004 16:32:12 -0400 Date: Sun, 22 Aug 2004 16:32:09 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "william(at)elan.net" cc: Meng Weng Wong , Subject: Re: SPF is not an antispam technology In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 22 Aug 2004, william(at)elan.net wrote: > > On Sun, 22 Aug 2004, Dean Anderson wrote: > > > Likewise, if spam isn't stopped by SPF/SenderID/MARID, then those projects > > will have failed. > > No, the projecs will fail if they are unable in serious way to stop forgery > and phishing. If they help with stopping spam, that will be an extra bonus. I've shown the examples that it does fail at stopping forgery, in its present form. However, you can't extricate anti-spam from the MARID charter. Phishing can't be stopped. That is a con game as old as, well, prostitution. One doesn't need to forge email to phish. Phisher's do forge, but they don't need to. People dumb enough to trust email addresses despite warnings to the contrary will trust similar-looking email addresses or completely wrong email addresses because they're /dumb/. Similar-looking but not-exact-duplicate letterhead and such have been used in cons since before there was electricity. --Dean From owner-ietf-mxcomp@mail.imc.org Sun Aug 22 17:33: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 RAA19643 for ; Sun, 22 Aug 2004 17:33: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 i7MLAhjD029721; Sun, 22 Aug 2004 14:10: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 i7MLAhQ0029720; Sun, 22 Aug 2004 14:10:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MLAhXr029714 for ; Sun, 22 Aug 2004 14:10:43 -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 11D7D414B5; Sun, 22 Aug 2004 14:10:48 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sun, 22 Aug 2004 14:10:48 -0700 (PDT) Message-ID: <3254.64.142.13.68.1093209048.squirrel@harry.mail-abuse.org> In-Reply-To: <20040822003616.GO28401@dumbo.pobox.com> References: <20040822003616.GO28401@dumbo.pobox.com> Date: Sun, 22 Aug 2004 14:10:48 -0700 (PDT) Subject: Re: SPF is not an antispam technology From: "Douglas Otis" To: "Meng Weng Wong" Cc: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > On Sat, Aug 21, 2004 at 07:50:09PM -0400, Dean Anderson wrote: > | > | Someone was saying on-list that the objective of SPF isn't to reduce > | spam. > > SPF/MARID/SenderID are not antispam technologies in the same > way that flour is not food. Sender-ID does not provide a means to authenticate the MTA and identify the entity able to respond to a problem. This makes Sender-ID as a mechanism for abating spam questionable. When pressed on this issue, several have responded privately, "Sender-ID is not about Spam!" So it would seem Sender-ID is not about enforcing polices that attempt to abate spam. Another issue with Sender-ID is that its identities are based upon RFC2822 content. No negative assertion can be safely made based upon this information, as the channel integrity or whether the channel is being shared remains unknown. An "open" Sender-ID record never allows a safe positive assertion the message originated within the prescribed channel. Again, this makes Sender-ID as a mechanism for abating spam questionable. Sender-ID ignores the problem of a spoofed return-path address, which is a common technique used by spammers to evade blacklisting and even things like Sender-ID. Again, this makes Sender-ID questionable with respect to abating spam. Sender-ID demands perhaps hundreds of sequential DNS lookups to process a message, but the integrity of Sender-ID depends upon this checking being done within the channel. A simple DDoS will likely result in these high-overhead checks being removed. Customers will then be advised to ignore any Sender-ID validations, making Sender-ID as a mechanism for abating spam questionable. Sender-ID often claims that it protects the RFC2822 From header. This protection is lost when there are other headers such as Resent-From within the message and this is not normally visible to the user. This makes Sender-ID questionable with respect to abating spoofing. The likely outcome, if Sender-ID record use is coerced, would be for all mail to then include a Resent-From header, again making the From header open season. This makes Sender-ID questionable with respect to abating spam or spoofing. Sender-ID checks RFC2822 identities and as a result can not lower the network overhead even when spam is rejected, as it has already been received. This also makes Sender-ID seem even less about spam or mitigating the damages done by spam. When asked how Sender-ID was to be used, Microsoft responded at the Open Group Forum by explaining there would be folders in their new version of Outlook to separate mail into various levels of assurance obtained by Sender-ID. Sender-ID is not about stopping spam, accurately sorting spam, or even allowing a complaint about spam. Sender-ID is about finding your mail split into dozens of folders and not being able to use your well-known From address. Good luck searching for all the new aliases in all the new folders. In the past, Microsoft has not been good at abating spam. To properly handle a complaint, the entire message is needed with all the headers. This is not something Microsoft does properly. This makes complaints registered by forwarding mail from a Microsoft client worthless for obtaining enough details to abate the spam problem. Microsoft has a history of not doing the right things to prevent script macros running on machines that receive mail. Surprise, Sender-ID continues this practice. This dangerous practice is likely responsible for much of the spam seen today by way of Trojans often spread by mail. Will these complex DNS record sets open up new avenues for cache poisoning or DNS spoofing? As an comparison to Sender-ID please see: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt This draft is aimed at abating spam. MPR use does not run scripts. MPR use does not require hundreds of sequential DNS lookups. There are no sequential lookups! If you wish to protect the From header, it protects the From header. MPR identifies the entities able to take action to stop the problem. MPR does not interfere with the IPR claimed by Microsoft. MPR handles the bounce mail problem. Microsoft could help abate spam by making the authenticated EHLO domain visible to the user as a means to help solve a spoofing and phishing problem. Sender-ID would not be as beneficial, as it is more easily spoofed. Forward mail with the entire set of headers to allow complaints to be processed, and of course, disable all scripts from running on mail client and now MTA, if they are running Sender-ID. And of course, an SMTP Temp error does not mean try again immediately. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Sun Aug 22 17:34:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19692 for ; Sun, 22 Aug 2004 17:34: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 i7ML8Rk1029418; Sun, 22 Aug 2004 14:08: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 i7ML8RE8029417; Sun, 22 Aug 2004 14:08: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 i7ML8RJE029408 for ; Sun, 22 Aug 2004 14:08:27 -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 48315414B5; Sun, 22 Aug 2004 14:08:28 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sun, 22 Aug 2004 14:08:28 -0700 (PDT) Message-ID: <3247.64.142.13.68.1093208908.squirrel@harry.mail-abuse.org> In-Reply-To: <20040822003616.GO28401@dumbo.pobox.com> References: <20040822003616.GO28401@dumbo.pobox.com> Date: Sun, 22 Aug 2004 14:08:28 -0700 (PDT) Subject: Re: SPF is not an antispam technology From: "Douglas Otis" To: "Meng Weng Wong" Cc: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > On Sat, Aug 21, 2004 at 07:50:09PM -0400, Dean Anderson wrote: > | > | Someone was saying on-list that the objective of SPF isn't to reduce > | spam. > > SPF/MARID/SenderID are not antispam technologies in the same > way that flour is not food. Sender-ID does not provide a means to authenticate the MTA and identify the entity able to respond to a problem. This makes Sender-ID as a mechanism for abating spam questionable. When pressed on this issue, several have responded privately, "Sender-ID is not about Spam!" So it would seem Sender-ID is not about enforcing polices that attempt to abate spam. Another issue with Sender-ID is that its identities are based upon RFC2822 content. No negative assertion can be safely made based upon this information, as the channel integrity or whether the channel is being shared remains unknown. An "open" Sender-ID record never allows a safe positive assertion the message originated within the prescribed channel. Again, this makes Sender-ID as a mechanism for abating spam questionable. Sender-ID ignores the problem of a spoofed return-path address, which is a common technique used by spammers to evade blacklisting and even things like Sender-ID. Again, this makes Sender-ID questionable with respect to abating spam. Sender-ID demands perhaps hundreds of sequential DNS lookups to process a message, but the integrity of Sender-ID depends upon this checking being done within the channel. A simple DDoS will likely result in these high-overhead checks being removed. Customers will then be advised to ignore any Sender-ID validations, making Sender-ID as a mechanism for abating spam questionable. Sender-ID often claims that it protects the RFC2822 From header. This protection is lost when there are other headers such as Resent-From within the message and this is not normally visible to the user. This makes Sender-ID questionable with respect to abating spoofing. The likely outcome, if Sender-ID record use is coerced, would be for all mail to then include a Resent-From header, again making the From header open season. This makes Sender-ID questionable with respect to abating spam or spoofing. Sender-ID checks RFC2822 identities and as a result can not lower the network overhead even when spam is rejected, as it has already been received. This also makes Sender-ID seem even less about spam or mitigating the damages done by spam. When asked how Sender-ID was to be used, Microsoft responded at the Open Group Forum by explaining there would be folders in their new version of Outlook to separate mail into various levels of assurance obtained by Sender-ID. Sender-ID is not about stopping spam, accurately sorting spam, or even allowing a complaint about spam. Sender-ID is about finding your mail split into dozens of folders and not being able to use your well-known From address. Good luck searching for all the new aliases in all the new folders. In the past, Microsoft has not been good at abating spam. To properly handle a complaint, the entire message is needed with all the headers. This is not something Microsoft does properly. This makes complaints registered by forwarding mail from a Microsoft client worthless for obtaining enough details to abate the spam problem. Microsoft has a history of not doing the right things to prevent script macros running on machines that receive mail. Surprise, Sender-ID continues this practice. This dangerous practice is likely responsible for much of the spam seen today by way of Trojans often spread by mail. Will these complex DNS record sets open up new avenues for cache poisoning or DNS spoofing? As an comparison to Sender-ID please see: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt This draft is aimed at abating spam. MPR use does not run scripts. MPR use does not require hundreds of sequential DNS lookups. There are no sequential lookups! If you wish to protect the From header, it protects the From header. MPR identifies the entities able to take action to stop the problem. MPR does not interfere with the IPR claimed by Microsoft. MPR handles the bounce mail problem. Microsoft could help abate spam by making the authenticated EHLO domain visible to the user as a means to help solve a spoofing and phishing problem. Sender-ID would not be as beneficial, as it is more easily spoofed. Forward mail with the entire set of headers to allow complaints to be processed, and of course, disable all scripts from running on mail client and now MTA, if they are running Sender-ID. And of course, an SMTP Temp error does not mean try again immediately. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 01:28: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 BAA27415 for ; Mon, 23 Aug 2004 01:28: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 i7N52HlQ002438; Sun, 22 Aug 2004 22:02: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 i7N52H0Z002437; Sun, 22 Aug 2004 22:02:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7N52HMC002404 for ; Sun, 22 Aug 2004 22:02:17 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 22 Aug 2004 22:07:18 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7N52GiQ017948; Sun, 22 Aug 2004 22:02:17 -0700 (PDT) Received: from fenton-w2k01.cisco.com (stealth-10-32-245-102.cisco.com [10.32.245.102]) by imail.cisco.com (8.12.5/8.12.10) with SMTP id i7N53jkZ012650; Sun, 22 Aug 2004 22:03:45 -0700 Message-Id: <4.3.2.7.2.20040822214401.036ea008@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 22 Aug 2004 22:02:13 -0700 To: "Harry Katz" , "Nate Leon" , From: Jim Fenton Subject: RE: Forged Sender (Resent-From) attacks In-Reply-To: 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:"1093237426.623948"; x:"432000"; a:"rsa-sha1"; b:"0:3353"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"uJEEB0DMfBX2wUzPZ3GqwpGPpGzbiYu13XxgEvlaIq1sPSLIzauwREHpVEdvC" "dyvirjOA6VIe7oP0QCYgU7Vq8KI0VgI/GzwHaoUEAxw7TPIiUIvh3yYv6b2hh" "CqjhRwLEPIxWfU+wlJ5zGJqN3M/OcxSkm9Is/2Fr2wMz2L1fk="; c:"Date: Sun, 22 Aug 2004 22:02:13 -0700"; c:"From: Jim Fenton "; c:"Subject: RE: Forged Sender (Resent-From) attacks" 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: Some of the later followups on this thread seem to diverge from Nate's original point. Further amplification below. At 03:30 PM 8/18/2004 -0700, Harry Katz wrote: >On Wednesday, August 18, 2004 2:34 PM, Nate Leon wrote: > >> I realize concern around this topic has been raised multiple >> times (Dave Crocker, Doug Otis, Chris Haynes, etc...) but I >> still can't help feel we are under-estimating the seriousness >> of this issue. If I missed the posting where everybody >> agreed on the solution (entirely possible) please point me to it. :) >> >> I expect it will take years before all MUAs are updated (and widely >> deployed) to display the PRA, which I do not think is an >> acceptable timeframe to put a serious dent into phishing attacks. >> >> For completeness, here is another example of the concern: >> >> MAIL FROM:<> // don't care >> RCPT TO: >> DATA >> Subject: update your account info >> Resent-From: JoePhisher@phishingScam.com // valid domain >> authenticated by MARID >> ... >> From: account-services@yourbank.com // Spoofed domain, >> displayed by the MUA >> To: valid-recipient@example.com // bummer for you >> ... >> >> Are we really going to RFC with this issue left open? >> >> If nothing else, I at least want to add my vote to more >> thought being put into this topic. >> > >To address the forged Sender/Resent problem I suggest we could add the >following logic: > >If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY reject >a message after DATA. > >In other words, if we validate an identity different from 2822.From, >then there's a higher bar for a message to be accepted. The higher bar >is that check of the SPF record must return PASS, else the receiver MAY >reject the message. But I interpret Nate's "valid domain authenticated by MARID" comment above as meaning that SPFCheck(PRA) == "Pass". So the message will be accepted, and unless the MUA does display the PRA, the recipient will see just the From: address (account-services@yourbank.com in his example). So it doesn't seem like Sender ID (as it is currently specified) will have done much to improve things until MUAs catch up with it, which I expect to take some time. I would like to suggest that, if the PRA != 2822.From, 2822.From be rewritten by the receiving MTA doing the MARID check, and the original From address be copied into another header. In the majority of cases where there is a trusted path between the MTA doing the checking and the recipient, this will at least make it visible to a recipient using today's MUAs that the verification wasn't based on the From address, but something else. In Nate's example, I would suggest rewriting the From header as something like: From: "[via ]" I haven't had a chance to think about whether further attacks are possible with a rewritten From header, but without it I'm concerned that it will be quite a long time before end users benefit from Sender ID, because those intent on circumventing MARID will immediately adapt and use the Resent-From attack (or the Sender: attack, or the Resent-Sender attack). -Jim From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 11:04: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 LAA14822 for ; Mon, 23 Aug 2004 11:04: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 i7NEZL8m074675; Mon, 23 Aug 2004 07:35: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 i7NEZLSd074674; Mon, 23 Aug 2004 07:35: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 i7NEZEp9074602 for ; Mon, 23 Aug 2004 07:35:16 -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 1535417127 for ; Mon, 23 Aug 2004 10:43:45 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Solution For Trojans In-Reply-To: Your message of "Fri, 20 Aug 2004 12:23:36 PDT." <1093029816.22717.176.camel@ddev.mail-abuse.org> Date: Mon, 23 Aug 2004 10:43:45 -0400 Message-Id: <20040823144345.1535417127@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > I agree. The PRA does not authenticate the MTA as a means to identify > those administering polices to control mail. I don't think that was it's intent. It identifies a responble party, who may not be the connecting MTA. > The EHLO domain entity is granting access to the mail channel and they > have logs to sort out who did what. If networks are to be protected > from those wishing to abuse the system, only this entity is capable of > taking effective action to abate this traffic. Then why do we have MAIL FROM? The user/domain in MAIL FROM is claiming some kind of accountability for the message. They should be held responsible for something, too. > Sender-ID does not provide author protection, as it makes a false > assumption RFC2822 content is secure Is RFC 2821 content secure? As we've seen, it's unaccountable, and untrustworthy. About the only field in RFC 2821 that you can trust is RCTP TO, which doesn't mean much. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 11:20: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 LAA15877 for ; Mon, 23 Aug 2004 11:20: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 i7NEr7lX080234; Mon, 23 Aug 2004 07:53: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 i7NEr6bS080233; Mon, 23 Aug 2004 07:53: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 i7NEr5tS080218 for ; Mon, 23 Aug 2004 07:53:06 -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, 23 Aug 2004 10:53:04 -0400 id 0015F9E8.412A04D0.00002516 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20B59876-F514-11D8-8FE8-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Marshall Rose From: Andrew Newton Subject: Working Group Last Call on Sender ID documents Date: Mon, 23 Aug 2004 10:53:00 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Today begins a 2 week working group last call for the following documents: draft-ietf-marid-core-03.txt draft-ietf-marid-submitter-03.txt draft-ietf-marid-protocol-02 draft-ietf-marid-pra-00.txt To better facilitate discourse, we ask all working group participants to abide by the following parameters: 1) Messages concerning this last call should fall into one of four categories: document bugs, technical errors, technical omissions, or implementation and deployment issues. Each subject line must be prefaced with a designation stating the category into which it falls. These designations are "DOC-BUG", "TECH-ERROR", "TECH-OMISSION", and "DEPLOY". e.g., Subject: DOC-BUG: typos in -core The co-chairs will not take into consideration messages that do not meet these criteria. Here are the descriptions of the categories: DOC-BUG: Document bugs relate to simple errors within the document, such as typos, bad ABNF, etc... All messages in this category should be subject prefaced with "DOC-BUG". The author of the message should note the document bug and provide corrective text. TECH-ERROR: Technical errors are misuses of technical mechanisms specified in the document. All messages in this category should be subject prefaced with "TECH-ERROR". The author of the message should note the technical error and supply a fix if possible. TECH-OMISSION: Technical omissions are issues surrounding lack of needed functionality. An example would be failure to guard against replay attacks when using cryptographic hashes, etc... All messages in this category should be subject prefaced with "TECH-OMISSION". The author of the message should clearly note 1) the goal of the mechanism lacking the necessary feature, 2) the purpose of the necessary feature, and 3) a suggested fix to include such a feature while still adhering to the stated gaol of 1. DEPLOY: Implementation and deployment issues relate to both technical and non-technical barriers for the implementation and deployment of the specifications described in these documents. All messages in this category should be subject prefaced with "DEPLOY". The author of the message should clearly state why he/she will personally not be able to implement or deploy a specification. The author of the message should not speak on behalf of others. Inclusion of citations supporting a position will also be helpful: for technical concerns these should be citations to research or studies, for IPR concerns these should be citations to legal filings. 2) Discussions of the validity for the need of any MARID solution or the need for a MARID working group are not appropriate at this time. While these opinions may be valid, they should be discussed with the IESG as an appeal for chartering this working group. It is now the job of this working group to finish the work under its charter and not debate the validity of the charter. -MARID Co-chairs From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 13: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 NAA23386 for ; Mon, 23 Aug 2004 13:04: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 i7NGejSC008943; Mon, 23 Aug 2004 09:40: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 i7NGejOH008940; Mon, 23 Aug 2004 09:40: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 i7NGejDm008934 for ; Mon, 23 Aug 2004 09:40: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 843BD4149B; Mon, 23 Aug 2004 09:40:48 -0700 (PDT) Subject: RE: Forged Sender (Resent-From) attacks From: Douglas Otis To: Jim Fenton Cc: Harry Katz , Nate Leon , MARID In-Reply-To: <4.3.2.7.2.20040822214401.036ea008@mira-sjc5-1.cisco.com> References: <4.3.2.7.2.20040822214401.036ea008@mira-sjc5-1.cisco.com> Content-Type: text/plain Message-Id: <1093279247.22717.337.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 23 Aug 2004 09:40:47 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-08-22 at 22:02, Jim Fenton wrote: > Some of the later followups on this thread seem to diverge from Nate's > original point. Further amplification below. > > At 03:30 PM 8/18/2004 -0700, Harry Katz wrote: > >On Wednesday, August 18, 2004 2:34 PM, Nate Leon wrote: > > > >> I realize concern around this topic has been raised multiple > >> times (Dave Crocker, Doug Otis, Chris Haynes, etc...) but I > >> still can't help feel we are under-estimating the seriousness > >> of this issue. If I missed the posting where everybody > >> agreed on the solution (entirely possible) please point me to it. :) > >> > >> I expect it will take years before all MUAs are updated (and widely > >> deployed) to display the PRA, which I do not think is an > >> acceptable timeframe to put a serious dent into phishing attacks. > >> > >> For completeness, here is another example of the concern: > >> > >> MAIL FROM:<> // don't care > >> RCPT TO: > >> DATA > >> Subject: update your account info > >> Resent-From: JoePhisher@phishingScam.com // valid domain > >> authenticated by MARID > >> ... > >> From: account-services@yourbank.com // Spoofed domain, > >> displayed by the MUA > >> To: valid-recipient@example.com // bummer for you > >> ... > >> > >> Are we really going to RFC with this issue left open? > >> > >> If nothing else, I at least want to add my vote to more > >> thought being put into this topic. > > > > To address the forged Sender/Resent problem I suggest we could add the > > following logic: > > > > If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY reject > > a message after DATA. > > > > In other words, if we validate an identity different from 2822.From, > > then there's a higher bar for a message to be accepted. The higher bar > > is that check of the SPF record must return PASS, else the receiver MAY > > reject the message. > > But I interpret Nate's "valid domain authenticated by MARID" comment > above as meaning that SPFCheck(PRA) == "Pass". So the message will be > accepted, and unless the MUA does display the PRA, the recipient will > see just the From: address (account-services@yourbank.com in his > example). > > So it doesn't seem like Sender ID (as it is currently specified) will > have done much to improve things until MUAs catch up with it, which I > expect to take some time. > > I would like to suggest that, if the PRA != 2822.From, 2822.From be > rewritten by the receiving MTA doing the MARID check, and the original > From address be copied into another header. In the majority of cases > where there is a trusted path between the MTA doing the checking and > the recipient, this will at least make it visible to a recipient using > today's MUAs that the verification wasn't based on the From address, > but something else. > > In Nate's example, I would suggest rewriting the From header as > something like: > > From: "[via ]" Using this email as an example- If there is an authenticated EHLO domain, then doing something like moving the information out of the Received header to create something like: From: Jim Fenton becomes: From: "[Rcvd: above.proper.com*]" Jim Fenton The '*' indicates successful completion of EHLO authentication. This insertion would happen at the MTA at the edge of the administrative zone receiving mail on behalf of the recipient, or by an MTA that (knows its administrative zone and) authenticates all MTAs within this zone. If there was already an insertion, it would be removed. As a fall-back strategy, if the EHLO domain did not authenticate, the most prominent header as determined by RFC2822 could be used instead. Sender-ID, as currently defined, is too easily spoofed as a primary ID display offered users. The name of the header being extracted should be indicated within this notation. I suspect there will be games played with an algorithmic selection of headers, where revealing the header selection could provide a heads up. Not just "via" but a short-hand of the headers. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 13:48: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 NAA25825 for ; Mon, 23 Aug 2004 13:48:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHOLuF014812; Mon, 23 Aug 2004 10:24: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 i7NHOLMD014808; Mon, 23 Aug 2004 10:24:21 -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 i7NHOLRe014792 for ; Mon, 23 Aug 2004 10:24:21 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 96904E04A5; Mon, 23 Aug 2004 13:24:20 -0400 (EDT) Date: Mon, 23 Aug 2004 13:24:20 -0400 From: John Leslie To: Andrew Newton Cc: IETF MARID WG , Marshall Rose Subject: Re: Working Group Last Call on Sender ID documents Message-ID: <20040823172420.GC44457@verdi> References: <20B59876-F514-11D8-8FE8-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20B59876-F514-11D8-8FE8-000A95B3BA44@hxr.us> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton wrote: > > Today begins a 2 week working group last call for the following > documents: > draft-ietf-marid-core-03.txt > draft-ietf-marid-submitter-03.txt > draft-ietf-marid-protocol-02 > draft-ietf-marid-pra-00.txt > > To better facilitate discourse, we ask all working group participants > to abide by the following parameters: > > 1) Messages concerning this last call should fall into one of four > categories: document bugs, technical errors, technical omissions, or > implementation and deployment issues... Does this mean that comments posted before today must be repeated? -- John Leslie From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 14:03: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 OAA26916 for ; Mon, 23 Aug 2004 14:03: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 i7NHewhO017042; Mon, 23 Aug 2004 10: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 i7NHewJ5017041; Mon, 23 Aug 2004 10:40:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHevST017025 for ; Mon, 23 Aug 2004 10:40:57 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 23 Aug 2004 13:40:57 -0400 id 0015FA78.412A2C29.000033D0 In-Reply-To: <20040823172420.GC44457@verdi> References: <20B59876-F514-11D8-8FE8-000A95B3BA44@hxr.us> <20040823172420.GC44457@verdi> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <95E331BA-F52B-11D8-8FE8-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Marshall Rose , IETF MARID WG From: Andrew Newton Subject: Re: Working Group Last Call on Sender ID documents Date: Mon, 23 Aug 2004 13:40:55 -0400 To: John Leslie X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 23, 2004, at 1:24 PM, John Leslie wrote: > Does this mean that comments posted before today must be repeated? If you have not received explicit acknowledgment from the draft authors or co-chairs that changes will be made due to your input, then I suggest reposting. -andy From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 14:04:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27008 for ; Mon, 23 Aug 2004 14: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 i7NHcV4d016728; Mon, 23 Aug 2004 10:38: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 i7NHcVQe016727; Mon, 23 Aug 2004 10:38:31 -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 i7NHcVuA016716 for ; Mon, 23 Aug 2004 10:38:31 -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 i7NHc0g09970; Mon, 23 Aug 2004 10:38:00 -0700 Date: Mon, 23 Aug 2004 10:37:57 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <925146391.20040823103757@brandenburg.com> Subject: China ISC anti-spam California meeting report 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, Following the useful discussions in Beijing, last Spring, a second working meeting was held in California, between Internet Society of China's anti-spam staff and a number of representatives of anti-spam organizations. This meeting significantly expanded the set of non-Chinese participants from the anti-spam community. Notes from the meeting are available at: d/ ----- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 14: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 OAA27332 for ; Mon, 23 Aug 2004 14: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 i7NHZGM7016267; Mon, 23 Aug 2004 10:35: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 i7NHZGVZ016266; Mon, 23 Aug 2004 10:35: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 i7NHZGTv016260 for ; Mon, 23 Aug 2004 10:35:16 -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 1342E4149B; Mon, 23 Aug 2004 10:35:20 -0700 (PDT) Subject: Re: Solution For Trojans From: Douglas Otis To: Alan DeKok Cc: MARID In-Reply-To: <20040823144345.1535417127@mail.nitros9.org> References: <20040823144345.1535417127@mail.nitros9.org> Content-Type: text/plain Message-Id: <1093282518.22717.386.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 23 Aug 2004 10:35: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 Mon, 2004-08-23 at 07:43, Alan DeKok wrote: > Douglas Otis wrote: > > I agree. The PRA does not authenticate the MTA as a means to identify > > those administering polices to control mail. > > I don't think that was it's intent. It identifies a responsible > party, who may not be the connecting MTA. It provides an identity based upon many unverifiable assumptions. These unverifiable assumptions ensures there can never be certainty with respect to accountability. Only when there is certainty, can this identity be held accountable. Also, as it stands, such an identity could possibly come from any MTA in the world. What does this mean with respect to accountability? Sorry, but Sender-ID is not about responsibility or accountability. Sender-ID may not relate to any MTA or relate to hundreds of other unidentified domains with separate administrations. If there is a problem, who can take action to curtail the problem? If, despite a lack of certainty, this identity is held accountable and thereby blocked, what recourse would they have? Which MTA suffers from a lack of integrity in the case of a spoofed Sender-ID entity? This could be an integrity problem with the recipient. Sender-ID is always checked by the recipient, and if there is a lapse of checking within a chain leading to the recipient, why should the entity identified by Sender-ID be held accountable? Would there be a blacklist for complainers and complaints? Would it be possible to complain, if the Sender-ID list were "open"? > > The EHLO domain entity is granting access to the mail channel and they > > have logs to sort out who did what. If networks are to be protected > > from those wishing to abuse the system, only this entity is capable of > > taking effective action to abate this traffic. > > Then why do we have MAIL FROM? The user/domain in MAIL FROM is > claiming some kind of accountability for the message. They should be > held responsible for something, too. This is the return path for a delivery error. By definition, this is unrelated to the MTA sending the message. This MAIL FROM identity, as it stands, is worthless for determining responsibility. SPF attempted to prescribe a mail channel related to the Mailbox Domain. But that breaks list servers, mail forwarding, etc. > > Sender-ID does not provide author protection, as it makes a false > > assumption RFC2822 content is secure > > Is RFC 2821 content secure? As we've seen, it's unaccountable, and > untrustworthy. About the only field in RFC 2821 that you can trust is > RCTP TO, which doesn't mean much. This overlooks the EHLO domain that can be authenticated and verified to have been authorized by the domain to act as an outbound MTA. The RCPT TO does not indicate any accountable entity. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 15:33: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 PAA04855 for ; Mon, 23 Aug 2004 15: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 i7NJ7dJU024294; Mon, 23 Aug 2004 12:07: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 i7NJ7dqY024293; Mon, 23 Aug 2004 12:07:39 -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 i7NJ7ckK024286 for ; Mon, 23 Aug 2004 12:07:38 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040823190735.PCWM4758.tomts13-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 23 Aug 2004 15:07:35 -0400 From: "John Glube" To: "'Marshall Rose'" Cc: "'IETF MARID WG'" , "'Andrew Newton'" Subject: Deadline for IPR filings Date: Mon, 23 Aug 2004 15:07:26 -0400 Message-ID: <009a01c48944$6dd39220$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20040823172420.GC44457@verdi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7NJ7ckK024288 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Marshall, I probably should have asked this question sooner. On August 6, concerning short term milestones, you wrote: >3. final ipr statements are due monday, august 23rd. >4. working group last call on the revised documents begins >monday, august 23rd. the co-chairs will be sending out a >separate email on this topic closer to this date. http://www.imc.org/ietf-mxcomp/mail-archive/msg03046.html In response to a follow up question, Andy wrote: >To belay any fears, Aug 23 is a hard and fast deadline. http://www.imc.org/ietf-mxcomp/mail-archive/msg03060.html By stating: >final ipr statements are due monday, august 23rd: * What time zone does one use? * Did this mean by Monday, August 23, 2004 so that statements would have to be filed by midnight, Sunday, August 22, 2004 or on Monday, August 23, 2004 so that statements would have to be filed by midnight of today, or such other time frame on either of these dates as the Chairs may indicate? I apologize for being picky, however since much has been made of this deadline, I am simply asking for the record to be clear. John P.S. Also, since we are in last call and any license requirements may have a bearing on implementation issues, could you ask that the full notice of any filings also be sent to this list, so that all can be made aware of any statements made? cc. Andy Newton John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of John Leslie Sent: August 23, 2004 1:24 PM To: Andrew Newton Cc: IETF MARID WG; Marshall Rose Subject: Re: Working Group Last Call on Sender ID documents Andrew Newton wrote: > > Today begins a 2 week working group last call for the following > documents: > draft-ietf-marid-core-03.txt > draft-ietf-marid-submitter-03.txt > draft-ietf-marid-protocol-02 > draft-ietf-marid-pra-00.txt > > To better facilitate discourse, we ask all working group participants > to abide by the following parameters: > > 1) Messages concerning this last call should fall into one of four > categories: document bugs, technical errors, technical omissions, or > implementation and deployment issues... Does this mean that comments posted before today must be repeated? -- John Leslie --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 16:14: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 QAA07506 for ; Mon, 23 Aug 2004 16:14: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 i7NJoClO027535; Mon, 23 Aug 2004 12:50: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 i7NJoCxH027534; Mon, 23 Aug 2004 12:50:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from soyouz2.netaktiv.com (ns2.netaktiv.com [80.67.170.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NJo918027522 for ; Mon, 23 Aug 2004 12:50:12 -0700 (PDT) (envelope-from stephane@sources.org) Received: by soyouz2.netaktiv.com (Postfix, from userid 10) id 4F9DAA7BAD; Mon, 23 Aug 2004 21:50:08 +0200 (CEST) Received: from preston.sources.org (preston [172.19.1.2]) by mail.sources.org (Postfix) with ESMTP id 84DDC148BB for ; Mon, 23 Aug 2004 21:48:04 +0200 (CEST) Received: by preston.sources.org (Postfix, from userid 1000) id D6407AAE14; Mon, 23 Aug 2004 21:48:03 +0200 (CEST) Date: Mon, 23 Aug 2004 21:48:03 +0200 From: Stephane Bortzmeyer To: ietf-mxcomp@imc.org Subject: [DEPLOY] Privacy and disclosure of addresses in -core Message-ID: <20040823194803.GA2802@preston.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Operating-System: NetBSD 1.6.2 sparc64 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [I hesitated a lot about the subject, feel free to flame this first Last Call message.] The whole purpose of Sender-ID is to disclose the real email address used for the last introduction of the message. This can conflict with privacy expectations (think of the example in draft-ietf-marid-submitter-03.txt, where Alice (unknowingly?) reveals that she is at such or such hotel). The problem already exists with the Received headers but the advice in -core (7.5 "MUA implementers") to display the addresses used in the PRA makes it stronger, IMHO. I do not find an easy solution (it is an inherent conflict) but I suggest to add to "Security considerations" in -core: Automatically adding headers like Resent-From and Sender, as mandated here, may have privacy consequences for the users. MUA implementors may make this header addition optional, at the risk of seeing the mail rejected later. Alternatively, users and administrators should be aware of other solutions like [RFC 2476] or various tunnels. From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 16:42:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10797 for ; Mon, 23 Aug 2004 16:42:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKJoEq030724; Mon, 23 Aug 2004 13:19: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 i7NKJoLH030723; Mon, 23 Aug 2004 13:19:50 -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 i7NKJorN030717 for ; Mon, 23 Aug 2004 13:19:50 -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, 23 Aug 2004 16:19:50 -0400 id 0015FA78.412A5166.00004256 In-Reply-To: References: <20B59876-F514-11D8-8FE8-000A95B3BA44@hxr.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Marshall Rose , IETF MARID WG From: Andrew Newton Subject: Re: Working Group Last Call on Sender ID documents Date: Mon, 23 Aug 2004 16:19:48 -0400 To: Daniel Quinlan X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 23, 2004, at 4:16 PM, Daniel Quinlan wrote: > Do you prefer for similarly designated issues ("DOC-BUG", etc.) for a > particular document ("-core", etc.) to be bundled in a single email or > for each issue be submitted in a separate message? (I'm assuming > related issues should be in a single message even if separate sections > of the document are affected.) Doing them separately helps us keep track of the issues. Thanks. -andy From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 16:44: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 QAA11019 for ; Mon, 23 Aug 2004 16:44: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 i7NKGcgL030532; Mon, 23 Aug 2004 13:16: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 i7NKGch9030531; Mon, 23 Aug 2004 13:16:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKGaKN030523 for ; Mon, 23 Aug 2004 13:16:38 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzLF4-0005pY-00; Mon, 23 Aug 2004 13:16:34 -0700 To: Andrew Newton Cc: IETF MARID WG , Marshall Rose Subject: Re: Working Group Last Call on Sender ID documents References: <20B59876-F514-11D8-8FE8-000A95B3BA44@hxr.us> From: Daniel Quinlan Date: 23 Aug 2004 13:16:34 -0700 In-Reply-To: Andrew Newton's message of "Mon, 23 Aug 2004 10:53:00 -0400" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Do you prefer for similarly designated issues ("DOC-BUG", etc.) for a particular document ("-core", etc.) to be bundled in a single email or for each issue be submitted in a separate message? (I'm assuming related issues should be in a single message even if separate sections of the document are affected.) Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 19: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 TAA27158 for ; Mon, 23 Aug 2004 19: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 i7NNEcXi047087; Mon, 23 Aug 2004 16:14: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 i7NNEcsh047086; Mon, 23 Aug 2004 16:14:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNEb27047079 for ; Mon, 23 Aug 2004 16:14:37 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzO1Q-0007xU-00; Mon, 23 Aug 2004 16:14:40 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.31328.393827.721202@proton.pathname.com> Date: Mon, 23 Aug 2004 16:14:40 -0700 To: IETF MARID WG Subject: TECH-OMISSION: failure action is too restrictive in -core X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In section 5.3, this specification assumes all SPF checking will be done at SMTP time which is not realistic. Some examples: some implementations may retest a message later to either verify Sender-ID results, because the load was too high when the message was received, because the SPF checking was done after-SMTP (SpamAssassin). This section should also leave open other authentication methods such as POP before SMTP, SMTP AUTH, etc. In addition, when done at SMTP time, other actions may be desirable on the MTA such as a temp fail, throttling, teergrubing, etc. I recommend changing the paragraph to read: An SMTP server receiving this result SHOULD NOT treat the message as authentic. However, it MAY treat the message as authentic or not authentic based on other authentication methods. If the message is rejected during the SMTP session, the SMTP server SHOULD reject the message with a "550 5.7.1 Sender ID xxx - yyy" SMTP error, where "xxx" is replaced with the additional reason returned by the check_host function and "yyy" is replaced with the explanation string returned by the check_host function. Section 5.5 has the same assumptions, but because "MAY" is used there, it's not an issue for implementors. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 19: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 TAA27160 for ; Mon, 23 Aug 2004 19: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 i7NNB7xQ046827; Mon, 23 Aug 2004 16: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 i7NNB71S046826; Mon, 23 Aug 2004 16:11:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNB6nj046819 for ; Mon, 23 Aug 2004 16:11:06 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzNy1-0007pc-00; Mon, 23 Aug 2004 16:11:09 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.31117.662266.736155@proton.pathname.com> Date: Mon, 23 Aug 2004 16:11:09 -0700 To: IETF MARID WG Subject: TECH-OMISSION: leave open other authentication methods in -core X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In section 5.2, the paragraph defining the result for pass should be changed to An SMTP server receiving this result SHOULD treat the message as authentic. However, it MAY treat the message as authentic or not authentic based on other authentication methods. It MAY accept or reject the message depending on other policies. in order to allow for other authentication methods such as POP before SMTP, SMTP AUTH, etc. It may be possible to find a better phrasing to address this omission. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 19:39: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 TAA27284 for ; Mon, 23 Aug 2004 19:39: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 i7NNJfnk047449; Mon, 23 Aug 2004 16: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 i7NNJfgQ047448; Mon, 23 Aug 2004 16:19:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNJe1C047442 for ; Mon, 23 Aug 2004 16:19:40 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzO6K-0008Nv-00; Mon, 23 Aug 2004 16:19:44 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.31632.97107.68023@proton.pathname.com> Date: Mon, 23 Aug 2004 16:19:44 -0700 To: IETF MARID WG Subject: DOC-BUG: documentation bugs in -core X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A few minor issues: a. all-uppercase words in -core "DOMAIN" is used only once in all-uppercase (in 2.1). RFC 2822 doesn't appear to use it that way. Same issue for "MOST RECENT" and "UNRELATED" (both in 2.1). b. "domain" is not defined in -core and other documents For clarity, "domain" should be defined as an RFC 2822 domain. That is, it should be defined as the right-hand-side of an email address. c. to fix some awkwardness in the introduction, I suggest this replacement: s/substantially all of the/nearly all/ -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 19:43:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27638 for ; Mon, 23 Aug 2004 19:43: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 i7NNNf4I047726; Mon, 23 Aug 2004 16:23:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NNNfqx047725; Mon, 23 Aug 2004 16:23:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNNecg047705 for ; Mon, 23 Aug 2004 16:23:41 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzOAD-00007H-00; Mon, 23 Aug 2004 16:23:45 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.31873.171081.835847@proton.pathname.com> Date: Mon, 23 Aug 2004 16:23:45 -0700 To: IETF MARID WG Subject: TECH-OMISSION: "/pra" should not be hard-coded in -protocol X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This may also be a deployment issue since there are still unresolved issues with the MS patent license. In section 3.4.1 and Appendix A, the "/pra" scope should not be hard-coded, this should just be specified as something like: version = "spf2." ver-minor "/" scope *( "," scope) With some language specifying where the first scope, "/pra" is defined, that at least one scope must be defined by a publisher, and that if no known scope is specified that the result is then neutral. The problem with hard-coding this is that it requires this document to be revisioned to replace the "/pra" scope. It's also just a nasty way to write a specification. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 19:50: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 TAA28250 for ; Mon, 23 Aug 2004 19: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 i7NNUdEm048191; Mon, 23 Aug 2004 16:30:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NNUdIL048190; Mon, 23 Aug 2004 16:30:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNUdhn048182 for ; Mon, 23 Aug 2004 16:30:39 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzOGv-0001Em-00; Mon, 23 Aug 2004 16:30:41 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.32289.260650.281859@proton.pathname.com> Date: Mon, 23 Aug 2004 16:30:41 -0700 To: IETF MARID WG Subject: DEPLOY: TXT vs. SPF2 queries in -protocol X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit By requiring SPF2 records to be looked up when they are not widely deployed (or at all?) and making TXT record lookups optional when they are already widely deployed, the specification effectively doubles the number of DNS queries required for Sender-ID lookups and makes it more difficult, slower, etc. for SPF queries to succeed, fail, timeout, etc. in practice. suggested change 1: Waiting for a negative answer for SPF2 queries before looking up TXT is not going to yield acceptable performance for most implementations, this should not be suggested unless the suggestion is coupled with a flag day. suggested change 2: Different implementations may have different results as long as TXT records are deployed. This should be noted. suggested change 3: Since there is currently a forward path defined for transitioning from TXT to SPF2, a flag day should be suggested if this poorly-reasoned pedantic path is taken. Using TXT forever would be much more practical and cleaner. New additional "TXT" records can be defined for similar future working-around the difficulty in deploying new DNS RR types. suggested change 4: change "later" to "latter" in 3.4.1 -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 19:56: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 TAA28664 for ; Mon, 23 Aug 2004 19: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 i7NNaV4h048501; Mon, 23 Aug 2004 16:36: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 i7NNaVuO048500; Mon, 23 Aug 2004 16:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNaVXm048494 for ; Mon, 23 Aug 2004 16:36:31 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzOMb-0001HD-00; Mon, 23 Aug 2004 16:36:33 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.32641.736435.727947@proton.pathname.com> Date: Mon, 23 Aug 2004 16:36:33 -0700 To: IETF MARID WG Subject: DOC-BUG: an example for "neutral" would be good in -protocol X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think a bit more should be said about Neutral, maybe just an example of where this would be useful (Section 3.2). -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 19:56:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28687 for ; Mon, 23 Aug 2004 19:56: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 i7NNb2hA048541; Mon, 23 Aug 2004 16:37: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 i7NNb2BQ048540; Mon, 23 Aug 2004 16:37:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNb1S1048534 for ; Mon, 23 Aug 2004 16:37:01 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzON7-0001Hu-00; Mon, 23 Aug 2004 16:37:05 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.32673.222833.688650@proton.pathname.com> Date: Mon, 23 Aug 2004 16:37:05 -0700 To: IETF MARID WG Subject: TECH-ERROR: PTR should not be recommended against in -protocol X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit PTR has useful semantics and has the same potential overhead as MX. It should not be recommended against. At most, "A" should be recommended over both "MX" and "PTR" -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 19:57: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 TAA28766 for ; Mon, 23 Aug 2004 19:57: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 i7NNZGed048435; Mon, 23 Aug 2004 16:35: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 i7NNZG3h048434; Mon, 23 Aug 2004 16:35:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNZGJR048428 for ; Mon, 23 Aug 2004 16:35:16 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzOLQ-0001GN-00; Mon, 23 Aug 2004 16:35:20 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.32568.397886.244207@proton.pathname.com> Date: Mon, 23 Aug 2004 16:35:20 -0700 To: IETF MARID WG Subject: TECH-OMISSION: billing.victim.com is possible X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Since Sender-ID is defined to be using the domain (RHS) of the email address, all a spammer/phisher needs to do is fake their email to come from "billing.victim.com" or some other undefined host. Then, no Sender-ID record will be defined. No Sender-ID record is possibly preferrable to a spammer/phisher to an SPF failure for "victim.com" or an SPF pass for one of their own domains. It may be sufficient to state that an implementation MAY fail or softfail in check_host() domain if no SPF2, MX, or A record exists. I don't think wildcards are a full solution, but they can be used as a flawed workaround in some situations for this issue. This is a plus in the column for wildcards, I think (section 2.1.7 in -protocol). -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 19:59:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29020 for ; Mon, 23 Aug 2004 19: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 i7NNeixp048759; Mon, 23 Aug 2004 16:40: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 i7NNeiJh048758; Mon, 23 Aug 2004 16:40:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNehVe048751 for ; Mon, 23 Aug 2004 16:40:43 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzOQh-0001SL-00; Mon, 23 Aug 2004 16:40:47 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.32895.132368.340022@proton.pathname.com> Date: Mon, 23 Aug 2004 16:40:47 -0700 To: IETF MARID WG Subject: DOC-BUG: include: would be clearer with examples in -protocol X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I suggest adding include: examples for both an include: resulting in a failure as well as a pass. The semantics is a bit confusing the first time read since pass has a different meaning. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 20:02:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29235 for ; Mon, 23 Aug 2004 20:02:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNggBv048895; Mon, 23 Aug 2004 16:42: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 i7NNggsq048894; Mon, 23 Aug 2004 16:42:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNggt6048886 for ; Mon, 23 Aug 2004 16:42:42 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzOSc-0001ob-00; Mon, 23 Aug 2004 16:42:46 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.33014.487251.811635@proton.pathname.com> Date: Mon, 23 Aug 2004 16:42:46 -0700 To: IETF MARID WG Subject: DEPLOY: processing limits are way too high in -protocol X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In Section 6.2, the 10 check_host() evaluation limit is way too high and could allow for easier DoS attacks. In addition, there is no limit for how large each SPF2 record should be and there should be in order to limit the impact of each of those 10 check_host() evaluations. I recommend lowering this unless someone has a reasonable case as to why 10 is needed. 5 seems high enough. Even 8 would be an improvement. It would be good to have some additional limits -- this is just too wide open. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 20: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 UAA29327 for ; Mon, 23 Aug 2004 20: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 i7NNhjOH048949; Mon, 23 Aug 2004 16: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 i7NNhjXR048948; Mon, 23 Aug 2004 16:43:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNhinM048942 for ; Mon, 23 Aug 2004 16:43:44 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzOTd-0001pf-00; Mon, 23 Aug 2004 16:43:49 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.33077.71829.32436@proton.pathname.com> Date: Mon, 23 Aug 2004 16:43:49 -0700 To: IETF MARID WG Subject: DOC-BUG: PTR mention needed in 6.2 in -protocol X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This sentence: Using "mx" over "a" allows the set of mail hosts to be changed easily. should be changed to: Using "mx" or "ptr" over "a" allows the set of mail hosts to be changed easily. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 20:14: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 UAA29943 for ; Mon, 23 Aug 2004 20:14: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 i7NNrrsT049632; Mon, 23 Aug 2004 16:53: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 i7NNrrwe049631; Mon, 23 Aug 2004 16:53:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNrqP4049624 for ; Mon, 23 Aug 2004 16:53:52 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1BzOdR-0002at-00; Mon, 23 Aug 2004 16:53:57 -0700 From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.33684.999278.517754@proton.pathname.com> Date: Mon, 23 Aug 2004 16:53:56 -0700 To: IETF MARID WG Subject: some other questions/comments X-Mailer: VM 7.16 under Emacs 20.7.2 Reply-To: quinlan@pathname.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit These didn't make my cut for last call comments. - US-ASCII requirement: internationalized DNS? - If Verisign starts doing wildcard DNS again, does that have an impact on any of the mechanisms described in Sender-ID? I can think of one: "... -exists:%{ir}.bl.somednsbl.org ~all" If Verisign redeploys wildcard DNS and somednsbl.org goes down (even temporarily!), then there are going to be more failures than there would have been without wildcard DNS. There may be others. - It seems like it would be good to have more flexible exp modifiers. First, there are multiple reasons why a FAIL might happen, so I think exp: should be neither global nor singular. Second, I can't think of any reason to also not allow exp: for all other results, even including PASS, although that would require additional syntax. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 20: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 UAA29961 for ; Mon, 23 Aug 2004 20:14: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 i7NNpqT5049499; Mon, 23 Aug 2004 16:51: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 i7NNpqKu049498; Mon, 23 Aug 2004 16:51:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NNpqCI049491 for ; Mon, 23 Aug 2004 16:51:52 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 23 Aug 2004 16:51:57 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Aug 2004 16:51:55 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Aug 2004 16:51:57 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 16:51:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH-OMISSION: failure action is too restrictive in -core Date: Mon, 23 Aug 2004 16:52:13 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8896B4@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: TECH-OMISSION: failure action is too restrictive in -core Thread-Index: AcSJaLD9WorlpOVwQEiydg4uV8z3GAAAz+fA From: "Jim Lyon" To: , "IETF MARID WG" X-OriginalArrivalTime: 23 Aug 2004 23:51:45.0580 (UTC) FILETIME=[25BC7EC0:01C4896C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7NNpqCI049492 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Daniel's point is well-taken here. While I think his proposed verbiage is somewhat awkward, I'll see if I can find alternate words that express his point. I don't think that a new draft is necessary for this reason, but I'll be happy to include a change should a new draft occur for other reasons. -- Jim Lyon -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Daniel Quinlan Sent: Monday, August 23, 2004 4:15 PM To: IETF MARID WG Subject: TECH-OMISSION: failure action is too restrictive in -core In section 5.3, this specification assumes all SPF checking will be done at SMTP time which is not realistic. Some examples: some implementations may retest a message later to either verify Sender-ID results, because the load was too high when the message was received, because the SPF checking was done after-SMTP (SpamAssassin). This section should also leave open other authentication methods such as POP before SMTP, SMTP AUTH, etc. In addition, when done at SMTP time, other actions may be desirable on the MTA such as a temp fail, throttling, teergrubing, etc. I recommend changing the paragraph to read: An SMTP server receiving this result SHOULD NOT treat the message as authentic. However, it MAY treat the message as authentic or not authentic based on other authentication methods. If the message is rejected during the SMTP session, the SMTP server SHOULD reject the message with a "550 5.7.1 Sender ID xxx - yyy" SMTP error, where "xxx" is replaced with the additional reason returned by the check_host function and "yyy" is replaced with the explanation string returned by the check_host function. Section 5.5 has the same assumptions, but because "MAY" is used there, it's not an issue for implementors. -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 20:30: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 UAA00841 for ; Mon, 23 Aug 2004 20:30: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 i7O08sq6050647; Mon, 23 Aug 2004 17:08: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 i7O08sXD050646; Mon, 23 Aug 2004 17:08:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O08rlJ050628 for ; Mon, 23 Aug 2004 17:08:53 -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, 23 Aug 2004 17:08:56 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Aug 2004 17:08:54 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Aug 2004 17:08:55 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 17:08:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: TECH-ERROR: DNS Record Types Date: Mon, 23 Aug 2004 17:09:13 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: TECH-ERROR: DNS Record Types Thread-Index: AcSJbpYyNz0Z3YrnQ06fCsBpUNcvxw== From: "Jim Lyon" To: "IETF MARID WG" X-OriginalArrivalTime: 24 Aug 2004 00:08:43.0264 (UTC) FILETIME=[8452C000:01C4896E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7O08rlJ050641 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I believe that the latest Protocol draft (draft-ietf-marid-protocol-03) contains changes that don't correctly reflect the consensus of the group concerning DNS record types. Briefly, it states: 1. Publishers MUST publish using the new SPF2 record type. 2. Publishers MAY also publish using TXT records. 3. Consumers MUST do lookups using the new SPF2 record type. 4. Consumers MAY also do lookups using TXT records. 5. Consumers MAY do both lookups (3 and 4) in parallel. 6. If consumers receive records from both lookups, they SHOULD use the SPF2 record and ignore the TXT record. These are all in section 2.1.1 of the Protocol doc. The problems with the above are: a. It's not what was previously debated / agreed to. b. Anyone who can't publish an SPF2 record cannot comply with this spec. c. Anyone who can't look up an SPF2 record cannot comply with this spec. d. Publishers who take the "MAY" in step 2 above to heart and don't publish TXT records will have their record be completely invisible to consumers that can't query for the new record type. I respectfully request that the above requirements be replaced with: 1.Pushblishers SHOULD publish using the new SPF2 record type, if they are able to do so. 2. Regardless of whether they published using the SPF2 record type, publishers MUST publish a TXT record. 2a.The contents of the SPF2 record and TXT record MUST be identical. 3. Consumers SHOULD check for the new SPF2 record type, if they are able to do so. 4. Consumers who either cannot query for SPF2 records or who find that a domain hasn't published any SPF2 records MUST query for a TXT record. 5. Consumers MAY do both lookups (3 and 4) in parallel. 6. If consumers receive records from both lookups, they SHOULD use the SPF2 record and ignore the TXT record. Brief Discussion: It's undisputed that the world would be a better place if everyone uses the new record type. However, it's also undisputed that many players won't be able to publish and/or consume the new record type until new software is installed. The updated requirements as I've spelled them out above will me that: a) Everyone can work before new DNS software is installed. b) After new DNS software is installed, there will be minimal harm to the DNS system. I think that (a) is obvious. There are four sub-cases: i. Publisher and consumer both have out-of-date DNS software: If the publisher and consumer both have out-of-date DNS software, the publisher will only publish a TXT record. The consumer will only query for a TXT record, and get the right information. All of the oft-debated issues of packet size and TCP fallback apply. ii. Publisher has up-to-date DNS software and consumer has out-of-date DNS software: If the publisher has up-to-date DNS software, he'll publish both an SPF2 record and a TXT record. The consumer will only query for a TXT record, and get the right information. All of the packet size and TCP fallback issues apply. iii. Publisher has out-of-date DNS software and consumer has up-to-date DNS software: If the publisher has out-of-date DNS software, he'll only publish a TXT record. The consumer will query for a DNS2 record, and receiving no records will query for a TXT record, yielding the right information. All of the packet size and TCP fallback issues will apply. iv. Publisher and consumer both have up-to-date DNS software. If both the publisher and the consumer have up-to-date DNS software, the publisher will publish both an SPF2 and a TXT record. They consumer will query for the SPF2 record, and get the right information. The packet-size issues will generally not apply, because the SPF2 record won't be mingled with other irrelevant records. So in all four cases, the updated requirements work. Contrast this with the currently specified requirements, which cause cases (ii) and (iii) to fail to discover the record. b. Note that after up-to-date DNS software is widely deployed, only SPF2 record will be queried for. The TXT records will still exist, but will not be the subject of queries by SenderID software. As such, the only harm that the TXT records cause is that they will take up space in packets when other applications query for TXT records for a domain. However, as there aren't any such widely-deployed other applications, this harm is minimal and largely theoretical. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 20:36:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01239 for ; Mon, 23 Aug 2004 20:36: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 i7O09vlx050746; Mon, 23 Aug 2004 17:09:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O09vHE050745; Mon, 23 Aug 2004 17:09:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O09vSL050734 for ; Mon, 23 Aug 2004 17:09:57 -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, 23 Aug 2004 17:09:59 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Aug 2004 17:09:58 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Aug 2004 17:09:59 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 17:10:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: TECH-ERROR: DNS Server Requirements Date: Mon, 23 Aug 2004 17:10:17 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8896D6@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: TECH-ERROR: DNS Server Requirements Thread-Index: AcSJbrw9y0zRQRdjRtGvPt/Kl3olrw== From: "Jim Lyon" To: "IETF MARID WG" X-OriginalArrivalTime: 24 Aug 2004 00:10:08.0752 (UTC) FILETIME=[B7472F00:01C4896E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7O09vSL050739 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The Protocol spec (draft-ietf-marid-protocol-03) has the following interesting sentence in section 2.1.6: Nevertheles, Sender-ID compliant sites MUST use DNS recursive servers that support EDNS0 [RFC2671] and [RFC3226] in order to be able to receive large DNS RR sets. Problems: 1. This sentence is unclear. Either it means "servers MUST support RFC2671 and RFC3226, and the reason is to receive large DNS RR sets", or it means "if servers want to receive large DNS RR sets, they must support RFC2671 and RFC3226." I'm assuming the first meaning was intended. 2. The reference to RFC3226 is irrelevant. RFC3226 says, in essence, that DNS servers that support either DNSSEC or IPv6 MUST also support EDNS0. 3. While EDNS0's job is to ameliorate the pain of large DNS responses, the SenderID and the DNS system will work correctly without it. In fact, there will probably be very few sites whose published records exceed a basic DNS packet. 4. While it's a good idea for DNS servers and resolvers to support EDNS0, many of today's don't. This mandate will therefore get in the way of adoption. 5. As far as I know, this particular question was not brought up on the mailing list before inclusion of the mandate in the spec. I therefore request deletion of this mandate. (I'd delete the entire paragraph.) -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 21: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 VAA05381 for ; Mon, 23 Aug 2004 21: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 i7O13ZvX054225; Mon, 23 Aug 2004 18:03: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 i7O13Zwt054224; Mon, 23 Aug 2004 18:03:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O13Y8X054216 for ; Mon, 23 Aug 2004 18:03:35 -0700 (PDT) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LE0D5LJ1A800005R@mauve.mrochek.com> for ietf-mxcomp@imc.org; Mon, 23 Aug 2004 18:03:37 -0700 (PDT) Date: Mon, 23 Aug 2004 18:03:25 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: TECH-ERROR: DNS Record Types In-reply-to: "Your message dated Mon, 23 Aug 2004 17:09:13 -0700" <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> To: Jim Lyon Cc: IETF MARID WG Message-id: <01LE0GZAXUBW00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT FWIW, I fuly support making this change. Ned > I believe that the latest Protocol draft (draft-ietf-marid-protocol-03) > contains changes that don't correctly reflect the consensus of the group > concerning DNS record types. Briefly, it states: > 1. Publishers MUST publish using the new SPF2 record type. > 2. Publishers MAY also publish using TXT records. > 3. Consumers MUST do lookups using the new SPF2 record type. > 4. Consumers MAY also do lookups using TXT records. > 5. Consumers MAY do both lookups (3 and 4) in parallel. > 6. If consumers receive records from both lookups, they SHOULD use > the SPF2 record and ignore the TXT record. > These are all in section 2.1.1 of the Protocol doc. > The problems with the above are: > a. It's not what was previously debated / agreed to. > b. Anyone who can't publish an SPF2 record cannot comply with this spec. > c. Anyone who can't look up an SPF2 record cannot comply with this spec. > d. Publishers who take the "MAY" in step 2 above to heart and don't > publish TXT records will have their record be completely invisible > to consumers that can't query for the new record type. > I respectfully request that the above requirements be replaced with: > 1.Pushblishers SHOULD publish using the new SPF2 record type, > if they are able to do so. > 2. Regardless of whether they published using the SPF2 record > type, publishers MUST publish a TXT record. > 2a.The contents of the SPF2 record and TXT record MUST be identical. > 3. Consumers SHOULD check for the new SPF2 record type, if they > are able to do so. > 4. Consumers who either cannot query for SPF2 records or who find > that a domain hasn't published any SPF2 records MUST query for > a TXT record. > 5. Consumers MAY do both lookups (3 and 4) in parallel. > 6. If consumers receive records from both lookups, they SHOULD use > the SPF2 record and ignore the TXT record. > Brief Discussion: > It's undisputed that the world would be a better place if everyone uses > the new record type. However, it's also undisputed that many players > won't be able to publish and/or consume the new record type until new > software is installed. The updated requirements as I've spelled them out > above will me that: > a) Everyone can work before new DNS software is installed. > b) After new DNS software is installed, there will be minimal harm to > the DNS system. > I think that (a) is obvious. There are four sub-cases: > i. Publisher and consumer both have out-of-date DNS software: > If the publisher and consumer both have out-of-date DNS software, the > publisher will only publish a TXT record. The consumer will only query > for a TXT record, and get the right information. All of the oft-debated > issues of packet size and TCP fallback apply. > ii. Publisher has up-to-date DNS software and consumer has out-of-date > DNS software: > If the publisher has up-to-date DNS software, he'll publish both an SPF2 > record and a TXT record. The consumer will only query for a TXT record, > and get the right information. All of the packet size and TCP fallback > issues apply. > iii. Publisher has out-of-date DNS software and consumer has up-to-date > DNS software: > If the publisher has out-of-date DNS software, he'll only publish a TXT > record. The consumer will query for a DNS2 record, and receiving no > records will query for a TXT record, yielding the right information. All > of the packet size and TCP fallback issues will apply. > iv. Publisher and consumer both have up-to-date DNS software. > If both the publisher and the consumer have up-to-date DNS software, the > publisher will publish both an SPF2 and a TXT record. They consumer will > query for the SPF2 record, and get the right information. The > packet-size issues will generally not apply, because the SPF2 record > won't be mingled with other irrelevant records. > So in all four cases, the updated requirements work. Contrast this with > the currently specified requirements, which cause cases (ii) and (iii) > to fail to discover the record. > b. Note that after up-to-date DNS software is widely deployed, only SPF2 > record will be queried for. The TXT records will still exist, but will > not be the subject of queries by SenderID software. As such, the only > harm that the TXT records cause is that they will take up space in > packets when other applications query for TXT records for a domain. > However, as there aren't any such widely-deployed other applications, > this harm is minimal and largely theoretical. > -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 21:30: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 VAA05453 for ; Mon, 23 Aug 2004 21:30: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 i7O16BBL054386; Mon, 23 Aug 2004 18:06: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 i7O16BDd054384; Mon, 23 Aug 2004 18:06:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O16BdO054377 for ; Mon, 23 Aug 2004 18:06:11 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7O1DvrW015276; Mon, 23 Aug 2004 18:13:57 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7O1DvSI015273; Mon, 23 Aug 2004 18:13:57 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 23 Aug 2004 18:13:57 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: IETF MARID WG Subject: Re: TECH-ERROR: DNS Record Types In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 23 Aug 2004, Jim Lyon wrote: > I believe that the latest Protocol draft (draft-ietf-marid-protocol-03) > contains changes that don't correctly reflect the consensus of the group > concerning DNS record types. Briefly, it states: > > 1. Publishers MUST publish using the new SPF2 record type. > 2. Publishers MAY also publish using TXT records. > 3. Consumers MUST do lookups using the new SPF2 record type. > 4. Consumers MAY also do lookups using TXT records. > 5. Consumers MAY do both lookups (3 and 4) in parallel. > 6. If consumers receive records from both lookups, they SHOULD use > the SPF2 record and ignore the TXT record. > > These are all in section 2.1.1 of the Protocol doc. > > The problems with the above are: > > a. It's not what was previously debated / agreed to. It has been debated, but it may not have been agreed to by all. > b. Anyone who can't publish an SPF2 record cannot comply with this spec. That will case those who can not publish SPF2 record to make their service compliant to be able to fully supportthe spec. However you maybe right that its too strong to say they are can not comply with spec at all. > c. Anyone who can't look up an SPF2 record cannot comply with this spec. Same as above, but here I feel more strongly that everyone should provide ability to read the records and those that dont are not compliant. And even with microsoft system dns problems (which btw means microsoft software is not compliant with some dns specs...), I've not seen any argument that microsoft software can not read new/unknown record types - it can do it given DNS type number, it just does not know how to interprete it as part of the library and that would be up to software to do, which I dont think is that hard given text format of SPF records. > d. Publishers who take the "MAY" in step 2 above to heart and don't > publish TXT records will have their record be completely invisible > to consumers that can't query for the new record type. > > I respectfully request that the above requirements be replaced with: > > 1.Pushblishers SHOULD publish using the new SPF2 record type, > if they are able to do so. This seems acceptable to me. > 2. Regardless of whether they published using the SPF2 record > type, publishers MUST publish a TXT record. This is not acceptable. If somebody can publish SPF2 record, they MUST do it and MAY publish TXT record. > 2a.The contents of the SPF2 record and TXT record MUST be identical. Agreed. This is reasonable to avoid problems for those who requested both TXT and SPF2 records and got TXT first. > 3. Consumers SHOULD check for the new SPF2 record type, if they > are able to do so. I would be ok with SHOULD here, although I feel slightly better if it was MUST. > 4. Consumers who either cannot query for SPF2 records or who find > that a domain hasn't published any SPF2 records MUST query for > a TXT record. I remind that its optional for consumer to decide to use or not use MARID. record. So I do not believe that we should force them to query second time (just like they are not forced to do it the first time and do it by their own choice) for TXT if they dont want to and are willing to leave with consequences and consider the domain as if it did not publish MARID record. I don't think this would be norm though and I think most will for considered period of time will choose to query both SPF2 and TXT records. > 5. Consumers MAY do both lookups (3 and 4) in parallel. Agreed. > 6. If consumers receive records from both lookups, they SHOULD use > the SPF2 record and ignore the TXT record. Agreed. > Brief Discussion: > > It's undisputed that the world would be a better place if everyone uses > the new record type. However, it's also undisputed that many players > won't be able to publish and/or consume the new record type until new > software is installed. As such everybody should be encoraged to upgrade their software to be fully compliant with the specs (as well as for many other reasons it also good to regularly do os and major packages upgrades), but for those who did not they can still rely on TXT records for considerable time understanding however that they are not fully compliant and may possible loose some records the longer they continune to use non-ugpraded software. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 22:24: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 WAA08673 for ; Mon, 23 Aug 2004 22:24: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 i7O20K0Y059178; Mon, 23 Aug 2004 19:00: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 i7O20K1r059177; Mon, 23 Aug 2004 19:00:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O20JCH059171 for ; Mon, 23 Aug 2004 19:00:19 -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); Mon, 23 Aug 2004 19:00:25 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Aug 2004 19:00:25 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Aug 2004 19:00:25 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 19:00:16 -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="----_=_NextPart_001_01C4897E.19E3C3CC" Subject: DEPLOY: Microsoft Royalty Free Sender ID Patent License Date: Mon, 23 Aug 2004 19:00:25 -0700 Message-ID: Thread-Topic: DEPLOY: Microsoft Royalty Free Sender ID Patent License thread-index: AcSJfh9BKMwdBO4lSNOwyREUUU/66Q== From: "Harry Katz" To: "IETF MARID List" X-OriginalArrivalTime: 24 Aug 2004 02:00:16.0479 (UTC) FILETIME=[19CA4EF0:01C4897E] 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_01C4897E.19E3C3CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Over the last few weeks we have had discussions with a number of parties about our published Royalty Free Caller ID Patent License. As a result of those discussions and the merging of elements of SPF and Caller ID to form Sender ID, we have made a number of updates to the patent license. We are in the process of publishing this updated license on our web site at http://www.microsoft.com/mscorp/ip/standards. We expect the page to be live on or before September 15. =20 For the convenience of the working group, attached is the complete text of the license. =20 Let me add the usual disclaimer: I am not a lawyer and I can neither provide legal advice nor answer questions about the terms of the license. If you have questions about the license, I encourage you to do one or more of the following: - Read the Microsoft Royalty Free Sender ID Patent License FAQ which I am sending to the list in a separate post - Consult with your own attorney - Send questions to stdsreq@microsoft.com. Someone from our legal department will answer your questions. =20 Thank you. ------_=_NextPart_001_01C4897E.19E3C3CC Content-Type: application/octet-stream; name="SenderID_License-Agreement.pdf" Content-Description: SenderID_License-Agreement.pdf Content-Disposition: attachment; filename="SenderID_License-Agreement.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjIwMSAwIG9iajw8L0hbNjU2IDI3NV0vTGluZWFyaXplZCAxL0UgOTA5 NC9MIDQwMzU4L04gNS9PIDIwNC9UIDM2MjkwPj4NZW5kb2JqDSAgICAgICAgICAgICAgICAgICAg DQp4cmVmDQoyMDEgMTgNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTEwOCAwMDAwMCBuDQow MDAwMDAwNjU2IDAwMDAwIG4NCjAwMDAwMDEzNDUgMDAwMDAgbg0KMDAwMDAwMTYyNCAwMDAwMCBu DQowMDAwMDAyMDQyIDAwMDAwIG4NCjAwMDAwMDI1ODAgMDAwMDAgbg0KMDAwMDAwMjgwOCAwMDAw MCBuDQowMDAwMDAzMDMwIDAwMDAwIG4NCjAwMDAwMDMxMDcgMDAwMDAgbg0KMDAwMDAwMzg5MSAw MDAwMCBuDQowMDAwMDA0NjI1IDAwMDAwIG4NCjAwMDAwMDUzNzIgMDAwMDAgbg0KMDAwMDAwNjE0 NCAwMDAwMCBuDQowMDAwMDA2ODk3IDAwMDAwIG4NCjAwMDAwMDc2NDIgMDAwMDAgbg0KMDAwMDAw ODM5MyAwMDAwMCBuDQowMDAwMDAwOTMxIDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMjE5L1By ZXYgMzYyNzgvWFJlZlN0bSA5MzEvUm9vdCAyMDIgMCBSL0luZm8gMzYgMCBSL0lEWzxlMzViM2Y1 MzFkYjczYTQyNmUxOGJjMDZlN2Y5MTkyZT48NDU5NTkxZGM3MjAzM2Q0MWFkNGZkZjY1MDkyNjc4 MmE+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9GDQoyMDMgMCBvYmo8PC9MZW5ndGggMTg3L0ZpbHRl ci9GbGF0ZURlY29kZS9DIDE5NS9MIDE3OS9TIDEwNj4+c3RyZWFtDQp42mJgYGBiYGDRY2BhYGDj YuBlQABeBlYgZGHgOCzIcPCO4JSeUqCgjl9QA5BKPSJYmH7oI8drK48mvbexAq7PPZQOwzQau3R0 MDBkNDBwMLAlwHUCAR8DQ0w5hGaQA4soMfDwBzbINxziPqCt92iPzqRHOp+O61yazSHQwHPRk/mC HfMrbwbG9ewHGpgEGjkEpKA2KDAwVH1gADudwRpiWMEsCJ8rDEhzMbA+L19+9sqZBoAAAwAvlDAK DQplbmRzdHJlYW0NZW5kb2JqDTIxOCAwIG9iajw8L1NpemUgMjAxL0xlbmd0aCAyNy9GaWx0ZXIv RmxhdGVEZWNvZGUvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDMvUHJlZGljdG9yIDEyPj4vV1sxIDEg MV0vVHlwZS9YUmVmL0luZGV4WzM3IDE2NF0+PnN0cmVhbQ0KeNpiYpJjYGJgYBzFgwUzzh3J/gcI MABlaAKpDQplbmRzdHJlYW0NZW5kb2JqDTIwMiAwIG9iajw8L1BhZ2VzIDM0IDAgUi9UeXBlL0Nh dGFsb2cvUGFnZUxhYmVscyAzMiAwIFIvU3RydWN0VHJlZVJvb3QgMzcgMCBSL01ldGFkYXRhIDM1 IDAgUi9QaWVjZUluZm88PC9NYXJrZWRQREY8PC9MYXN0TW9kaWZpZWQoRDoyMDA0MDgyMzE4MjE0 MSk+Pj4+L0xhc3RNb2RpZmllZChEOjIwMDQwODIzMTgyMTQxKS9NYXJrSW5mbzw8L01hcmtlZCB0 cnVlL0xldHRlcnNwYWNlRmxhZ3MgMD4+Pj4NZW5kb2JqDTIwNCAwIG9iajw8L0NvbnRlbnRzWzIx MCAwIFIgMjExIDAgUiAyMTIgMCBSIDIxMyAwIFIgMjE0IDAgUiAyMTUgMCBSIDIxNiAwIFIgMjE3 IDAgUl0vVHlwZS9QYWdlL1BhcmVudCAzNCAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3 OTJdL0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDAgMjA1IDAgUi9U VDEgMjA2IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzAgMjA5IDAgUj4+ Pj4vU3RydWN0UGFyZW50cyAwPj4NZW5kb2JqDTIwNSAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGlu Zy9XaW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQvQXJpYWwtQm9sZE1UL0ZpcnN0Q2hhciAzMi9MYXN0 Q2hhciAxMjEvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAyMDcgMCBSL1dpZHRoc1sy NzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI3OCAzMzMgMjc4IDAgMCA1NTYgNTU2IDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCA3MjIgMCAwIDcyMiA2NjcgNjExIDAgMCAyNzggMCAwIDYxMSA4 MzMgMCAwIDY2NyAwIDcyMiA2NjcgNjExIDcyMiAwIDAgMCA2NjcgMCAwIDAgMCAwIDAgMCA1NTYg NjExIDU1NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3OCAyNzggMCAyNzggODg5IDYxMSA2MTEgNjEx IDYxMSAzODkgNTU2IDMzMyA2MTEgNTU2IDc3OCA1NTYgNTU2XT4+DWVuZG9iag0yMDYgMCBvYmo8 PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L0FyaWFsTVQvRmly c3RDaGFyIDMyL0xhc3RDaGFyIDE0OC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDIw OCAwIFIvV2lkdGhzWzI3OCAwIDM1NSAwIDAgODg5IDAgMTkxIDMzMyAzMzMgMCAwIDI3OCAzMzMg Mjc4IDI3OCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAw IDAgMCAwIDEwMTUgNjY3IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTAwIDY2NyA1 NTYgODMzIDcyMiA3NzggNjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYx MSAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIyMiAyMjIgNTAw IDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2IDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAg NTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyMjIgMzMz IDMzM10+Pg1lbmRvYmoNMjA3IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFst NjI4IC0zNzYgMjAwMCAxMDEwXS9Gb250TmFtZS9BcmlhbC1Cb2xkTVQvRmxhZ3MgMzIvU3RlbVYg MTM4L0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvQXNjZW50IDkwNS9EZXNjZW50IC0yMTEvSXRh bGljQW5nbGUgMC9Gb250RmFtaWx5KEFyaWFsKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdo dCA3MDA+Pg1lbmRvYmoNMjA4IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFst NjY1IC0zMjUgMjAwMCAxMDA2XS9Gb250TmFtZS9BcmlhbE1UL0ZsYWdzIDMyL1N0ZW1WIDg4L0Nh cEhlaWdodCA3MTgvWEhlaWdodCA1MTUvQXNjZW50IDkwNS9EZXNjZW50IC0yMTEvSXRhbGljQW5n bGUgMC9Gb250RmFtaWx5KEFyaWFsKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDA+ Pg1lbmRvYmoNMjA5IDAgb2JqPDwvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2UvT1AgZmFsc2UvU00g MC4wMi9vcCBmYWxzZS9PUE0gMT4+DWVuZG9iag0yMTAgMCBvYmo8PC9MZW5ndGggNzE0L0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiXyUXWvbMBSG7/0rDr2SoFYs+SuGUlg/NjoWKKtvSrML x1Ycba4dbKUl+/U7R07qrCuDBCuS9Z7nfXWU2T1cXMwW13c3EMDl5dXNNXgB1J4EA97sywOOB+8q 92Z5HoCEfO35gQiCIIa8BBqpFPJX3Av5ADKg52/8lfcgFT4DeshEiSzOsgzSYC7mYZbhnmfviX3v uB+zfdFY7qdsz6VkPvcV+9xzP2Faw4NuK90Dwt0XVrcWvplSt4OGT3Wv9TPN8B/5V+82924XSD6b 3MijmxFejvCBwyZiifAHQjeKU5GgLwlJFjjahBgZ8PznR/LqY3mKRkoq4mJS8f9LJamIwkOpJ5Zv zAD44QkroNF10fCUQUFWecyc2yVbKhWO7nERp86WnDastH2lt3QLdqPB4GJbGRfOeGBqglIEpWKh gjChMCqs/WKqXdFAhxI9HQGQWMt9yayxexhM3Zq2hhWVoNmmez3APHY7nMRRtOTnjr2tYGHKnrQG 7oesW1s+Z3ACE7/ByEwSjX/E8aWQUZjKkeq667cHpJAV1nQtFj17L04RLFnZNQ1Bl9a86GbvYiC+ +6K3Rh9fHzkF3K3h0QEFUy6RyyUSURTKYy7dDl4LDN520FDvkY522lscFvi1XNE5QG/qjR2gW6/R rMuo1xWs9pgFHsbfxKdZRBPAmMQBwCVBN4Uwdu4eWGqQw+EnVPQcto0uEGgwOFG3QNn3+kQ9mZKe u16cCxXL+GjP7vqxYaYLhU4XpIbEA6IKoLY8UcwmxbG7ExGpGKcPkkCb0WiErdtSHATewUpDUZZ6 azGUrsXzGdN/15px5jIII5GkSfIuhG5Etbqn3h9g0BbWXW83YGiFYnYBOzMUEPkRPGN02uWmaGua HaDop9r/XFYVijRLInW0o+G5qDQ5eEuf7gBJn5M0EY0mcdWtvXS/dCX++WOCPwIMAGNHZkoNCmVu ZHN0cmVhbQ1lbmRvYmoNMjExIDAgb2JqPDwvTGVuZ3RoIDY2NC9GaWx0ZXIvRmxhdGVEZWNvZGU+ PnN0cmVhbQ0KSIl8U01vm0AQvfMr5ghSIGB7watEkZqPQ6pGqmqkHpIeCCz2prCLdtd18+87s9g1 aZ1c1uNlePPmvcfl5fnDzf0tzOHq6vr2BoLrMjgvywwyKNsgTpM0TTOsa0ih3EGGFzMs033FioRx vmSQpzxZLNOMQdkH4be7m/vy05dVVL4Ed2Vw94DA2JoTGLZiVXDOYbFMeE5XaVJknBdgRNAG51/h cs9qcZJVSnT+ZZKlecLykQeCLz0PmBKY4LLTuMdl/eIz9s7KuX/GlizhbD/qMfy+ERELTRTPQlFh Zc/gQdZGW9062FQWGnr+S3R6EA1UEOWhHfBG1LKVdeWkVmOLrY18ltGP8vPIaDYhxInRjCU5X+Tk SIODFSKtoRb4Y1yFp4yyUEHlHOJsnbDQRjzUBkQne0ndOEytcRK4jQA7aN3KEQSbjnPZca4fGx/m xlmSLdAtP73VZo1ooFvEJw41KeCMVjIqwhr6SnZArJrG0GMbLULri4tx1gl78pP2vG8ESxOO2cuP RuR/jcjfGrGTdoN3KAqeToNQtcZqa6hzLeh2JxsxmoMoHgHt8lTj/xIyJ2Eew0YP5N8ZyH7ocG3R C+VGSykKqgHxe4IwnyAQGkE4oazEWfgKna33ZiVUIwygJB/NH69T/taY1TBNFmI+hY1AoyliTRRn ITxjFvHPjpR6igDV2IhugI46KB6UIyf7ymFIhPookDP85nCpfSAbEvhggYXhUGq3z8c8dLSeNNBo zAcKpkBVPQlnoVJecSPova0PNG2ALlaoozePJB4+luRAyUsyL7KRmUFJ6F2J9kRL5NaTAEaAaFtR O4lf5yug/crJ9tXPa2Xn0IGXrfoJpEtMi4ycO5Tnwje9l+NikmP4I8AAwJVhLA0KZW5kc3RyZWFt DWVuZG9iag0yMTIgMCBvYmo8PC9MZW5ndGggNjc3L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFt DQpIiYRU24rbMBB9z1fMow1rxbJsyYZloXsptLCwsIaltPvgteVGW19SWyHk7zsj5+I2WUrAlpzR nDNnzmiZ5xw45PUiCFkYhhHkJbhlhMstcFxGEOJvWiWKJVkmBCRhzOI05BLydvHde1lpP/EGP4g8 XeBqvIJvPb43sC06CwWsC0sRnR9wz0JjSt1RmIZ6oLjW5x48mtJtRj8QXl9bsD34r/nXPbf4xI2o RYJlMuZILa+QgWnXjW5nGHal4Vl3lSMGX+7hea1Ll+7fbCl3pQosLUqP+WpTFtb0vsSE0rvyhQdF V8EWK5XHSqU3YqGbiWZ4ShlTxkCgWonMIOCMx5maEm/2lEZLQmHGw6v8RZL028ZXnqYaKtz+1FhI MVdsJMla6O0Kty5uwJCZTpyfeAinVMwUSnWsbKiCNZ4t3FlriM0IbbGDohl7eNNABerfGzPoinpg WmTk1O0mWWdgYgbGnY7BAc5VLRSfUM9acRC4YzAlfMgXD493sFg+wfX18vEO41K4ubm9x2+3+WJ5 tOqHpoxxlZ1MyRnc69p0hlCcr+YwMmWK1MJTknGVZRnEksmUPoVMRTDoRT0nk10k45oeXpoVzhMm 0okUpk+JlAd+/n6pUh5ezD6JrLKjyFTbR2OpIBY4lckBC/WHH1EkPtW1aQwN4AxbKYY9ikXEpAR8 qoQUuFg49vVjbmduO5chZPEk9J5dNrUHqcXQ6sK1BmdrB6fpNXY3+d6MUKEPS9vsoB/AUPD0YWbC s1srYzxT8mB4PFr2nfVTb+ibhkAqeNtdAU3igH+1bd+R5ykII2Br7IrAiAAe+r/dY4ku/9vu+1zj NC94TWze3gm5pLvNwlMx2B0DP5DeZ0Rab2gy1sfLz40k3Th9jQlIg72P/Vf4I8AAI0lr2A0KZW5k c3RyZWFtDWVuZG9iag0yMTMgMCBvYmo8PC9MZW5ndGggNzAyL0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpIiXxUS2+bQBC+8yvmUgkOrNldMKBGOeRxSNRIPXCreyCw2NsaFsG6qf99ZxaMSRXl YgaE53uyxbMXsSiKBBQVhDSKJIfiDYRkaSwSDhEUtffDNx1UJtj6nR3MEVqFY9mNUOsg9Qe6qyyY Aei2q/Xy5K2jaRgPugfT0Bv2oCD4WTx74f/AgnDDBTjkjMd5OsEPen+wYA2ov2qoNO4cFez8Mkj8 XQB7vAxBKHxVWuXm2EegsoNGN/bs4Bya5Fe4lOD4lkUivoiEHperzuLmBCGiL7jbNEHuO9bmZEdb dk5yt4fxQB44pWMQSv8zVTxjkvMFx1z4wkh0q9OgraZpWoQMSKENhH9UNan+Y6yCxgQhmj3hRFeE 2PkmYyZlIt/bRrTVUVVWE2QXhNwHmhpcDRRTZRcuI1xpkSbd6iP5O0BbdjTsNaouT/aAs6FVyPpM qa6Ex1darkUxS/MoXlpEfMbT6y+nOpC+dVrt+Ss1Y+e/UpbDal2yrOM5d0ZyluRZdtm35E22ucCR uct8HaXL8ZMShHLLZJaLuXMy5XNMzZT7usS6s2rK3IK79tcGkJYOb/bub66yKy1rWO7EiAjFiEUM Bd2WvxXUamo47ZyCGyl8imIyEEf0EL8vfGsykMEk8LHwHl/uwdt8h5ubzcv90wNwAbe3dw/48K7w NkXBAcGbmRRfkZLOYBwFMormKUnZNoq2W5DbmOUZFC0y5UzATgj5TaPFVFtV4y88tf1RtUiotPSN uI5072iluC3GVZLxNM9zjBMNz5AGRCwVaKjXvKMuP6TumKcLcck/Is6zjGWcQBxzhJvJI/H4coCR y2DocjyjtwYPlbEnUysS0GBDdQW9GfD7md91p8GHXyBPmYiT5JLm2ZwG6AeKrSYjTq7ymKgdqalU TI211OgZQjnbAA8XKOfzi05J+CfAACpkclYNCmVuZHN0cmVhbQ1lbmRvYmoNMjE0IDAgb2JqPDwv TGVuZ3RoIDY4My9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIl8VMtu2zAQvPsr9igBESNS D0pAkEMehxQNECC6FHUPCkXFaiVSlam4/vvuSn7EbtKLsTLJ3dmZ2S2+LEIWhiHnUCgIopBFMRc5 BJzxOJdQVIvvnrJd3za+9ErjYNM4P/dWfsA9KNsWBv17pLNBV+CnXm8H11jjJ976ApZe0yx9oOPO 517f6k7jiaHHDvwfBVanukIwniUph3AuWNL7CrpyC41R7Vjhp4bSbMH2lL3E7xbelQJbg1tpeNam ogoDPNzN+YND7qmlSPK5xHOvVVM3qqQUF36GzZhqD5jyD34gsOjLPsRjQlERAatd7vfUUSwiKDbA JROJTI7d4DtwQ1np7pD4F1gMNxQaPTVrB1DWuMG2LRZ52cI3O7K5zn2xuH+8hcXlE1xdXT7eYm88 huvrmzv886ZYXBYFB0RRz1qmBzxRyCdAGAtEE+6iRLIU70mIeMZimecZFB0C5SyCpRDR10Zpg1qu dYW/8DTYasRAuRM0ErPEmCJlKabIAb9FBiGTAj2xqE/QJp+jjY/sZR+i5UnMcnGOFXHGgG5KUZg1 lNBjNDFrCfOoyKTwMpBq6V41aqY8KJHulcDIbsx8DVWgTi19Oj/yTuSg925Vup0pqTiVPvp4biOm LoKcSS7S00EiYsn/SCw8dD25GMcCh8K42YdUXCNSPeBs4RGZxOjJKxPY2XwWL0wmp8GcBgATrP9j lvRD+oNz/j/xSpIjfpFFLEGzS6IfnRJPTrmva61c86bhrnTaL36euQMlZZJmBFLxuTvkx+44Y/Qf X0Q5+WIHLMzf+wIXji7nzUBC4maoEN8snls1qNorEaiJRtpMmu66C6jHtt2C/qOVH6CL3EH6iXg7 umkJqRXeplE2r3pedJhxoFBp2nVvaBzahscdMZEMfwUYAPBcYdINCmVuZHN0cmVhbQ1lbmRvYmoN MjE1IDAgb2JqPDwvTGVuZ3RoIDY3NS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImklE1v nDAQhu/8irkVpOJg861GkZqPQyulilR6anLwgtEiAV5hE7T/vjMmpJt200sVEc0azPvMO68JIxZF AqoFwoIJnqYQcsaTMoeq8X76uyPcd/Wkg9Q3QRj7urVwmCczS1wZg5D7FqyG76q2nR4hYzHs8I6i O32Q+ZqKhUHwVH317irv7v4GvIsHuLy8uL/5cgu8gKur61tcvK68i6riwKFqPYKKOJY1hA4wJUKO pYAI/9YqzVkWRVkKIilYgmUC1YDQnKXwKER8Nzbwwyjkmd7o57gvwU0Zy9KyLCHhLIeI5QIm5bVv 8Mr38cQJXXkOj/OSxckGx1c25EpgUBK9GQ1IsPsuyJEvFH4DB1qe7BHq2ViN9RBwX03k8LInNwfA /xJqfTiCbldXz3slBONFmnGkcYPUE9DIahpirYyhd0o4TLqZadkCPrBa9UxA7jkFnYHe/VTjlgB6 psGLNqz6TlkU2Gse8zU+cc5fZO1eTUtnFEnhrucg9rtGNdCSnpPeY7f0cquHdVRoxYdNDfQywvyq /fGk5fik5dy1zFkhMlFuLcsRzWrwglFbJ9jOE/KQx6i963836qahqKWmMzYo/anbzZhoWseLIfW7 ERbR+xnJXhFjCsDZCGME8wzhY5YUEY+3CGcuwt8IrSZLqDBB4huXkSPc9LIbsAFzLtoc9+cU7SJi aXE+24L/T7ZT/FqIjToqT8ONUMp5b6B+hXSzxLWWrMTgSatGF7qXSh4OL/OIfWn/MWU8VBkmbRsy fXXsXlp49OVj4I7HpJzSQq6NZFvjsoo+6tFOuu8xfvhdcyfJCYV/KXE3rFCgVp5lf4b6QdIZxXd2 1sDntu36DpswGDMM6kI3kEeOR8ybnZHGdoP6hAsNQu6CJ/glwAC5a1lbDQplbmRzdHJlYW0NZW5k b2JqDTIxNiAwIG9iajw8L0xlbmd0aCA2ODEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJ fFRLj9owEL7vr5ijI5EoD5JAe2wv7WFVabmVHkwyAVfBprYB5d93xknYoK0qoZHB1sz3GnbfX9Ik TdMig10DMZ/zGnZ3yItkXdUZpLBrX36KfQRRJaRF0EiHhotzkqqN4lyoqBZ9lIkBlO6s0kds4UCX Q1QIUOdLj2fUnl/pI/gTwhvqlntY+PYVol+7CUb+jqLcMox4xhFnSbbe1iOatws2qlON9MroVbQV cD+hRaVBQtPTFKnOoNwDa+j/3nrNnbMqKTfV5sGQ2FjVPwhEpcAozkRLBzCaLmiEBuVDX+PhYujG OeZ06JFfeQPyZlQ7t6APvz/wZSOpXB0uuH6QPH5AeiLrmVqYSmQMeGxOmqc2sidUlilKZ7Q8MHHy x/C7WHHtSP4Ziex9EFwHBGFsmi0gFJPr26zKR00EyXtD6IxdWDj5F+1+Tz0WluVB1yyp06qaZR2N Lkejn3xLFlqU701G24syqfJ8MypRkP+h2avxd+VPnD1OnZdMsl3EirDikWWafnNMWXvUIQcreF2G 1w7wZQzLPwOSr5N6W61nImcHrSEPSmE4F5QD3fRX+toiSD08cuc+wV6ocV8Me0fApKZi2H0ajH4k Hs8DntwmBv4E8mBIedbtRhZy7jpojPZSMQDkiAW+Tp7ZdAYEF0k8PUjHU15xin38IWtsOrErk3xd lsv0BzkqlqMitp+ZBvMg+H5FABbtPnieJkVVFnMz6FWDDNRhu4I7L8q1bymqf/jEYBUlWk4ysNVZ Wm+fdbjIgfMGpgPLDQbKr0IHFEZSdd5OCx3iXjiCeRj+y5d2a5NuHm7S9B/S+oGX9qpl16lekX4t sVW2hQsNkGEADx2lYFlYDhPsRl644MaR9Q5bOWejN0fF3lFI6e+Pb0lCYgt/BRgAgK59vA0KZW5k c3RyZWFtDWVuZG9iag0yMTcgMCBvYmo8PC9MZW5ndGggNjMxL0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpIiXyUTY+bMBCG7/kVczRSgvgIkGiP3T20Uk+bW9ODYwZwCxjZzq74953BCsv2sAeE sT1fzzvD5cfukMRJkhRwUbAs03MKl3c4pGV8Sk5HWsTpMa9os979EoOc4YYwosKoEC465MJJO4M3 MMi/CMbC3SHIcYbJmpru3JUHQ2/Ld2Fall5Hvy+P0Mc1dMaBszw+FWV2hiRENCP4Di2aht7Sgx6m HgeOPtLjo0w48Bt32Ye7xV+axXlZ5A93HcIrjjXbW/j+DK8TKt1oJSmnkoMFV3kZZ1lahurPVbC9 CozbeA84yluvOXwLDgc2VIY/6+iQijstFBfrCcYgOdF7I9fNu9VjC54TUB0bGTbqOXg770GZYdJ9 SM8j3TDrkbn9wdUNkdY4Lm6WqOHy6o4NopMI1fzPpTgzmOSjuGfmPKElCJSbm6OzcB6HNYGKvJaC cyBRvVHLltvTNd5o6czKgThUpAndA02J2eYLUTLCm+dF+lBFKnR7IFv0Kr5GT3AV+u0aEY03DLxI Nz1QgIlxkP6jp2RJLtNwmYZbZFNsmm6qXdp5jfi5n6c7KcnFMNQOa87BTYRx7YpF2OUYuJ2R8b5h T7gYPWDv8L3jA0ttz2LXYLFBa8mZNxsG+SandJmxrIqTqjo9IBC2pc6bqWdY2n3bq9GhEJ/71YxP XDuxYlQfxW8G6hRmOQSqzp/bOcBl0doFIMsISvZ9WOma36NfowE3AY1xJmi+PRse+INwlUIOMPB1 1Uk20o61uoovxryM8yJfx9JRBcauY2F6/k+0zHqG906rDrSD0XiaNw9N+Il0D2AEibV4dMDLZffy 8xvs4J8AAwBTplVxDQplbmRzdHJlYW0NZW5kb2JqDTEgMCBvYmo8PC9Bbm5vdHMgMiAwIFIvQ29u dGVudHMgMyAwIFIvVHlwZS9QYWdlL1BhcmVudCAzNCAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAw IDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9D UzAgMjIgMCBSPj4vRm9udDw8L1RUMiAyMyAwIFIvVFQ0IDIwNSAwIFIvVFQwIDIwNiAwIFIvVFQx IDI0IDAgUi9UVDMgMTcgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAy MDkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDE+Pg1lbmRvYmoNMiAwIG9ialsyNSAwIFIgMTQgMCBS IDE1IDAgUl0NZW5kb2JqDTMgMCBvYmo8PC9MZW5ndGggNDg0MC9GaWx0ZXIvRmxhdGVEZWNvZGU+ PnN0cmVhbQ0KSImkV8uO28gV3esrCrOiAKmaxTcbgwE8tjGYIA6MtLII0lmwyVKLHopUSKpl5etz 7i0+1ZJmkFm4TfFxn+eee+rhq/jxx4cvH3/9JGzx008/f/ooFrZ4XSiRi8XDL0+4bhY/bxYPm40t lNhsF2tb2ratcJ0KvnZcsTnha7FphLLp///i16bGD2k7uLS7Kz+UAX0qQvwOA7ra7Bf/suD76aDT fJunSZtX5UpUtXi23vLnpVgGVlq9LWNLL9fKqvPyVeT75b83f+nicCdxUEwnoXzpqZj8bjIYPxR6 DyO6bNm20N+TpW/tcfvZaoyDRrdiW+Fu3e5EXop2Yj8YzKuIrQew7qq4N7/T4kmX+DbTtTCJ4Ee6 XHsW8qHo6XJMi5yXlMpZ3M1i7SoZuQ4erJVUXhwad/uk1XWeFKLdJS3Fvte1Ls4iL4ojLDdtjRca PNWi1v855uzjnYuQMwkpE0f1mdR6r2GwbBtRbdkCEsvoVj0N1RvNsBVbKt8PeyOXrZTLyDJff94s Pn8BuB5GwKkecFfw5Yxuej/vsaQAvSD0ZRjR+wQlJZEbQn92HPd6X9yxL67pyyy8GHYjQmYQujIO 4ziCQ0/68C1DB2VEXRfbaRbO1SzsMX7vWvyO7UjHBA8noYn+B7GnKBOK2zQxJVjuX3K6Y/Db9aYx VV6GSGRszrupRJMBIneAq0kY1il7YeYibwudccW+HusDHlY8ai1u/l03B/N+/lLo30ds6Hv+HLAf sqzW7NBFShiuz+t9khfii24amoVX/OPRbn5YiW0OJ2XCRRBZnWzbda7bLb6g4cyz9SSAS4A4ngwx rgOcKZF6uXasZG3bsv3ersRyHaC2mSioqMAnEiTD7dKxuKbbqiiqEyiG3Bd5+ZtAvT8cX81kddkP fpCm68QuebMcd4WO2t5KHOtiufm2ePgI5kwbbrgtfVvFvhBNWi4GSKQU6En40veDrj3Wo6Bvh0l5 OiTlADP3zrCYZlxCTKlIhh5j2bdl7DGZEcx2bXt4fHg4nU4S5cWEbmVVvz7kJbil7PvRrtEx9GBS cp+9uNINwYB9nbdt85BRrU23qJ7UMHQLl2uC2aGGpYTM2bhlk3H0Az/b2eRNwvViIIiuHIx56NMQ 3po+b7q0/g8eccNA+pcFEoQSQgQhppkxh6G12eRwFvCrJpPPvVWdI7CVHUksjSiee7LEvOFjWv6d bvvjSorVTW7kQroRnHXcwmxOXPgoKPwPRySIFCghavprN5n9GFLqNIqP80Hs++piLdd6bbtmtAD7 R1OHCfCVgfxYENeTylZhD/c7aA/Gtl4M0JWCBNfQ74Fg8WRagjnuR9AbpnCtUrfrGSQHG6GMgMJY 7Be+o6QfEa7Gu8XFXYPdYvp5f2t7kWd4u8/KvjrVY3MdLHBeUJwcd6khsfEwZ85BAZjlEM329TCm DhDudsyv+ZZncXPfzekkAF8GIRVAeSAFj2ZU0S67nNHo9oZ8vxZpPOa5WZIZdRiwcawcRBhevHxr ouL3RPHOHlKjhqJlCkj1u71806Sy/6yAoTL6cTD6IgUT9eqFWsMTO6t/iA89fOVJl9Hn+QSyW/yo rous35MnynFozb0Pr5d3LDw6BUWSVvw1Twk3ZaP1nNaBEi8wlvqQ41j6PBA3o74uqv5YZR3Hv4wa BfWMWu60VVKehe6lOHj83AlqkN72WEBQ05X+rtNja9SLRxIhb5g5X2uNM0VIG0CcSEu2u+rYin2V TRbEXamEU0RoB34810q0dWrdHuvSiL/Of2acXi7i2QZwpO9G0SDzOEBeUaKtxJc8raum2rbythS/ Li9+DybdwKC3ARKJbNUtUEcyHgalqcUvTLI4CeF8MQsiiHqg+bF0I0hiyKq72PBuhXoFxm7AYXbR qfvjfG/phmPJIdduzrOPPED3QdA7c6QSXyE10QmuSKOn3kNPOhG+8LtNEgQUp0n+KpWq4M8IA2wh 6bEjDnI61ceXb4PMYdA86ZSB7EiP5DBh85/VsRav/bYcTrItnUkKkxy6rXw+WEDqJyk0QsYTl2pM SrvrrDJhOBKimaHJKHEsANTg8xJ160g6Qex20wL1OY5LjtPqhy0ES87n3h3vcv1y7sN0pmEifpGI g+ZDjhG5x6RYibIq9fdlbKXFscnf7p0xfBkH3iB99UrU1Tkp2vN6i4kjQ+SsrZMB+FtdUwA4PLEb WqzN8aUYDqADBzU6eSloZFf9OaPzNWMIxN6wlYS+Qegn8lgX2Yn3uDZtIOdaHCH36OGkxnCIIoMM nUb8Tad0BKvPU6ryxoS7fF0vHLX+xyLJiVfM6REg2Se/IeDjMOYrQZntD1UNTVhtkT291egCodJf YbrhWxnFL+5R2npwPqtAljdtnb/AxJEbqEWWs2BJW7B2VeOISTf4F1x/Bkb+0aBqCOfl21V0ObaM 6LJvatoSfFOqWKbFG76lZcfKaGiroKdbOjfOaS4Tv9JiOBR6j4nvd+P4VYmokkaMmmy6G0KTdhfO HOt5iYACqz7wX8Y1FlNgYQJKpMnLN6Dly8via11lR0oC05HQ/Qx/RFMVGv63KBK2C905HOtJC9Qk FrdrP4RtX5hDZXCFYU+rElb2VJfylQYbZ8gdd5QPTfdWHzaVFw57is8kDFJwW6cszAKV4vauui6a /8CuAkEHrvCwctQonB3piCcwGyjqY4WOf6K05iBDPHMJxrTtga3dkDhUKSWdQdC8J+3rAvhG1d+R doQ2KFZ6XeBxR9rMZ0VTiV3PCG9agF6+kTZJWzN6PBodkRM2DJHf71Esg9gL+iYde8YXr/V10r/N 98aPC98BijQf5XHDuKvVdWLGz6pc9+Tcz1H+9o55L085Jh2fUezS0SzqszE25xxNCRL9hpah6Y6j Qz4TIcORN5QL8R0EgzU9fHaFmmt6RNSsJ/FNKDYyRIdV7Dihry5G3lB5QCOHRmYDKqEIxcACojKj XJ/4udFa5t2UvFf4uqmO/etoC/MI8YG+zoYupEjgDBOK9w9kDk1Gw5tjugPZUGU6sU9rB6Q3Mh45 LRkZ42ojlqL37pHNevB8AyRKVL1FsFi+Zfg/W/nzUhzqas8eEEJxJlrGmjgUyZn5aFsVBX16ykFW 3H4z1CiGCSvBYqI09UjUlCrBeEfVI2rglZD18FyxHoJzSvd5yZ2402J7zOnTZIcFFveyFtSOfKkm PaO4G+oUOzc907Q/8PzMq73GxBQD7d8XLYFnh87QUT7p4ChzIL2RcJ/MOsYIp8WgFDhnVPZ7vufz UTUWkw89KOaY8sSpH/fr27ido7qsuPBmK4mMEgO0cJd6EdCUMzb5gEbYxq5ifO8bE3fSQxnNo/WT 3qcyRKFcLIx++Ju8ly+tOb21uxV14FQdi6xLeEfvvORQMJOECSivXCWTwePt9RTP2d7p1hMFGAzx ufZVhW4OVK4v3CiUSsXReIB1Nzue6wkuOlBSvUh2AO+kE+YigQQClJdZCWBVcegfVnSl6xbker6j AbHr4ngUvaI6lRhoWo5nnhUYGQ6Y2KDw/j/Gy6U5cSOKwvv8Ci1xyqiQhARauuKZqlTlVYmzm40M LawEIyIJz/Dvc8693S3JgDwbDBj14z7O+W5TdBN6DAldJKkXGDsNuKI8iGFJJwqcouxun43SmSRp MpYMQVQKEq+HJHdAE9w++PnT0+dAiMPhhht4BtTxMERootIHgLRKstRdxUmGFAuD7iNuZxFeFT6B bvJqLUT8JvNUtbejQlBCz/CDoI9rH8+LEpq7U4wbTfAfmQaNsM3pTfjD1YuDgONBvplDjDZNxe2q Q9HVDLlpXqXQZFNUcDLJKzG2zSNPC2r76O46KI1VVHQNItmwLGnalWnd0sPmuNAQUNUyTr1wAQl/ xwCqTYpXiVrVWseBZHcvVTvSa0X4PnYATx88W0BxmEXZ+v2QUTNmTpZElE9bG7hz0Buz/Ag3s/+o 2UqUrIZn2r2AvlG+Z9jUVBFJqmgssg66atxR2r4XlaSkZD915zD4uZSdZCAULbutzU8/Cl78a6yF WMrA66jwnFLWJa7Vwe1MuAtRTs+NVhAYzNDKrnMEiDhP/FSl3IKjqVney1nFsaElHc/MoaIrXEd2 g9ofDHghBg1I4fIuWkB45tnspgrHi7EKR35I4AyiiutmAvRREq/CdW7RGqs+/XN10Wi86HLYGKt+ gs3y2wMIN4vScL2UnT6jejb7ovEKdK9V/LAD1pKo5Ci3JgUMBmsWrw0ynaBGb6UzrdzXY61pRb4Q q/NdhNTWINudbAWcEIbqmGnk8r8TAi2e11A5NxWI6NAJ901IsD/EqIOwbqOt6JAJ+UULVZ4UKZE4 RCssW4oUWrpkQV4rKQisW2w7Qk4RMum1YiPucex4awmkdmd/e0GKCVp6h2rMAzfVVGSzr9g9J6st sbyrUV6gCwO58ydQzd+taeRErwWdR3c+TXNKYickZyWaCATDXVmbdHhxH0EH2wraWkAfofZgHvOW 0QprU7uB2zFDh9VaC+D4mgwOn+a+Qrw4Ie4WaSc2ZmOqN37UdLNrN1McALDAaJv5K+91LdlVH7bf UJSkULkNE7BmAnCIFxlsusB8UyeH8HVk/PcBGMg+fEoC4PYeFa1vOjgNFn7qGxGyIwWArXGAOJ1V GBmeoZ9vVKJiuNeFCqwx1iwSjzt78WDWKpY4Fg3dcLgwtuLFOgw15p/TFqkNb4tcPNajxcBNL7nr lhzBYuGzUhtEzThMgj8loBV8dgPX+aMQWP7Fl9noPCsA4hqLLMIMbh5l/LQIAf6N+aEcnTa5etrv VM8oX4Rp5g67yPWwrIv7QMvz2bwU+5JyBXNpWoP3nNL4IXi4m+ezsqz2Fe7S3gdQAfN8Dnawsk4Y c2C5OtxNaMQcCBtneTqunsJKhVQ/lsTaMq+yW+KZy7gKkFAo3duC6MbrP6Lc90zabywxieMwjxYe iCCUrVEIOR21b6niMlLxFsFRCPBouqlmiJbhYhl5Hgdm3MM+ePS5+YZ5TBFuOaveDBy/JsCd55Py kmRhnsbvmqtEH3HhQ9cI5ghalKaxzCv/wtt5e4JBgUEEA6TeGNDWoG04w9yDcJo9eYn9MquEnIbM zvO64Ioi/wZh0lnip30hoKvgjYS8Fv+aCW9bDPTxUQYLkV53JrWeVsnTIKe6s80pz7WpxNtwTJtc O8IS2yaEMYFiZLHPiAmEZLF5JRWlY6satfmPqsfTMGYCgzCBI3/fiDGmgzEDVf2KGbHYt6Oh6tKN 5v4I48HqoOUgKAzc5TQjgcBGhFO3q4hEH5aDPHJl5iKji5xrcL7IlGt/7zpJHlPP03FOfksG/HJ3 r8BMgAxOLUoDCcLnWp5DA3y/zdclKpHLQDVQ/nwVEdjyjG0HenVh7syQR3u3cl9MjovxiIkpO3A0 RwxQpZEs8NIA7wHkuFzyTPXeYDcOqAzyB9nUfd/b/fHU+HChcZAvqbMDFn2VEXYnUsZiI1LaZEom YVKPchSrXZrJRBLJJSYsa3nbsi4HwEvLSvMc1J3mYa4PqGMtg0dT6hwjtfVG4Qv+OrVH/VKp5opt Rek6jMQF8zxMl3xz3bvSCe/KekVdX7WuFdop4nBhDx5Z88LM1o85daOofmYmKnD3A/2KFWI9q26U gnyuBwUWJZY1louV9YeZoK+sJjr4oPbXzxO9u0S5FMo6zHlM+7jsWWAiKKum7QDnEBbW28RAMk+4 xHrxTvqPyg/VoWyAZ66zBam151lasv5RtLE7a39PSDMwY5XhBraV2J7nu0SLVC32D6DVWXwefSbK xP9rQGRy9CF24T0Efvzc1CccziqYnsLtOO6h1+JwKvup9dRAhUSK2oKeprrCqOnniiJ2rJvODmBy LPZRbTHBTyc3rCENs3WceQLYVq2orla9rtkER102ntWvdUdf4Nd6F0RZ1JWNTfhkpOOW0AHHdXTn fjCFQP4ko0wPpzIOo3KcX0UeGn9Ovik73dgJymNw8ej99MCUjqeHoGiDgheHS24KAQrcl47L+9jq wrtCzeEsTtgZKh3SL50HzZ8I/dzvOLrxgDx2LuxgSgh3Kw5SOFo427psKv7uRbykBeTXb9UWZzs5 l8Tw4hFFps8+ChcNG2fhMkp6dvNjKp3stHkJ8LHCXXmQls7Nrzy+VC77fReEwdPHbuI2HXcCitzs aqYOE1grUyICeqjBO8cjrKrSAhxqgfx2CFQ4ZNUJJPWJGJ5gZTM/wiMA4Wm/RXQRcwT4a4VUwLF3 O/JCw3tnvDdf9wU/4P8Y7OCg5Emc7LmQL7cfZf8KEQnSGY3tuwJzjWXLw9GsdlZf7NL36F3XKq5P /FEuTNHPrvb+9aiXCPyDdmKIO4dXcs9ga0pW2AHnrQ54aNOpO06iy9zvOro/ZkXBsFbqHHn25O5x nRXg+PUM+e/htd3UQsnBZIlH4Wq5TvvLyqN7O4padJExDik1HbUWy1fMC5L84GayVOzmHZb8L8AA 6puiHg0KZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250 QkJveFstNTE3IC0zMjUgMTA4MiA5OThdL0ZvbnROYW1lL0FyaWFsLUl0YWxpY01UL0ZsYWdzIDk2 L1N0ZW1WIDg1Ljg2MzAwNy9DYXBIZWlnaHQgNzE4L1hIZWlnaHQgNTE1L0FzY2VudCA5MDUvRGVz Y2VudCAtMjExL0l0YWxpY0FuZ2xlIC0xNS9Gb250RmFtaWx5KEFyaWFsKS9Gb250U3RyZXRjaC9O b3JtYWwvRm9udFdlaWdodCA0MDA+Pg1lbmRvYmoNNSAwIG9iajw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udEJCb3hbLTU2MCAtMzc2IDExNTcgMTAwMF0vRm9udE5hbWUvQXJpYWwtQm9sZEl0YWxp Y01UL0ZsYWdzIDk2L1N0ZW1WIDEzNS44Mzk5OTYvQ2FwSGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9B c2NlbnQgOTA1L0Rlc2NlbnQgLTIxMS9JdGFsaWNBbmdsZSAtMTUvRm9udEZhbWlseShBcmlhbCkv Rm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwPj4NZW5kb2JqDTYgMCBvYmo8PC9Bbm5v dHMgNyAwIFIvQ29udGVudHMgOCAwIFIvVHlwZS9QYWdlL1BhcmVudCAzNCAwIFIvUm90YXRlIDAv TWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlczw8L0Nv bG9yU3BhY2U8PC9DUzAgMjIgMCBSPj4vRm9udDw8L1RUMCAyMDYgMCBSPj4vUHJvY1NldFsvUERG L1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAyMDkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDU+Pg1lbmRv YmoNNyAwIG9ialsyNyAwIFJdDWVuZG9iag04IDAgb2JqPDwvTGVuZ3RoIDM4MzkvRmlsdGVyL0Zs YXRlRGVjb2RlPj5zdHJlYW0NCkiJrFfdc6J6En3PX9GPWhUJ30jVrVtFlEzYNZoVnNmpO/tAFBO2 FFwwM5P56/d08yGaaO2tu/OQAYT+OH36dP9uHum3324eRsGYVPr999vxiK5Uer7SKKWrm08hrsur 2+jqJopU0ihaX6mKqqoGLpc04GvdoegHPqaoJE3l/3/hLipwo6g6LtX6ynIUG59q5ODesfkq2l79 0dMVi+ZJ3+6VSfE93qd9p5dnlK9pnj6/7Ptur+z/K/rblR9d+Q+IzjEVfUiOOlRcy3Vtci3FNgkW dYRFRXK1vro5JKU1SR3lMHiXhKZxFqcha7aruPppwORtNlRwcCVl+Z4QevJzVyR9q1eWmzd6xkXR Hxi9GBdZf6D19smK0oz2L2lJ3rOkIxGYhwCGVQBDxVAtkwFcwVORMC7bvtZLsj3FBd8hxZL/L77D 6NObGKvycdzWnGbX6QwdU9cacxzpQ7os8jJfw1y2Qnz0NX9VqGNFP8Sks5GBqSrG0IWVgaZoputU tqY5xfz9Kt2neRZv2HaNSVzlr/eSBgr9GIqnN0q3u026jPlbygsS7Biyfb7D5S7Z8NN8/8I/FD9S Zgf/nChEdESHTq31D2t9mpTlflRpkBNsQhFsx1KcIX+wveoZCkVJse1H/2792UPFERbbjqG4Dr4h 3VAMF//OktD4ODCOSf0oGFdXtNoHgoEPR6Khbhwd8+YFjmsdjhtnEmdmG2RbuqJLRwnJ/Z/LZAeS lCSdue8Pe7TOi/0LvSRFwk2aXTeEFuon26StMXMLPyaEGidZmXT59b7rdEsZWoCtZulzcSBLSS9s mq/hNGuoBSJQsl6zw+U+/Z5wmBAM9ujjcfVsHO9rx++QsITYjd8jXkvkqLlkCAvcIq+7PKvSYf/l nn1JHzWsRTt903W9lLzRUA3raZosK1mIiwstpjuKOjSGDQBvNNoA9JhZvy1pnxPkJS3AfTyA9YJV h39cVkhwGE8M0SZ9lo5qwoJiVJ1j9NLsuVuEd7QYNDEIGIajVaG8ZivpQAoZVHaUkakYFdh17fmF RqLKF0YI8igQMn7EYDB+/YHT+58wRMRTqWyDnODhAI8TMM4Dqh5qOkYWB83bxm+d0E7omwnJvwGr 5eZVpA2gxRuRNhD5QKV3aqKbij0c2k0Bk0x6Bupn1+qXyRz71qck5mebVBSc0jWzBVEhJiYcnL3R UyEvLV84PjysStnJtjM1qtLV3o94LJXZ8mjK9tcNL2kdpxvGcPlaJMJocWaxsx8pu7OrxmPXxf6N LowqeLUc022Hy7eeoSLBVfzGqVK8Rk7iU6bWUiTje5/5yuxdJk3DPsnvMSJYgwzVtOtmax2Gmqs1 +Vaej7naVhmi3ZEeyEkGHVnlMqultisIBsLiJhNpifEatO0CxpAKw3SMNtk4wwjL1tJe2bNwh/Il UK2f0E4uchEuBvxYmvoDu8fypJydZdb/RdMtRxNNNypNNxUsWjveH4TqohXVuAY92lJ3zBtmMywt d9jq0zjFx+VywybSrTBZ5BcXX4TeBf/N9m9HybWD08JSZcqg0VUU0Lk0Oe0/OTl12EagknezsJ2d m84FjE8V5TzEpqM4ZrsbmopWk37XbkGNwskOx+K8oh8yyJiZYEaMP5e0WbOwaLTiAiLtkqKEoiY/ RSbZ9KuszeDdh6rM6nteLDWkYtpOY/8p4ZErMr7mqnI2tXwU5K3X6SYFc0uCn4tTfWAYiq3rpxMl ft2/5NIcvwQThqNSnJx7tMyvK0TELUSKA3mVXeAlF0Qxy35hh+RBkMl4ln0A3bjnbrN771X9ul5H OK39xwjhUUxPadZE047Lk0mSPzUzVqZupZXVVD6a/QjoAJVyfmUdfkjBj5dT1SYLDWNU+0tFNp2C qkJQL9akql5HddqDZeUavVptUaW8J3uJ1k7XetW45vnH1jDG+YiT/Of1Am8MW9Fsx3Yr4vRSmSgC cFI7xaIIfU+k/87tHa2Vo+n1lL9WjYKjgtjDzBaNCeudDwXQFeO8frp/rbcruE3bZhnR3AZuo4MO ENsV+Vb0HhTC4ObjUFruNnEV8/GShhW63p/BsopZbRQmR4HjWbVkcWY6HxcTHopL5tnurZmW5WG5 xAhl8/mq2ZD5nfjdxqt2GpApPEllscJoXFGwZZXacBNwo1TE5lWl6cBVWu7RrJrae3rFwgSWrWQl WfJC1q5uyWHB4MVH4Ik3ZX5pfYA6mJ3toXbkfOynOf1VBCv5wWuxvLzdNw6OeNVFC7stXxeMmSx4 iSzOleQ8V0cOefkgE+IeWtGgFi/Prwyai1a1zHYnbIUOlV1uDtjxAQNE+pluUyxc9apQxttmOTnm 0XnGa+pfXBlqziNup8t5k8ZBOJp4AcThATn78/AoBAcqNMRnjuJaPMptRxnKPH83zBHE+QhP0TuJ TzN1nE+q6OBmWEWHTe/ep9Cfjv05wQNgCh/9UXAXjLwomE3Jm47Jw9PJhIJp5E8m/ihaeBN6nM8e /Xn0lcb+JPiMzPy+3pv7485I0/QDZnINTg0V09C048WzBx83szlNgpE/DWHi9iv5QXTfil41DjVD wactHRDvo8cB1F8HUUje3V0wCbzI7w+sXniyBp+K1h+9aCbZz0Ag/C/2MHcinkZIhh4X83DhIbUp PyW83bFmH1IbSmZNeEfdEt0HiOrT3Pe59v40Im/uM3afgzE/GsvkxanNYD8hBSGuTfqC7GeLi8sB r/Cq24AR0Rc2MJ9LuABldgdcvtLfg+lYId8b3XNlW7z4hvHq1Ert1MpsDwnqyVRpAQ6rDbzi9QNy BD++eOzfAVxIKgr88JrGiyjAE7/rSnXcgyu7zsVBpzfJcICj2XQcMAFhhLmA6vj/fJz7Ie6Dh8dJ 0B+YoBz+jAnFv7T8DRrzx2tUGHnRIuLaz3kWfAVw11z1YDqaLPoml0bvBVNcfWKBuV1ENJ1FIClX MohAU3x84ZCl69XyVidVRY2vjgoFkLhUD/58BI7de8I07xYYR1+vL9KtMX9UnrsgmgIiugMknrRH MFpMPDAb3hZz/jsL/euLdYc+DE3TaJkVRBNfis1lmc6mg2B6Nw+mn3ym84XFTNMvaNVpOh8fDpCe YQxFrmRf61kKTVjl6/1xjbv4CWsaDkqdA0p7TjKwGlWS6sKqfUZTjT95QtKsKiS3DW548ZAEWM8D 0WkF6zwQ0G0DZxijki74eghG81k4u4ukm4+kL6TwnruRyXrrdzbHqu16eOkWFRWKQCHG3oP3CR95 8yBEVeluPnuQjjq/cZ5s9HN/4kk7QFRmMm8b1UPv+EKTa+kqtNFizO0DN9JY42DuX9QFS9F0qz1X jUSc4UDM4SZAv45h3ptcE9+Ld0yQf7Anf9q8HvDvj4sp9OSzf6wWH8le7fSosWQmYuo1aPmfZcRM KUDztrWopxCiej+I7j34vvXrz7zx54AnHXqfJ9DFmXm6fj7OwjCoJIKNsY1wAYFvYgvEvDcd+RdW nf+SXnU9jtpQ9K/4MVtlCDYJkH0bjbpSK7VaTXa7qrovDjgJUwIITNL8+55rYxIyhFXVl9GEEPt+ nXPPWf1PqWOHEnWCdPF5ZMVE6LHfsiZReS4LUmVl2wwC6IEpVitvGbMwoL+EStrO74AZ/ldgBsLj EQGzi8tfTwMzmijCOz4fLwJygUyG3PPXrgac/V6yz7LWhRPKdXPIqjn7tTRWh55o9gfUcAvDV1oz AhXwCY4vOWSNGhGHIuAdk/F4bYrPH7BZPF60UQdxn5JAQ+LYZcRtQnC6mT6Qlq4hrCHdn/f4AF9K hteq+jkUNkxAcYHv6YymLPB1St4LGacZ8TV5kO6BllkB82THXvjeKg5jfrefD6pW5GCK+dUublV3 AKxOSweEM4kza4WFQOfv4UQqqjwFV4NhbOHfjAUas4yQBvRfRzAZDMpp2BcIArk3tia5oNhkpqRp IBKiw8loSedEKJ49ukjBrEwwXYb2lgGj7Fy3GTKgWqmdqQm8DewLKY5vEhcUe02RmKExE0KRHIyz s37ul+KEqqvHLmqYYqPJprLPdalVYrboc4L+vb58YxxHr+kej/v+/CYreTQFSFU6vxlXwPNHqqtP um/qy6dXtqHs7N3Ie4kdLb7P5PcPc1dLk+yFNdj0uaxZTs/ODVWmRGlq9tZSEKYGxuMaX2cmDBFP KZL1KDYeAJuDH1ZebHeRRbZgP/9TlbVmr5TCvs2lu3UEsjxashgSevkQq2LKb/5IIZEKiblhBAqz w+qfJdWGyeTvgjp1psrkKqVoqahmrvRBapYdq1wdlau2VVQNSSpgfaKtpA5Xfq8OFbpZpHRMTe5x U6kk22WJdN09ygsDaJt2Sxg0jTfNYrqcsmZPYg26E3wIma/exmPKduCtrTPqfnjt/nV2KN9uVmRV 5f1b9MKWXsgVK1zvDJxzN9h8OcOggcPMV/SKzPFzDOEZo4Xygg7oTaUohaREGQ3rncGRzLDUlGn7 8hPSGIa0RSy4EKrIrgoTFyUic2bQnnah4rNDgukgHXOhIPREIQHCZRhx4fp1mGrYwHDcsQgXXhBF 4sqUSU6TllLMICnqNerNTIsAkg9PxLiUj+4OBcyNrRjayfSYFRnI3CVtaO5VUYlb05ceYXPiyTOk xQ0xmfFNn1r3QDlymjMkiQ9PbbdNrb7sUwq4k5fxKuS9RZNmWbGUtkejzfKxk1zbJ4ZzEo1+Z1MY +WtGUOo5uqFNtUU0FwhSWyGJW+x8ToLAxHenRPflyQ5nt3sxOFQbHFjV2Uk6hF26id1gUId8uKlk caUg7iho8bLxWdIQw4DnfFBgsA4Ya5JijJ3saI+qMCG4h98SMQHFUdwro4PW1cfF4nw+e0cz/3Xp GlfutAcsLQBuko01Fuh+MQj79tTIg+Mi/ls+1kGid58+249kIMx838ceRGtvuRwGPvMe6Ucx4Rxv NMbIfjGGlvuhFwg/CNx6CYAclbTaCpvnPUjmSKxZ6NH94mO5CLZGGcLHZZjynvcQv98wkfAiW3Ib aa8IyegVIJ+ygHoxYZKmqDDOJHtvRvrdEgs6MdAh7tJJO6wIknJJoirKfnuBj8B4NDQX7EtJ36vd jgTLSdGwX3VVGCzvAKJsDR05sec+wKMhCo3TPg4x8a8AAwCwSOHGDQplbmRzdHJlYW0NZW5kb2Jq DTkgMCBvYmo8PC9Bbm5vdHMgMTAgMCBSL0NvbnRlbnRzIDExIDAgUi9UeXBlL1BhZ2UvUGFyZW50 IDM0IDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQ3JvcEJveFswIDAgNjEyIDc5 Ml0vUmVzb3VyY2VzPDwvRm9udDw8L1RUMCAyMDYgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4 dEdTdGF0ZTw8L0dTMCAyMDkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDc+Pg1lbmRvYmoNMTAgMCBv YmpbMjggMCBSXQ1lbmRvYmoNMTEgMCBvYmo8PC9MZW5ndGggMzEwMy9GaWx0ZXIvRmxhdGVEZWNv ZGU+PnN0cmVhbQ0KSIm8V9mO20YWfe+vqLehBhKb+2IHwTh2HDhjZxpuDYxBPA9ssiiVI7FkLi0r Xz/n3iKpXQESYB5aTVFk1V3OOffU/YP47rv7D6/fvRGO+P77H968FneOWNy5Qom7+58ecd3c/TC/ u5/PHeGKeXnn2I7juLjMxYyuvVDMt3hZzBvhOvT/d3yb1/hiOx4unf4qjO2IXhUxvscRXc3Xd79a n63s80RMIquRVSuedmI9iS05mblWgzuT0FrIeiraOsNlPpn5lqSrp5UU8tumlrhuGn4no3fUSuha mPubTBVi8t/5z3ezs6h9itoL7dANKdwCgeSyblWpZEHBrDO1mopatl1d0fda5lJhkw1t0uKHrx12 kE0ri6nIisIEMvGRBS4K0eqDnV1/3Jhi2IpZv/PMtd0gjc3+HxTSC6x64lm60WWLdRu6IUq9Wukt X78wq/44v/vxA1p1v2+fO7TvqFsm8WCfN+1+tTNRHNpxQg+tTTw1ByJe63qj66xVGrlVJgRnv2Zg EDAm8wYv/6uS4gMVDGtwZdA4XU4S1O5TthuWOHrloyyojbpCRT+9EmnihB5enUU+PlP+Q+0PGxrt y5ocxODHLq1ovWpbQErp6oXY5/LYZlWR1UUj3lWT+ZezPNzADpIRE187VasRj+Kz1bRFg+b/Y825 od9mWTvXFDsB+Up/vBv98Q+AaQByvUVeSuQhRFGPXuvNDlh7Id4oRmDeAv26xFciVFurJ9zsGLPA 9eMOeF03Yw2GxrwU1KOaLq/G79+IP973IUpvh+96thcwCwz3n1CyMvsmDWOiPQn8P0OC4EaQZ+y/ GmSYJEQDv6/xDRhR1RhJX4cyn8DlONDHTVaNsYbXY4UyIFTnUpCen9hemKapiTJOiT0UJVemnbiW wSd9Ww/R2lxTIPQwmsOVIjvFSgn2CG03oRpAol1au5Z35WGFo4tRD0XNz+L1A98OguNgmSag3kVx mnmJHXqA0ak2/l+0qJeOPyNGZ/g6ieKxe/oi8/aF+Kh3k9RMq1W7m72tpRSPRF4adoWsBcr8kBHm EKJ4r3Keghy1FH20p6oRn8vfr9bbLG/UWmFSgli/aBu7vgCvhAi8cJb6Ee7OYnz4+PPSq6SKL7f8 VDcvsgkcCp2YWx8YnEZ2IH7Sz7KuqCM838X7bPtS/NwxdZrCKCuyJc69FKCfriuqz47G69/EW2lm 7WG4cWB7CbYKByCnsR0mhGLvDMLJDZHw9lldHJVe7NqJIQ2llZicxHzJessC+mqBhrKHgZ1pltlq JZ6kyPXYxLbuIHcZdxv3qfFtDXXDTbifdinFKts2N6E181zbT3z3hCUQfnod2tRKmgKfsmbJVV60 upoSmiBa4j+6E6hvaOkecwZaiBYSLL/lq663MupZii/oynFL+CXCPq31LCv2QUJVvHUpAeBsRYDL dWeGime1Dfs71baqWtCjnNv87wj5n3TnNT/Kq7a7qZjMIusTaSuiZ4BQ9KKrVr3Zo3uaQ8B2tDtd 064NUWywia1YZ1DumlM4BxYyVQ0xjLOfUlTb5fjEUuRZI02p9p2TY5Sjv7vJxIH6pqg9QIaqXggJ mIgsU9Sxoo9gbbeR/DxmOx6gakV9YdHlfRhnrhzIHOoLMUkt1JYh0Rd1yMbmPLcZRUZwLWRpJIfr TUC6ZNdWWf4b/YbYGl4KDbiY1xFgSl1Tr9ei4rKiuM9jVRVfNTYAkFoPrNX5UPamMa58R2RCYCgA v1jwytROhWrV4mGQ1rrdDSVcZ1WFn/aj4lQos65dao7892E/sy74mG02K5VndN5YESa3wnThEN6i 7lbD1LfFVSFNr87OQ90JbzgoH9IdHU79yA7Fq6ZRC0RUraksaPS5MAZe0Atj6PVD/6I0us5fMVAu YgsDcg8c5SCOBC5qXIY4UaUFNUU10EmqH6QSyjNlbCD6rNqJWi2WUIzekqYW3ddPK7WgoT9yUSxH 5ktWj4LahpPiln9gMKB9esO3+dVDST0V+llkJ3TyOdVTABRHzxwR7ruvsTgtulWNnOKsqZ9VQQaW Ns5ahhznGiFXigWyqPYsPWs1zoJB5KK6/ZmjblqRLfjMKcdsSZ5qBf2kVUl9aBeoG9x8Rl0v8EHB FqpnHPEWXDC1Pkj8zG4Nu+8pQUH0UyyiufBSUFtITNcbOkZQcouq/1E89ZOZ+6yOihzuzwUpH2s8 mp6RP6b6rPTKtIZHFyJ9hEWi7+PgxC7PWhWg1VVeIfirxDpIN7lxsvID4ScOUaWnVQTRrAbJxsQm xvMlaqrgsvHjOc38OLEDQ7PIdqMrHLt1EvxjjvkO+enDYMW7kmSVm1TLrKFBAih0NftHxvB6Iwc/ eTjQ9506P4F62CDEQaTvFDelVAw1glwv2TsD/3G2HXTyFXZbGH4SjA3NdX3Zsc88+DXPPaYffD5v 29ONpFYOo7+cEgmAj67iWYUC5PQjCzXC+Wxp5iNUoF3i1MUGm6HVCM/GCo7Ffp4W9WBJOaNCBLb/ eTKFkciXtAonx6plpjPNhdBi7tWyaUVvuG5ZNXY5R55wS+sZcMuK4zaL6n5YfVPrbn2TRm5qx0Ey 9kZ+o+bSIF4roztUhEZzUkY+yNmVJbglbjbdDezESYKx6UuyIbz4kCms2UOGtshmOljYP6rAzA/s MDw90V0sCamtMo6S5y/kpOxwn6s09Ih0h3OxxbtqjEo+y370XdMeUNJ34yE3gkU7EKVnCXWc9iWs tBOPQxv4Ep37mVIRF8w6e0Lc0to+hNMh04seIzOxvCn++/QREF8ASQE6dXwEMnih3Z74/Ij5A5jf KL6HpZxw7CgW2ptYVUs+rVC5h07QHCYhWbFCyCPra6C0qDNWEgwCzFjZmVMrEbQX7VtTdgjneNg8 EZ2qwXXtyc69rggAfNagMUAS9jZTqw6xkzujJwiQO4a4Kc+NFsAHRV4SjwOIUh1IHlmH6rXorQmw if3HI0dLtC3op0EMssPtoj3qEpPwsOFRz9lr17RZ2bXsI40WmMx9FJ7XZ95NZnEP1l7jNXubPmpd 2dfnov/X5iJ8YpgIRG/HuPSH0Ygc6oz8hlxnfBAJrN/u32tyLFr8u2HrIi9MRy8J7ZS9p+uEtnNt PAY3xuNJN8+GY5zamOQccQQbasbjLyiYOfIwYKEpgPBIgga+BV86MVpPPtvNXN/qcAIcWyIK1WzY A+740Q8q5xNKA+ujS7yEmlBB+sd/G0fdNVV0PQOIYyqs9EKT7EEJ2TuOp1kahFuccYC39xe4ac4r 79abFQ9bOBRgt7dWA5/wYm6OWGCWOV8VHcnodQSFN5pxYXxcxBDk18OxI04c9LbHUIKuiI/ya6fY 5w5oR+U5hbW8eIzxQseGuXJ9nzzQZfhElzF/4jdOI/WcmFbr43TSA+ggMlUtzFnySBh6tYtIvnLj uWEUjWhljWBdpQRjq6YFcJccMlLc4yqwbo0LTOM0cdP0BCLKVGhEMI/AR9kfgASK8LiRuSpxaqX+ T9kF1lD0tTLPPmSkKTzERVnrtYmePGKfKA/2ndji0EaQ0x07R1WVlAg9w05rgOZysHSjxL2hsUYq 1Xz2IPxkIf7HebnsNgjEUHTfr2DZStEoQBnCB3RRqctI3WQzgUlKS0jFo0r+vtf28EgJLLqKIBIz vravj4tCAKw1BVmXbGXNdYU/06LNpD+5hrmuj+Y4ekVXShdne6j8JNYDrNLWkAulYEhbPg6/ZVNc SQtEhYg++ONy0ZVYLO2pzuDJxbLlYeZOvbF2gm1eQHH8j5WWnUtQBxXG8caym8f/qmy332hAI+Au WPc2nnivJIjUCdRw7D54hK3vtKCfhAqqk4n7EcKe6cLNgm/81XHi4ptEPQfdfTsX3zLNeweTNpIq aiZTCRWKuiItQoG6SC30HEnMVvjGz7fOKaQJlrAXm7aNmxTc66Pkx0PJgWS5O5H9KIrvUq1mlsIX ynNDVn7IsxF2mUJ5LzlPcUEXqrqT+XLgMjHX2JV4nOge5L7bvSAazyZTlmccSltqmXYsV3vsrTSO TUUdphEXVKvQvvrxgrnF8XbQg3e3IU9HVneHeZDfsaTqqFbwm9olCfsintJeAZSWN1C08d7tnq5a 543dPS00QDLfAOv58bNBKem1CgNO4ukBlrv97L//K8AA2vF+Eg0KZW5kc3RyZWFtDWVuZG9iag0x MiAwIG9iajw8L0NvbnRlbnRzIDEzIDAgUi9UeXBlL1BhZ2UvUGFyZW50IDM0IDAgUi9Sb3RhdGUg MC9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQ3JvcEJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzPDwv Rm9udDw8L1RUMCAyMDYgMCBSL1RUMSAyNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0 YXRlPDwvR1MwIDIwOSAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgOT4+DWVuZG9iag0xMyAwIG9iajw8 L0xlbmd0aCAxMjU3L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiZxXTY/bNhC9+1fMUQLW XJL6oBgEAbofKFIgRYDoknZ70NqyV8Fa2kpUt5tf3xnKWlFeSU56kUlz9ObN8M2QuvwM799ffrr+ eAMcPny4urmGFYf9SkABq8tfv+C4WV2lq8s05SAg3eFquoE1Z5zLENJnfA3SBgSn3+84S2ucMC5x yI+jSLGYcy5A4VzFNEoPqz+9mAkOt6Up6hx+2dd57kfewRdeXhr/r/S31W26uv2EhJRmSQyKJ0xH WuNIsSQBhJKcB1Dnq93qcohD9HGMaJ9yEkhKBVrrU1KQPhS+8hp/HXiWFZLKD0gJ/NjbVCVO7Zop TGvyBswDGUDehZHtcea8c5+bZzsr0TCHz1ltCpo38FyYB+TePNHqxviJB6aCwjRgY6cE82jItaZc rzXTOoS1YCLUCtIt8m3a+2/IFyHgkBmTI8sasnILBzvc07PxQw+yx0d4qosKV/EvNOjiMfkBX3+q yDgr8ZlXLb3S0bDOeSAGIkIQExmxJMLk847EpjrgO4cWYyn9tfCKTWaKimYNg48GmgfyXlaUECDT alvsinwL+b+bnDJgfOnB/Qtkrls5eJU2/N6rTUCgROf8uS4w7tLN/SAk2GYG/WCWmvzv1u6EwUQ7 XoQTXEBuhGKBEGEfm904QoFqh+OieaMKynZDotmX9P8Wqj4PGC5GvqM3v1at3ZZPZLipq15H1c4s xtyzGW06ZgpZFTVYIs0TPTedKv9Bsu0jZrI1D1VdIL3vtJDb/a5tsmt/LW2OLAEMIqPX+jmDUfE5 lSUnK2t9IlWhrUJmmkAIcZTYyou7eusLf2vzhSWQlTaH2QaVYYaVmZy+m2UbLLBVA9tYL7MNQhZq HR27w9UL3HlNsS8z03aZDGwm73wazZMJJ8nYXsqX/UvJtNJhQv498NNvU/DRD/W8AVQIFkY6DBdB 46UEaieDUwEEnPRKfeuYwcDut4dbVsPv2SF/N3IbCZYgrzA4NmVq7vRQGiVvO7xjoclC4ijqbcWr mdQRC5JFJKnp4KGG76AFeMaoN2hREFH29QmgNRizGxvqE0NxGgbXTA70MEPRmP7cuuPHNbH4g5Wz iWpaeOMi0HypCATgqcuk9WGLgLYPywAPE2xlpT1ytnf+vPiT/yd+9JsoezQHizrVPyN+BFWxTZxa BBV8Xv0kZaRO2peTva4Xf9xnLpFd5r5W/jr0Wnpg64jxgrGl8dZOcmy/ePE4yWMvmIQqFpvmRGVI FsXWIhJkIUPJEjFbGQtITmUMaGcrwwWcqAzLP1Ih4+LVK7WEcERr3mDwNLLpJd+buXs3fQXsOpf+ AdnFXWNMC/N40qdcL9PHoZX1PDRuVqjOim/67JpHDQXNFyGnT6Cf7OYo6DjAO6hOIuvtujAvF/AF LxD5BfxRPF3AddWWpn6Z6u6RCtymho/k9f7eadhaHLv7koaXkAYNO2jnNDwC7DXssOv4B4l7prxp 2rPrjh/XZL5pi+nz/PWr66yAZXKEt5KY1cT0CX9GwXghlWd7spg+d+ZReWQTc6Yupk8S9x6/oNwu KV0r9m7os2BSpYE6fmbOqhQ3kb/ttNKR4FEP80iOSgc0V6UDmqseB3BWpVyOVBgx/JCYXF++Qc3j ONwHrLMV5sJ1yneYLZiN8FwtnBz7whXvUQGOwEItmLKjNwL7T4ABAA5SxpgNCmVuZHN0cmVhbQ1l bmRvYmoNMTQgMCBvYmo8PC9IL0kvVHlwZS9Bbm5vdC9SZWN0WzQwMi4wNTk5OTggNjM1LjY4MzUz MyA1MjEuNTk4MTQ1IDY0OS4wMjAwODFdL0JvcmRlclswIDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3Jk ZXIvUy9TPj4vU3VidHlwZS9MaW5rL0EgMjAgMCBSL1N0cnVjdFBhcmVudCAzPj4NZW5kb2JqDTE1 IDAgb2JqPDwvSC9JL1R5cGUvQW5ub3QvUmVjdFs1Ny42MDAwMDYgNjI0LjIyMzUxMSAyMDAuOTU5 MjQ0IDYzNy41NjAwNTldL0JvcmRlclswIDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3JkZXIvUy9TPj4v U3VidHlwZS9MaW5rL0EgMTkgMCBSL1N0cnVjdFBhcmVudCA0Pj4NZW5kb2JqDTE2IDAgb2JqPDwv VHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFstNTY4IC0zMDcgMjAwMCAxMDA3XS9Gb250TmFt ZS9UaW1lc05ld1JvbWFuUFNNVC9GbGFncyAzNC9TdGVtViA4Mi9DYXBIZWlnaHQgNjU2L1hIZWln aHQgMC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoVGlt ZXMgTmV3IFJvbWFuKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDA+Pg1lbmRvYmoN MTcgMCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L0Fy aWFsLUJvbGRJdGFsaWNNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1N1YnR5cGUvVHJ1ZVR5 cGUvRm9udERlc2NyaXB0b3IgNSAwIFIvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDAg MCA1NTYgMzMzIDAgNjExIDI3OCAwIDAgMjc4IDAgNjExIDYxMSAwIDAgMzg5IDU1NiAzMzMgMCAw IDc3OCAwIDU1Nl0+Pg1lbmRvYmoNMTggMCBvYmo8PC9VUkkoaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tYXJpZC1wcmEtMDAudHh0KS9TL1VSST4+DWVuZG9i ag0xOSAwIG9iajw8L1VSSShodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLW1hcmlkLWNvcmUtMDMudHh0KS9TL1VSST4+DWVuZG9iag0yMCAwIG9iajw8L1VSSSho dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1hcmlkLWNvcmUt MDMudHh0KS9TL1VSST4+DWVuZG9iag0yMSAwIG9iajw8L0xlbmd0aCAyNTc1L0ZpbHRlci9GbGF0 ZURlY29kZS9OIDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+c3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCV sMNjDVuAsAaQNWxhkR0EUQhJCAESQkjYBUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4 tBbXjp0XOEedTmem0+8f7/c593fv793fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJAAMKIAIR ADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7ca6qN+hM9hmc eaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKjMPFpnFfXGZU4I6k4d9WplfU4X8XZpcqo UeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7XPoOG5QNBtOlJNW6Rr1aVW7A3OUemCg0 VIwlKeurlAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4kYNFocHBQn8f0TuF+q+bv1Cm3s7Tk8y5 nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sAMPG+Hb74zn34pnkpNxh0Yb6+9fX1Pmql 3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo26rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUW j8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4Y68Br9gHsC7yAPK3CwDl0gBStA3fgd70LZWS BzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0WQICoAIm4AErYA+cgTsQAn8QAsJBNIgH ySAd5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsYA7vBfnAQjIOPwQnwR3AefAmugVtgEkyDh2AG PAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEsqAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegEdA66 BH0FTUEPoO+glzAC02EebAe7wb6wGI6BU+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwC EBrCRxwRISJGJEg6UoiUIXqkFelGBpFRZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKai8rRGrQV7UWH 0V3oYfQ0egWdQmfQ1wQGwZbgRQgjSAmLCCpCPaGLMEjYSfiIcIZwjTBNeEokEvlEATGEmEQsIFYQ m4m9xK3EA8TjxEvEu8RZEolkRfIiRZDSSTKSgdRF2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S 95A/JV8m3yO/orAorpQwSjpFQWmk9FHGKMcoFynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZE C6Vl0tS05bQh2u9on9OmaC/oHLonXUIvohvp6+gf0o/Tv6I/YTAYboxoRiHDwFjH2M04xfia8dyM a+ZjJjVTmLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXmIxaF5caSsGSsVtYI6yjrBmuWzWWL2Ols DbuXvYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91veBG/GnGMe aJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJijcV+i8sWzyxtLKMtlZbdlgcsr1m+tMKs 4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsctLlpC9t62mbZNtt+YHvBdtbO3i7RTme3 xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMxWBU2hJ3GZhxtHZMcjY47HCccXzkJnHKd OpwOON1xpjqLncucB5xPOs+4OLikubS47HW56UpxFbuWu252Pev6zE3glu+2ym3c7b7AUiAVNAn2 Cm67M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96wV7BXmqvrV6XvAneod5a71HvG0K6MEZY J9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8tEUeULOoQHRN95+/pL/cf8b8awAhICGgL OBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4QYhLSEnIeyE3xDxxhrhX/HkoITQ2tC3049AX YcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3QinCFnEjojJSCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3 YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6HxCXGdcdNxHPic+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ 2pB0Q2onlUt3S2eSQ5KXJZ9OoadkpwynfJPqmapPPZYGpyWnbUy7vdB1oXbheDpIl6ZvTL+TIcio yfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3ZT3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi 8wXWBeqCI4WkwrzCnYWzi+MXb1o8XRRU1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxd NiqbLZWWvlc6I5fIN8sfKqIVA4oHyghlv/JeWURZf9l9VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8Wz yvTKDyt/rMqvOqAha0o0R7UcbaX2dLV9dUP1JZ2Xrks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zu xpXGqbrIupG65/V59Yca2A3ahguNno1rGu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2z bXp54vJd7dT2yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2rHnd rej+osevZ7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbKB74PtN xZvODQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf +qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axc rNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5 wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dB x7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V 0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz 5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0 NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23//wIMAPeE8/sKDQplbmRz dHJlYW0NZW5kb2JqDTIyIDAgb2JqWy9JQ0NCYXNlZCAyMSAwIFJdDWVuZG9iag0yMyAwIG9iajw8 L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQvQXJpYWwtSXRhbGlj TVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDE0OC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlw dG9yIDQgMCBSL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAyNzggMzMzIDI3 OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NjcgMCA3MjIgNzIyIDY2NyA2 MTEgMCAwIDI3OCAwIDAgMCA4MzMgMCA3NzggMCAwIDAgNjY3IDYxMSAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIyMiAwIDUwMCAyMjIgODMz IDU1NiA1NTYgNTU2IDAgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgMCA1MDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMzMzXT4+DWVuZG9iag0y NCAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQvVGlt ZXNOZXdSb21hblBTTVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDMyL1N1YnR5cGUvVHJ1ZVR5cGUv Rm9udERlc2NyaXB0b3IgMTYgMCBSL1dpZHRoc1syNTBdPj4NZW5kb2JqDTI1IDAgb2JqPDwvSC9J L1R5cGUvQW5ub3QvUmVjdFsxMTguNzQwMDA1IDY0Ny42ODM1OTQgMzc2LjQ5MDU3IDY2MS4wMjAx NDJdL0JvcmRlclswIDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3JkZXIvUy9TPj4vU3VidHlwZS9MaW5r L0EgMTggMCBSL1N0cnVjdFBhcmVudCAyPj4NZW5kb2JqDTI2IDAgb2JqPDwvVVJJKGh0dHA6Ly93 d3cubWljcm9zb2Z0LmNvbS9leHBvcnRpbmcvKS9TL1VSST4+DWVuZG9iag0yNyAwIG9iajw8L0gv SS9UeXBlL0Fubm90L1JlY3RbMjIxLjAzOTk5MyAxMjYuNTIzNjIxIDM3OS40OTk2MDMgMTM5Ljg2 MDE4NF0vQm9yZGVyWzAgMCAwXS9CUzw8L1cgMC9UeXBlL0JvcmRlci9TL1M+Pi9TdWJ0eXBlL0xp bmsvQSAyNiAwIFIvU3RydWN0UGFyZW50IDY+Pg1lbmRvYmoNMjggMCBvYmo8PC9IL0kvVHlwZS9B bm5vdC9SZWN0WzIzOC4yNTk5OTUgNTg1LjUyMzQ5OSAzNDMuNDUwMDQzIDU5OC44NjAwNDZdL0Jv cmRlclswIDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3JkZXIvUy9TPj4vU3VidHlwZS9MaW5rL0EgMjkg MCBSL1N0cnVjdFBhcmVudCA4Pj4NZW5kb2JqDTI5IDAgb2JqPDwvVVJJKG1haWx0bzpzdGRzcmVx QG1pY3Jvc29mdC5jb20pL1MvVVJJPj4NZW5kb2JqDTMwIDAgb2JqPDwvTGVuZ3RoIDE3ODMvRmls dGVyL0ZsYXRlRGVjb2RlL1R5cGUvT2JqU3RtL0ZpcnN0IDgzMC9OIDEwMD4+c3RyZWFtDQp42uxY S08jRxD+Ky3lkhzC9PshrZCADcqGzYIwOVk+eGF2l2A8yJjd8O/zVXcN2GMMdKRIkbIHXN09VV9V 12tqMEFIYaJQ0giThJdaWCm8VsIqEYhoPFNRWCOUSk5YK5SVOHegHtQL5SyeB6ECUWBFmYRNQiWf hJNCSw2qhFZBCqeF1sBzBjRY4azQRuG5A/XYe6Et5F0AxUMXQRP2SWgH5R54LsJS4HnjYCpoVMID L+ggAKFDMMIDLwLXAy9i44GXFPiAlwAO04zEpWGSkTA2KNBkcWdhFOwFhFHAhYkGBovghDHQFzwo hEIQxkrsIyhcFoBHdkbgOTgLosZBKALPAzwCL0BfBF4gPuBFXC4CL8HrEXjJWBHhQmmkwBWtxOWS RCTAlygUKoiEAGlcPhlQ/MBka8CcQwM7k0doiC+AwtgEPC8hD7wgETwJwGA8RRXBMhReQEbch3LA phxwgKZIJw4BzCcei0hSAaGEfQqYTuEWioKlc3ogugZgCm52xtNCI76aFgaLSAtE1BmFBZDJPqWA TPmmYLTznk6AHBSdUBogIZQGcoS9CnwuUsoBFFlAJ0BOnhaUG5IeIdgSaaC0R5aQdkoLRRfUEfmC IFKAvYZr6SbeUC7DJm8lnWgsPC0oiTQtgJxNpXTz5Dr8eQ9Pv3nTnN3ftM1oubg7X54t2va065bN EVWUFKfNwWx6e/v79IZKi/Yn00U7z3xUZesnH9q/lkftPfzZnHazlqRQguDZ3YWaozEVD3aoMsVU MzVMLVPH1DMNTCPTVGhkvMh4kfFcT/ncMZ9jPY71ONbjWI9jPY71ONbjWd4znmd8zTiacTTjaMbR jKMZxzCOYRzDOIbtMoxnerz+OeNKfi75uezPWZ9kfsl6JetVrFexXsV8ivWqgsvuYu/1QUkMnhg0 FVAtC6jP20lzgqaQ82HUjNrzZQ75h25xPZ1RF33Igg9317djST05g1FTzmjUlWlhqC3TwvYLRw06 a6IOnS2jFk2LSD2aFrlJkxlZx/HdcnY5R07fTOfNH/OLdvG4LSY1J80ZknW/+6t5e/m1OVxMr9uy QvLPu2ULPvz8Mr943Iy+TFEnh5ef7xZt825OkGtHZ8d7+Dsg+o4W9HPIJ4d8Mrq7aRe354vLm2Ux Z3T3cW27XFxetd0db98uupuD6U2v4aC7vkap/aDlafupRdWd86UOu9ms+9Ze/IpKprtelePB9uvP y+7627Rg7+6+ohxfW5bD8hyU6Ua5Dst2UL4bZZzpZLxZ14Va+2S594nkXmgCdktTGDaHYZN4bbMY NI1CJ7kjmr79Hu//dtocf/xTlFayu0sFxRdCRb2nIJ58Fqvd1IuwIV0KOTMMHqzByqdhx48NbdjY tjW41za6YcPb1vgGDXDYCJna8HR/LLS4VqtN34YVJxTZFSf43gmv7LLcejab7qD5bjThYTMeNuVh c15r0uVybvNuceVucni3xHfrO/xao+eC4PzntOds5yTnHOcU5wznxOa89gXFFxRfUDx37oLi4+ob I18Es8mkOXjoyv3UMXo4QXLqx6QXutkb09iXXzkVcmaVOcnnmW0Ns6th9mvM6nnmsMoc7fPMsYY5 1TBjmlvldi9wq1Xu8EJYlK7iNlXca2Es76BnuNfj6F/g9lXcoYp7LZThhYxSqaYMSgWihlLfnGQ/ vYU+G8/e8gumGMoWZJa+rZz17yCeCHgg4DkgqAcB0wvsdxf3fVprtqGMFZNVs8+mH2dt5tvHbDZ2 YQcfRDJ/uekdfOq5/FWvd0KySdNXjt1xIbk0aY6b99P7PDgtp4vlOwx986WQO5JmON4pqwCHb8DQ nMym5y3NUs3+rDu/6i9c+lpS2y9cioWrYItPSpcLaTvLU51zAo/w4BPNg2gYBIX7K/EWY6Paxntc vImpcUYDn1D4KPtWVvycPZZdsDe7/Dxv9ttPHQbN/W6BoXm0vJ+1P4662eXFT3wErG4xhlsF/034 wdmXy/OreXt7i8Pg/hP68ZZ84uWV3cxfD48R8htulr2bS2rHsI33u5ufmh/IzakcpMdacUM3lymD eEvmJ7ON97ubnxqpsptLlpfP86c6+f/ddY+vhht0/YIsPF4Neb/3adku8Jbckexn20/2fpKHTfOa YTM9vGTrtAlJOrSq04HXfgWvruA12RxZac44iJidpVKtZMIMUkRjrSj9f1UX2VAtazAOFFlfLesw /xVZVy0bMN9VBTr9O5n3nXm96pG5Wvb/WNAlrfSrSt//w9Iv375QY1OdmqOxFqZIxkpJfNqSWKhV 6LgZWl+rMGQxVysWs5itFUtZzNReTyEUHAtdLavxXVpkVa25qoRDVut86ECmOne4A5FsrM47I3Tp mqYmhf4WYADzo3GEDQplbmRzdHJlYW0NZW5kb2JqDTMxIDAgb2JqPDwvTGVuZ3RoIDY1NC9GaWx0 ZXIvRmxhdGVEZWNvZGUvVHlwZS9PYmpTdG0vRmlyc3QgNTUyL04gNjQvRXh0ZW5kcyAzMCAwIFI+ PnN0cmVhbQ0KeNrsVttq20AQ/ZX5gmjvOwsh4Lp9CE3aEhv6YPLg1ooxpHYQKjR/33OktI4LTbqG vvlB1sxozpmLdsayPosR61VCxK1IgRZogRqsWKXuxDnqXlymHsRb6lF8op4kGOoZLNTBVqgXieSC LSr0aCUhhI1OEp9HL1kT7kHU0y+KFo97khJ5z2KNpaAQMgWgrYXGsDbBkpCjM7Q4CIkCrN5RCBCI SkMttCQmS0tmVrQow9LCvAo0FphQqc2WCrQM5sxcyKUWrBmX8ieDuXg6grko4VmcYS+zirPsSi4Q GBCtdM4VckAobC4a6xld0dnAlmqAwOLQLxcJR4NcZFcVzJFtQxiX2FcFc2Jj8dJcZgdB6vKQFJjV 0QJmZQMKmIulBcwl0pLEG4M0Ssb7dJ4V8MWirlIgMAXU75G9nJ83H5ur5ePue9/MHpZf2zft3a5r JZ2ZUZ/c9W2HN3BmLi5OzifnF5zfLyK3jZEb0dtm2nzYdd+W980nwRaCsZn9tqzF0vKEwtkWrB7i Qg0OY+AspPnjQ9tcT29wXb4V88zttpksuAGgvEaM4d5TS6lJnysLXRiD6b8EO4BjPsOIzdVYTHsa sakay801YmMlFnukwtmZGmdbcwC4ZscSQm35Dmszjlhfhz0N/fEbAtOJjpdYP5F2AIZ6oBuAvhq4 8DKOJf5yq4PGAWjrgWkAmnpgJlDrV91CpQxlqtZjh9U3ovMRaHx/jeOr6Qg0PmfGAdZ4BBrfdXlE hyPQ+CB86lr1wTpthJPzq87z9kc/ud+st8203cLlAB3/9P7cbfrNdn29W7XNVTf/0sz6ZddfblfA ikGsd9vVM21PPvgdcJvDzH6579FD5L+f9v/8+KcAAwChJg4RDQplbmRzdHJlYW0NZW5kb2JqDTMy IDAgb2JqPDwvTnVtc1swIDMzIDAgUl0+Pg1lbmRvYmoNMzMgMCBvYmo8PC9TL0Q+Pg1lbmRvYmoN MzQgMCBvYmo8PC9Db3VudCA1L0tpZHNbMjA0IDAgUiAxIDAgUiA2IDAgUiA5IDAgUiAxMiAwIFJd L1R5cGUvUGFnZXM+Pg1lbmRvYmoNMzUgMCBvYmo8PC9MZW5ndGggMzk4NC9UeXBlL01ldGFkYXRh L1N1YnR5cGUvWE1MPj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2Vo aUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+DQo8eDp4 bXBtZXRhIHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjku MS0xMywgZnJhbWV3b3JrIDEuNic+DQo8cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMu b3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUu Y29tL2lYLzEuMC8nPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6NWEwNmUxY2Ut MmE4NC00YWQ2LTlkMTQtOGU5NjU0ZDNhMDlmJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5j b20vcGRmLzEuMy8nIHBkZjpQcm9kdWNlcj0nQWNyb2JhdCBEaXN0aWxsZXIgNi4wIChXaW5kb3dz KSc+PC9yZGY6RGVzY3JpcHRpb24+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDo1 YTA2ZTFjZS0yYTg0LTRhZDYtOWQxNC04ZTk2NTRkM2EwOWYnIHhtbG5zOnBkZng9J2h0dHA6Ly9u cy5hZG9iZS5jb20vcGRmeC8xLjMvJyBwZGZ4OkNvbXBhbnk9J01pY3Jvc29mdCBDb3Jwb3JhdGlv bicgcGRmeDpTb3VyY2VNb2RpZmllZD0nRDoyMDA0MDgyNDAxMjExNScvPg0KPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9J3V1aWQ6NWEwNmUxY2UtMmE4NC00YWQ2LTlkMTQtOGU5NjU0ZDNhMDlm JyB4bWxuczpwaG90b3Nob3A9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8nPjxw aG90b3Nob3A6aGVhZGxpbmU+PHJkZjpTZXE+PHJkZjpsaT48L3JkZjpsaT48L3JkZjpTZXE+PC9w aG90b3Nob3A6aGVhZGxpbmU+PC9yZGY6RGVzY3JpcHRpb24+DQo8cmRmOkRlc2NyaXB0aW9uIHJk ZjphYm91dD0ndXVpZDo1YTA2ZTFjZS0yYTg0LTRhZDYtOWQxNC04ZTk2NTRkM2EwOWYnIHhtbG5z OnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFwOkNyZWF0b3JUb29sPSdBY3Jv YmF0IFBERk1ha2VyIDYuMCBmb3IgV29yZCcgeGFwOk1vZGlmeURhdGU9JzIwMDQtMDgtMjNUMTg6 MjE6NDEtMDc6MDAnIHhhcDpDcmVhdGVEYXRlPScyMDA0LTA4LTIzVDE4OjIxOjI1LTA3OjAwJyB4 YXA6TWV0YWRhdGFEYXRlPScyMDA0LTA4LTIzVDE4OjIxOjQxLTA3OjAwJz48L3JkZjpEZXNjcmlw dGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjVhMDZlMWNlLTJhODQtNGFk Ni05ZDE0LThlOTY1NGQzYTA5ZicgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6NzNiMjQ0YTEtMWM0Ny00Y2ZiLTljZjkt MDgyYTkwY2EzNzQ5Jz48eGFwTU06VmVyc2lvbklEPjxyZGY6U2VxPjxyZGY6bGk+MjwvcmRmOmxp PjwvcmRmOlNlcT48L3hhcE1NOlZlcnNpb25JRD48L3JkZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVz Y3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjVhMDZlMWNlLTJhODQtNGFkNi05ZDE0LThlOTY1NGQz YTA5ZicgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3Jt YXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9 J3gtZGVmYXVsdCc+Um95YWx0eSBGcmVlIEMjIExhbmd1YWdlIFNwZWNpZmljYXRpb24gTGljZW5z ZSBBZ3JlZW1lbnQ8L3JkZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48ZGM6Y3JlYXRvcj48cmRm OlNlcT48cmRmOmxpPk1pY2hlbGUgSGVybWFuIChMQ0EpPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6 Y3JlYXRvcj48ZGM6c3ViamVjdD48cmRmOlNlcT48cmRmOmxpPjwvcmRmOmxpPjwvcmRmOlNlcT48 L2RjOnN1YmplY3Q+PC9yZGY6RGVzY3JpcHRpb24+DQo8L3JkZjpSREY+DQo8L3g6eG1wbWV0YT4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94 cGFja2V0IGVuZD0ndyc/Pg0KZW5kc3RyZWFtDWVuZG9iag0zNiAwIG9iajw8L01vZERhdGUoRDoy MDA0MDgyMzE4MjE0MS0wNycwMCcpL0NyZWF0aW9uRGF0ZShEOjIwMDQwODIzMTgyMTI1LTA3JzAw JykvVGl0bGUoUm95YWx0eSBGcmVlIEMjIExhbmd1YWdlIFNwZWNpZmljYXRpb24gTGljZW5zZSBB Z3JlZW1lbnQpL0NyZWF0b3IoQWNyb2JhdCBQREZNYWtlciA2LjAgZm9yIFdvcmQpL1Byb2R1Y2Vy KEFjcm9iYXQgRGlzdGlsbGVyIDYuMCBcKFdpbmRvd3NcKSkvQXV0aG9yKE1pY2hlbGUgSGVybWFu IFwoTENBXCkpL0NvbXBhbnkoTWljcm9zb2Z0IENvcnBvcmF0aW9uKS9Tb3VyY2VNb2RpZmllZChE OjIwMDQwODI0MDEyMTE1KT4+DWVuZG9iag14cmVmDQowIDIwMQ0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDA5MDk0IDAwMDAwIG4NCjAwMDAwMDkzODQgMDAwMDAgbg0KMDAwMDAwOTQyMSAwMDAw MCBuDQowMDAwMDE0MzMwIDAwMDAwIG4NCjAwMDAwMTQ1NjUgMDAwMDAgbg0KMDAwMDAxNDgwNiAw MDAwMCBuDQowMDAwMDE1MDUxIDAwMDAwIG4NCjAwMDAwMTUwNzQgMDAwMDAgbg0KMDAwMDAxODk4 MiAwMDAwMCBuDQowMDAwMDE5MjAzIDAwMDAwIG4NCjAwMDAwMTkyMjcgMDAwMDAgbg0KMDAwMDAy MjQwMCAwMDAwMCBuDQowMDAwMDIyNjE5IDAwMDAwIG4NCjAwMDAwMjM5NDYgMDAwMDAgbg0KMDAw MDAyNDEwOSAwMDAwMCBuDQowMDAwMDI0MjcxIDAwMDAwIG4NCjAwMDAwMjQ1MTAgMDAwMDAgbg0K MDAwMDAyNDg3MyAwMDAwMCBuDQowMDAwMDI0OTY4IDAwMDAwIG4NCjAwMDAwMjUwNjQgMDAwMDAg bg0KMDAwMDAyNTE2MCAwMDAwMCBuDQowMDAwMDI3ODI5IDAwMDAwIG4NCjAwMDAwMjc4NjMgMDAw MDAgbg0KMDAwMDAyODMyOCAwMDAwMCBuDQowMDAwMDI4NDg2IDAwMDAwIG4NCjAwMDAwMjg2NDgg MDAwMDAgbg0KMDAwMDAyODcxNSAwMDAwMCBuDQowMDAwMDI4ODc4IDAwMDAwIG4NCjAwMDAwMjkw NDEgMDAwMDAgbg0KMDAwMDAyOTEwMSAwMDAwMCBuDQowMDAwMDMwOTgyIDAwMDAwIG4NCjAwMDAw MzE3NDcgMDAwMDAgbg0KMDAwMDAzMTc4MiAwMDAwMCBuDQowMDAwMDMxODA2IDAwMDAwIG4NCjAw MDAwMzE4ODQgMDAwMDAgbg0KMDAwMDAzNTk0NSAwMDAwMCBuDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KdHJhaWxlcg0KPDwvU2l6ZSAyMDE+Pg0Kc3RhcnR4cmVmDQoxMTYNCiUlRU9G DQo= ------_=_NextPart_001_01C4897E.19E3C3CC-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 22:24:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08693 for ; Mon, 23 Aug 2004 22:24: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 i7O20sJl059207; Mon, 23 Aug 2004 19:00: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 i7O20swt059206; Mon, 23 Aug 2004 19:00:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O20rCK059200 for ; Mon, 23 Aug 2004 19:00:53 -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); Mon, 23 Aug 2004 19:01:00 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Aug 2004 19:01:00 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Aug 2004 19:00:59 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 19:00:50 -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="----_=_NextPart_001_01C4897E.2E71592E" Subject: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Mon, 23 Aug 2004 19:01:00 -0700 Message-ID: Thread-Topic: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ thread-index: AcSJfjPipzSpEVvpRyC6u0S07ROV9w== From: "Harry Katz" To: "IETF MARID List" X-OriginalArrivalTime: 24 Aug 2004 02:00:50.0946 (UTC) FILETIME=[2E558E20:01C4897E] 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_01C4897E.2E71592E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Over the last few months a number of MARID working group members have asked questions about Microsoft's Royalty Free Caller ID Patent License. We have prepared an FAQ to answer questions about this license and its successor the Royalty Free Sender ID Patent License. We are in the process of publishing this FAQ on our web site at http://www.microsoft.com/mscorp/ip/standards. We expect the page to be live on or before September 15. =20 For the convenience of the working group, attached is the full text of the FAQ. =20 If you have any further questions about the license, I encourage you to consult with your own attorney and/or email your question to stdsreq@microsoft.com. Someone from our legal department will answer your questions. Thank you. =20 ------_=_NextPart_001_01C4897E.2E71592E Content-Type: application/octet-stream; name="SenderID_Licensing-FAQ.pdf" Content-Description: SenderID_Licensing-FAQ.pdf Content-Disposition: attachment; filename="SenderID_Licensing-FAQ.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjY0IDAgb2JqPDwvSFs3OTYgMjM1XS9MaW5lYXJpemVkIDEvRSAxMjQw OS9MIDIzODM5L04gMi9PIDY3L1QgMjI1MTI+Pg1lbmRvYmoNICAgICAgICAgICAgICAgICAgICAg DQp4cmVmDQo2NCAyNQ0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAxMTk4IDAwMDAwIG4NCjAw MDAwMDA3OTYgMDAwMDAgbg0KMDAwMDAwMTQ0NSAwMDAwMCBuDQowMDAwMDAxNzYzIDAwMDAwIG4N CjAwMDAwMDE3ODcgMDAwMDAgbg0KMDAwMDAwMTk0OSAwMDAwMCBuDQowMDAwMDAyNDM5IDAwMDAw IG4NCjAwMDAwMDI5MzAgMDAwMDAgbg0KMDAwMDAwMzE1MSAwMDAwMCBuDQowMDAwMDAzMzc4IDAw MDAwIG4NCjAwMDAwMDM0NTQgMDAwMDAgbg0KMDAwMDAwNDA5MCAwMDAwMCBuDQowMDAwMDA0ODE3 IDAwMDAwIG4NCjAwMDAwMDQ4NTEgMDAwMDAgbg0KMDAwMDAwNTY3MCAwMDAwMCBuDQowMDAwMDA2 NDM0IDAwMDAwIG4NCjAwMDAwMDcxNzQgMDAwMDAgbg0KMDAwMDAwNzMzMiAwMDAwMCBuDQowMDAw MDA3NTcxIDAwMDAwIG4NCjAwMDAwMDgzMDAgMDAwMDAgbg0KMDAwMDAwOTA1OSAwMDAwMCBuDQow MDAwMDA5NjgwIDAwMDAwIG4NCjAwMDAwMTIzNDkgMDAwMDAgbg0KMDAwMDAwMTAzMSAwMDAwMCBu DQp0cmFpbGVyDQo8PC9TaXplIDg5L1ByZXYgMjI1MDEvWFJlZlN0bSAxMDMxL1Jvb3QgNjUgMCBS L0luZm8gMTMgMCBSL0lEWzwwZjY0MDRmNmE3NzlmZDYzNGIyZDA4ZTg4NmNiNDViZD48ZjUyM2Y3 M2UyZmRlZDk0NGIyNWM1M2Y5OGJmODZmM2U+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9GDQoNCjY2 IDAgb2JqPDwvTGVuZ3RoIDE0OS9GaWx0ZXIvRmxhdGVEZWNvZGUvQyAxNTMvTCAxMzcvUyA3ND4+ c3RyZWFtDQp42mJgYGABol0MrAwMAu8YeBkQgBcowwrEHB0M5w0YGPZAhYMk0vfOe+q3AMhUjWgA kkoWDSB5IACa4VADpEWBWAIsIsHAI5TAwLHwkqzBUZ4NJmpO+xkWS+s5neFIuK4jdF81KpTJQYuj oRNiMicDg+stIM0ExFZAzMHA4PgfSDMyMDDfZgA5lHWrqwNAgAEAPU0cqg0KZW5kc3RyZWFtDWVu ZG9iag04OCAwIG9iajw8L1NpemUgNjQvTGVuZ3RoIDIwL0ZpbHRlci9GbGF0ZURlY29kZS9EZWNv ZGVQYXJtczw8L0NvbHVtbnMgMy9QcmVkaWN0b3IgMTI+Pi9XWzEgMSAxXS9UeXBlL1hSZWYvSW5k ZXhbMTQgNTBdPj5zdHJlYW0NCnjaYmLiYGBiYGAc6hggwABC7wCgDQplbmRzdHJlYW0NZW5kb2Jq DTY1IDAgb2JqPDwvUGFnZXMgMTEgMCBSL1R5cGUvQ2F0YWxvZy9MYW5nKEVOLVVTKS9QYWdlTGFi ZWxzIDkgMCBSL1N0cnVjdFRyZWVSb290IDE0IDAgUi9NZXRhZGF0YSAxMiAwIFIvUGllY2VJbmZv PDwvTWFya2VkUERGPDwvTGFzdE1vZGlmaWVkKEQ6MjAwNDA4MjMxODQ0NTUpPj4+Pi9MYXN0TW9k aWZpZWQoRDoyMDA0MDgyMzE4NDQ1NSkvTWFya0luZm88PC9NYXJrZWQgdHJ1ZS9MZXR0ZXJzcGFj ZUZsYWdzIDA+Pj4+DWVuZG9iag02NyAwIG9iajw8L0Fubm90cyA2OCAwIFIvQ29udGVudHNbNzUg MCBSIDc2IDAgUiA3OCAwIFIgNzkgMCBSIDgwIDAgUiA4MyAwIFIgODQgMCBSIDg1IDAgUl0vVHlw ZS9QYWdlL1BhcmVudCAxMSAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BC b3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgNzcgMCBSPj4vRm9u dDw8L1RUMiA4MSAwIFIvVFQwIDcwIDAgUi9UVDEgNzEgMCBSPj4vUHJvY1NldFsvUERGL1RleHRd L0V4dEdTdGF0ZTw8L0dTMCA3NCAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMD4+DWVuZG9iag02OCAw IG9ials2OSAwIFJdDWVuZG9iag02OSAwIG9iajw8L0gvSS9UeXBlL0Fubm90L1JlY3RbMjk2Ljcw MDAxMiA1MDAuNTAzNTEgNDEyLjM4NzkzOSA1MTMuODQwMDg4XS9Cb3JkZXJbMCAwIDBdL0JTPDwv VyAwL1R5cGUvQm9yZGVyL1MvUz4+L1N1YnR5cGUvTGluay9BIDg3IDAgUi9TdHJ1Y3RQYXJlbnQg MT4+DWVuZG9iag03MCAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2Rpbmcv QmFzZUZvbnQvQXJpYWwtQm9sZE1UL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxNDYvU3VidHlwZS9U cnVlVHlwZS9Gb250RGVzY3JpcHRvciA3MyAwIFIvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAyMzgg MCAwIDAgMCAyNzggMzMzIDAgMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2 IDU1NiAzMzMgMCAwIDAgMCA2MTEgMCA3MjIgMCA3MjIgNzIyIDY2NyA2MTEgMCAwIDI3OCAwIDAg NjExIDgzMyAwIDAgNjY3IDc3OCA3MjIgNjY3IDYxMSAwIDAgOTQ0IDAgMCAwIDAgMCAwIDAgMCAw IDU1NiA2MTEgNTU2IDYxMSA1NTYgMzMzIDYxMSA2MTEgMjc4IDAgNTU2IDI3OCA4ODkgNjExIDYx MSA2MTEgMCAzODkgNTU2IDMzMyA2MTEgNTU2IDc3OCA1NTYgNTU2IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI3OF0+Pg1lbmRvYmoNNzEgMCBvYmo8PC9U eXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L0FyaWFsTVQvRmlyc3RD aGFyIDMyL0xhc3RDaGFyIDE0Ni9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDcyIDAg Ui9XaWR0aHNbMjc4IDAgMCAwIDAgMCA2NjcgMCAzMzMgMzMzIDAgMCAyNzggMzMzIDI3OCAyNzgg MCAwIDU1NiAwIDAgMCAwIDAgMCAwIDI3OCAyNzggMCAwIDAgMCAwIDY2NyA2NjcgNzIyIDcyMiA2 NjcgNjExIDAgNzIyIDI3OCAwIDAgNTU2IDgzMyA3MjIgNzc4IDY2NyA3NzggNzIyIDY2NyA2MTEg NzIyIDAgOTQ0IDAgNjY3IDAgMCAwIDAgMCAwIDAgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2 IDU1NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDU1NiAzMzMgNTAwIDI3OCA1NTYg NTAwIDcyMiA1MDAgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMjIyXT4+DWVuZG9iag03MiAwIG9iajw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9u dEJCb3hbLTY2NSAtMzI1IDIwMDAgMTAwNl0vRm9udE5hbWUvQXJpYWxNVC9GbGFncyAzMi9TdGVt ViA4OC9DYXBIZWlnaHQgNzE4L1hIZWlnaHQgNTE1L0FzY2VudCA5MDUvRGVzY2VudCAtMjExL0l0 YWxpY0FuZ2xlIDAvRm9udEZhbWlseShBcmlhbCkvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWln aHQgNDAwPj4NZW5kb2JqDTczIDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFst NjI4IC0zNzYgMjAwMCAxMDEwXS9Gb250TmFtZS9BcmlhbC1Cb2xkTVQvRmxhZ3MgMzIvU3RlbVYg MTM4L0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvQXNjZW50IDkwNS9EZXNjZW50IC0yMTEvSXRh bGljQW5nbGUgMC9Gb250RmFtaWx5KEFyaWFsKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdo dCA3MDA+Pg1lbmRvYmoNNzQgMCBvYmo8PC9UeXBlL0V4dEdTdGF0ZS9TQSBmYWxzZS9PUCBmYWxz ZS9TTSAwLjAyL29wIGZhbHNlL09QTSAxPj4NZW5kb2JqDTc1IDAgb2JqPDwvTGVuZ3RoIDU2Ny9G aWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImMlN9vmzAQx9/5K+4RHnBsAwaqqlOattOmRVpX S3vY+oAItEwpIHBUdX/9vnaWpeogmyLB3QXffe6XF5/p/HyxXn24Ik4XF5dXK/I4PXiCGvIW7+8g j96l9hZacxKkay/kjHMuSZfkRAnxGYdJjyS4ff+EpgcoDJ9x/PaSTHIWSc4FpTCk3Er6yfvm3yxv qe4GWjflECi/G7vafJdSjkTBvf7oXWvveg2uxZFVHFgn0IQ4skWW7S2IyDMWSx5lpPKciTTPsz3I ly4Ilf8SiNQvglD4WxOEmdWFHwah9G+GqqK7qt1UAwHirq/Kpm7KIkh803QtAf5TU1btWM2CyxPg b2v6dwEjluDPnFSWslS6E5bbFg5VQ/ja0Mq+h74bCjBBbGdZokkWh5IcUfJJlFQxGXMFFEgi/1PC 5e5hF6T+aEhyBOcxHrMA8TSAjc2nokZcgUjwmJSKmULjEhsVAfSPKf/JpP8TXlFgaZM56VX9l9fc 1TETpGLBMGf/QE3ne/FqLJLJZhxDRdyN8++xuBVnRF8f0YHCUDPa8TSPFfW7oXdrVllLV5Mzuq8q Oy+Gtvshfje/f9ksrlCz7Ttyioyl2X56/aU4szWBF/Gq//t8Y+eGKaFwCvYNsiINSBAXG6xd1x92 D3m4zYTulhP5Nk99Z1UTZH6BtOwdY1xGcxdFzmJYs0MoRGlaG2Znb4PRDC9UtBvcU5hwt3FYt2d4 hv+RTEd1UTbbxqCOrqbBPf0SYAAvOD1fDQplbmRzdHJlYW0NZW5kb2JqDTc2IDAgb2JqPDwvTGVu Z3RoIDY1OC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIl8VEtzmzAQvvMr9lbpABHyA9PJ 5JA4h3YmM+2UW9qDAsJWBkuMhOvh33dXxrHTuuGCtKx2v8ei6msiMiGEhKqGlJZyUUJ1gFTmmchX Ioc0z/J5WUDVJM9MNa4fjONLZsG1MGw1hEHZBgPKN/Ay8pJBZ2ptec6CsRswQwBK17UOQeHKj9DT e9B2AG8224H/qiYYs/yMoyAYssiWcrUsQRz7B3CWyinwblTdMELrtYYXFQwvWODpjIGymNBArJr+ zU4eyZ3KviOnbe32Xm2M5Qu24WnOwCFDH2BwkRSGLYWDJubmjDu/wL2gDs/MI8vh7cTEFCtt1UAE avdb+6jfj5jU4O7Lmr6EngI1USFOLcd3rVB0C8HsTIcxhQm+Gy8pXipHaA6oWCQ3K3C3RnZ4/k21 dFIN6wQTMoBqi0tEZgIctiM8mdq74Nrhp5QyfCQljYmcn+zpDFHTpF9A3BqMrbs97hoSQcdwtKjr aHxim1PwrVu9955mQ1GZycfrKqdT93cu9to2JBzO3ocOKK/BRqkjrhBF5XM2kttm13d6d8F7fm4d actsLgp54k1wj16ejLx0sY3+YUu0wLoBXveB0vG7/nhKpyZnH8/8lv/yU33fTZOCQag7ZXYBNSZL 3slMLtfkStSZrxiOkjqQHq7FWcAnonqsksenB0huvsHt7c3TA7Iq4e7ufo2x+yq5qSoBiKlNBAEX BDlH9CSKmFZlJLbKYTEvs0IKsYRqlzDg1eu18rm4Xv+q+f/vNVtlkk5Qr2f2XX4GWNOVpQPdDJ+i +1v1m+c5/mEzElJFKdFEdIg8pORoY+12R1E1HSKLe+/ijAe8inDR8lQy2OgBDS5ZvO8gXpI6Dq+i nwf+CDAAtMtuWA0KZW5kc3RyZWFtDWVuZG9iag03NyAwIG9ialsvSUNDQmFzZWQgODYgMCBSXQ1l bmRvYmoNNzggMCBvYmo8PC9MZW5ndGggNzUwL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpI iXxU226cMBB95yvmESrhxWa5RVGq5lIplVJVClIfoj54wbvQsniFnaDt13fGLHuJor6APeAzM+ec cfnNCyMWRRHnUFbg1iKGcoTyk/fiyx4eH8qvYKzsg9Sv5VB/Bgh+ld+8h9J7eLoDb/EDrq8XT3eP 94AYNze39xi8Lb1FWUaAoGuPMHlK8BEBc9wLXEaHVeHy5xwSnjCRR1xAufX8L+IqKH8TDD/BXJSZ ODSW8hQPI3SNBQNW+V0zeLRgmiDx9WtXQ68tg7JRuB+CUPgK5KCg1rj/q3p8miD2Qfb1ZSzEoF7D TlrVWxjaTWODwjdgG2mhkW8KVvifUj3UbZD5purwqY2qMQpWTzRN7C5PVVPRoas6ozdfFtlUum3U RLbDD8LU38o9VPpNDRgPcv+gA8GjDoYBPCv1ToznHUp21EPMeizuniOozMQ6gKn6g0Qztx8JI4qU ZcQ5JFHMsqQoclLmxW+s3V0tFuM4slbZNdPDZtHuJnZjnzV2211UdQ7EWYFABXolYWlOsYhlAgbl rS+sFM+lR7C5rHViNDkyygv+UfVLLlicvy8d1noACRUVSlpvd52yCrrWyY02gZ8HSsNYMJ7FGZ9U ooWTiayDhgKJp0c6JOfGyV9kGNnv6YV6BmE2+Ug5F+H3Pgi5bw3KOiVvK2lduo/dLSJWZOls7pZ8 uSHgcyMcvbqb/a0rZU6gZ97LZ6YKcRoZAwqHxkHsaFWRmWXX7WFsFDZL6c6sLE5wk5djlDRaCn7p 5sPU6LFH+yJqI81ZgW9tTWzUxAbyBdKYV/ooqcPqSKabhNbC+D+KOMuWeTJ34wZ+K/+QpthHdZpl dSRKvsm2kysaVwWafkBLDHovO7sP14NyuaeWZ/SL3lbSuIF3YGNrG9CWLhtF7QzoZRLG6J6cseoc Gl0uvUsV1sez1dBu215aPfOyB6uGrXF/kxLugCOJzli8pVrdG2e9KflTWw3a6DXdRxTEC4yOkGDw T4ABAMtBe8UNCmVuZHN0cmVhbQ1lbmRvYmoNNzkgMCBvYmo8PC9MZW5ndGggNjk1L0ZpbHRlci9G bGF0ZURlY29kZT4+c3RyZWFtDQpIiXRUS2+bQBC+8yvmyEqFsMvDJopSNXEOiWSpUZF6aHNYmyXe FrNod5vI/74zgE0SxRd7tMzO95gPqocgiZMkyaDaQgLVK/5EPOZZuuBQrYJwp6yKgVV/grsquFvf QnDxHa6uLta39yvgGVxf36zw8KYKLqqKA15qgoSGcZwrcFoyVcsyLsulKCDLilgsyjKHah+EZ0fn 70cn0+gT2YhKseTE+TxWmsUFlilh/Qof00tgRfhzx6I8PDC+RPioCLUb/tZ6a40zbBE2HqTDxr+6 e4Zemb5VdM8b8JKOFUho9VZh3TEeOvUV2FP18KmO4qwOfHQ0/bwAkcYptg4Cwm/pJdk1Oz2YgP0n P8QwLS54gc7g6BpVw30HhuWhZZEIa0UVoJTemj1qNV7BD9XVysL96gusNYoafEAT0Ji+HZSNQJzP SCkhiSTmJeqYkGi2ZBE5UhOEaRocq72DTm2Vc5KwDzMc9McLXnVYeibC0cmPuvKS4CLB42WyzMaI losR1ernHUIY2gYuxlJxkK0/RI1VCja0ModSNv88mK49EDO/M27Y6evOADVYloW41taZ4VS3Le1+ XPpe4sb9Tmm0y47s6QYJGMnOfFbIp5eoBgnJF6lbvCI3GB8zUFNbmtEPFLcsSkPZIt+3ZPGBdNTk Ypidf2M8H40X8SJb5qcVVztFiWQRquhQmXZUEn+URKWh5YPe98Z62XnyYD32W+Ix7rsx9g1oks+g JR/9n2DnT0QdYKQaxNQvCvVJZzpkDgMhkttbSuznIngaL5JiSk9ottofKJUv2mmcArKryXWQG93S IxqUzJHIphG5KMqjD6jKKqcscjmyYiXGEhMGU0w+aPz47kRiEYs0zfn7jE3fhsb/FkI48rFVe9yy 9JpeLQqvIx8x8uDQ4JqCbevTsbSYtif4L8AAP79oBQ0KZW5kc3RyZWFtDWVuZG9iag04MCAwIG9i ajw8L0xlbmd0aCA2NzEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJfFRbb5swFH7nV5xH Iw2KgQCuqk5t04dWqrRpSHuo9uASp/EUbAZOs/z7nWNyo2r3EjlH8N38HerHIEriJElyqBvwxxTq LaR4qkRZQQL1InhmbyqcsX4Huu1s76RxoNY0aunHhBFnbgBtwG56WOBI0ajRg7YGnIXwV/0YeB7O T0QzYoqOVBGPeS7KkbCxxvU6LNnLxilwqlkZu7aI/ErIOwIdUMdCki5iHOKR5b4O7p/uILj4BldX F093D3PgJVxf385xeFsHF3XNAUUsg4SUJKSBo4QUj8n+VIlYiCrnkM3yOEPVBdRtwCCsf3+IX03x kxF/NJn/nyBP45ILkRPBM/ueXwL8XIUFUwZzLJiFBzBKLcgvRf1XNRscYyQS1rrx6Q8KQl6xbRil M6bDirkVPOmGgrGDXbqvPpeJb7zgIhazlI/3+7kz8aEzMsYLiu9zYxmPszRJU5/cTX5JDCcNY+nE sQvcd4HHBS8qfigdwI0Dt9IDON0q8jQaApxYs96B3MoezWNMy33FTuUacy/jVGT5AbBTZqHNoUTQ UXmcwjLLrsM0paO6NmupWyzeEEYZQ3r/UJgyaOyb6kFj0U91Ts/aLHydeRULjvNJm4fNS6s9Zsb8 TthlKAhcwQ/UhLAP+H+ON8hg6Oj6G72kFxoSQbpwZmKAW9VIzx69px/Xlsc5z9JjghtaDILwKU0C NNbt88PwpMHVHgZ6HLvWSYctolzOqM4XNxsX90A2Xdzz+L6Ml3ZQQdQLS6Ud+Xv1Z0MuUYQ8fEd2 eLXKr7d+Nb7lFIMyEydbPXZ8Co0v4fcJJ+uQM9WSAUp43wyvMivRxhxl+thpRQBrPtBLPvJ9B2xP LJRKJ3tHCWnCkpNE3n0yucA4RDpGD/8EGACuIV7CDQplbmRzdHJlYW0NZW5kb2JqDTgxIDAgb2Jq PDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNlRm9udC9UaW1lc05ld1Jv bWFuUFNNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMzIvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVz Y3JpcHRvciA4MiAwIFIvV2lkdGhzWzI1MF0+Pg1lbmRvYmoNODIgMCBvYmo8PC9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0ZvbnRCQm94Wy01NjggLTMwNyAyMDAwIDEwMDddL0ZvbnROYW1lL1RpbWVzTmV3 Um9tYW5QU01UL0ZsYWdzIDM0L1N0ZW1WIDgyL0NhcEhlaWdodCA2NTYvWEhlaWdodCAwL0FzY2Vu dCA4OTEvRGVzY2VudCAtMjE2L0l0YWxpY0FuZ2xlIDAvRm9udEZhbWlseShUaW1lcyBOZXcgUm9t YW4pL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMD4+DWVuZG9iag04MyAwIG9iajw8 L0xlbmd0aCA2NjAvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJfFRLj5swEL73V8wRpAVh Hsnm3q60lSpVVW7bHrxggrXEprazKf++M2OykEN7SDBj4+819kuiPWjTWjelTWLx59KsSmRQHZaD hecvx3SXPKVZncDVujdtcM0JOifx2QefAzwbSH8dv37KirwoCiHg2AKPywqOV8jEIa/FQeAgF/Vh D8fu00vSWtMvcGVyps1Mq+CqwwBhUAT7BM/ff8BkR93O8E23jpZ7YmcZjtGqDdqe0Moir/cHKCJK H2CQyN9Dp9N94tsR/61HcQSicOZPWqEFQRG67bGMszDhhDL8iTnBitasYAeWtqDdKZvQPBOgHaU+ E2aKzknT3YhMzr6nokh0RxYHD1zeGFivIIQhdnldNuVNkb84SVzDIAPoHvylHQB3iHC7aBCk2S6R TsEJFweFvnVpJpLoorfoylWPI7Dtb2ojcPeBXRUihrfAs8RqLyILzEQZQlOsSb5LTc7K1xFdNOBU FIXRWhwYrlMJbTBcyZY8nD5r2kiuHLYN1BCHlyRYN0NQjv3EjrvvhhhyQzyIhLdwokmj4FXNPOo2 Ejf2PrLEYo3vM0q7dd/Psiw9KkFyvy+an2fMNT0gziu+zNg4FLLT/az/w140efFYPd7yw36K0WHy 0cWGXCT2nIlTiIYqMDzDJ5Jy65Xy8HFawCJHegFnZzkGzZ8/YJNR0NuzWK5cypjmQuauYfuLww3d A+Bxv7WE3JADqr2jXAyZk8R1impunEF2duIOc6sHG9iGz0lZ5ruq3n/0MDXsdbD80H4A9AMZaAe4 l+b+IIzF3GXKkSunAW1bBYpydZvHdCQXrPuG5Ysltj9dZfEIYMkpfp/IV9XSMER5pE2fp1Fx6P+2 FG8AUe1v0uCvAAMAWK9xZg0KZW5kc3RyZWFtDWVuZG9iag04NCAwIG9iajw8L0xlbmd0aCA2OTAv RmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJhJRNb9swDIbv/hU82sDiWLZjJ0XRYf04dECB DTOwQ7CDbCmNNlnKZLlD/v1IOWnSrVsvFi3afMSXpGLulTXJIh6SWRGn0Ox3quNa72HHvSSHh63V QroBhAXasMmM4W7Pf0jwW6mSKnaQfGs+RrMszbKsYNB0EOycof0LZnmWsqKuYcZSVq5qaES0jrXq AmDAMNL1A/AnrjRvtYTReAqrgW/QRRQYPA+MgMhPhMWKCKxO63K5gGwKbQR3ArYcYwzQSlykAS4s GjsvBZDDiIA5YygXkiaffyOhI+9FQp3mqickSYn0Jwkt5ieR/ei4QfA70HQW/qTMI0iOTodKq36n ZS/xzQRpSeszPDvDF0TPS1ST1cdkvYVhR393xB01pgBI4QOgh6QbtVc97ZLMSY2S2E1wnEHKE2Oq 2IEREixqRqipYoNMAZLme3TXRHcPNxDNP8Hl5fzh5v4W8gyurq5vcfO6ieZNkwP+uIkyCp6FOuW4 ZrSs8LnEvT6K/x2OvQyXTeFmf/ZAODJD8xA9WASo6nRVEmMdf15cAHzdkjAeBC4W7sFIbAZUaXrf WAetMtwlsyreJ6yOgSxuxBw9gx0dftZRRalM0FkhQajBO9WONEXvJ0FfSyR/NRE6PKtO4rySwaJK y2WWVUGoD4sLUgoDsHMl/moQllasWrJjgwA8UKuZPdgdnd5gLriOrpNwKOkATv4cFTaHo06CvR1J F2U6fZq6xQkThg6nul5V5REzkooSZdntHUV63Hq8L1BYj4wwiZNY6GpHfKdBVCY0IkoZ/n3jFsnT khXYFOdNuY6VH6TegBISx3mzp9GimHz0W0rTPbc7UY7FayV9998py9KCsefsBJ071Jqko3sxyWMp cBbgi+0lSht0PYiK3x4uN5pJeTSAa4piEQy/BRgA41Bugg0KZW5kc3RyZWFtDWVuZG9iag04NSAw IG9iajw8L0xlbmd0aCA1NTIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJZFNNb5wwEL3v r5ijLQWE+dhlz22kqFJu3KoeiPEKq2A3xgTtv+/MsATSHsDjr3nz3hs3P05ZmmVZCY2GhMK8VtAs kORZWihVQqJSVV4v0HSnnyKY99nKC45w9zNEL88CrNPD3GFkIPYGBquNw9lkYMbBdQb/AZaeLmqZ FKIH+atB4B2zJEhErIr8CtmKRQDByEpoYz9Mx7m1x3mHn5GJErDY2B/WCb+NXBkDcO5MqR2n2Kgx 0BdqnZ1isG+YZ6bc0cDkIcpaUMrOLw63qZqWdkeYJ5oEWYoJ/I2LWEkRZHGAvBCkqtOaWD6oadIN y21Rx7GlAOeLTHJBQaAA053FI3E0YZz4jOuA77rORutZ5QPskWnFTDdcZlpc1Ao/kyfVv55EeRW9 uYNuHRpXiYmWzWN5UzgFeLU6+MnfSBUzgcN1z4rBoTtad8d74HzEbgAfwMd+sy1AG0nqGSngmjt0 Q7Z78h0LXXqq07HX5Cp6pAe6M3HOjsDINRwwG/dkADv+wRODVMKMxsU22kMz5LtCOfecQoHqT2O8 A0vyMuKbdW24w82HMcU+AHjxi/lg5Z7A3v6riAwLx867XD/R1HntvAfcVz8wiUxKEWUuWJadyLBR oMIc8DFCm4OmcH0FiKvXDZxhM1HBexUq37uCYySdp0V1LTbST7DQy7HuN2UBG2GthwrwIbYuUsrH g6fXTpsDgc3Uuivj5+b0/PoNTvBXgAEA/dIrNw0KZW5kc3RyZWFtDWVuZG9iag04NiAwIG9iajw8 L0xlbmd0aCAyNTc1L0ZpbHRlci9GbGF0ZURlY29kZS9OIDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+ c3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJCAESQkjYBUFEBRRFRISq lTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem0+8f7/c593fv793fvfed8wCgJ6Wq tdUwCwCN1qDPSozFFhUUYqQJAAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+J LdfpDQBAGTgHKJS1cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKj MPFpnFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7 XPoOG5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4 kYNFocHBQn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sA MPG+Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo2 6rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4Y68B r9gHsC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0 WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsYA7vB fnAQjIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEsqAAqgVSQ FjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7wb6wGI6BU+AceAmsgmvg JrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelGBpFRZD9yDDmLXEEm kUfIC5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbgRQgjSAmLCCpCPaGLMEjY SfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolkRfIiRZDSSTKSgdRF2kLa R/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAorpQwSjpFQWmk9FHGKMcoFynTlFdU NlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh2u9on9OmaC/oHLonXUIvohvp6+gf0o/T v6I/YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXm IxaF5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K 7hj3DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJi jcV+i8sWzyxtLKMtlZbdlgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsc tLlpC9t62mbZNtt+YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMx WBU2hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS47HW56UpxFbuW u252Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96 wV7BXmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8t EUeULOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4QYhL SEnIeyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3QinCFnEjojJ SCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6HxCXGdcdNxHPi c+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9OoadkpwynfJPqmapPPZYG pyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3ZT3Nic/pybuW6 5xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MXb1o8XRRU1FV0fYlgScOS c0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIVA4oHyghlv/JeWURZf9l9 VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0R7UcbaX2dLV9dUP1JZ2Xrks3 WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V59Yca2A3ahguNno1rGu81JTT9phlt ljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c 22XWpe+6sSp81fbV6Gr16ok1AWu2rHndrej+osevZ7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa 9dc3RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvODQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia 1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9 p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660 JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFn wePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfP uNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c 3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHt nO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p /br+S/7c/23//wIMAPeE8/sKDQplbmRzdHJlYW0NZW5kb2JqDTg3IDAgb2JqPDwvVVJJKGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaXByLmh0bWwpL1MvVVJJPj4NZW5kb2JqDTEgMCBvYmo8PC9Bbm5vdHMg MiAwIFIvQ29udGVudHMgMyAwIFIvVHlwZS9QYWdlL1BhcmVudCAxMSAwIFIvUm90YXRlIDAvTWVk aWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlczw8L0NvbG9y U3BhY2U8PC9DUzAgNzcgMCBSPj4vRm9udDw8L1RUMiA3IDAgUi9UVDAgNzEgMCBSL1RUMSA3MCAw IFIvVFQzIDgxIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzAgNzQgMCBS Pj4+Pi9TdHJ1Y3RQYXJlbnRzIDI+Pg1lbmRvYmoNMiAwIG9ials2IDAgUl0NZW5kb2JqDTMgMCBv Ymo8PC9MZW5ndGggMzcyNC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImUV9tu48gRffdX 9KMEjCjeKU4WO5id2Q0cxIg3VjAI1nmgqZbUMS8KSVmjfH1OVTdvoqxBAAMmKbLrdurUqeWj+Omn 5cOX+6/CFj///MvXL+LOFrs7Ryhxt/zzE67ru1/Wd8v12haOWG/x6zoVC9uybdcX6xM+E+taODb9 /y/u1hVuLNvFpW2uYltEuIpC28YR+d0fs0PSyKIRSdNU6uXYzFczVRbiebatylzMw1kt58EstfBc uJYryq0oj5WoSjw9J1lzXsz/tf7LHTlhB70/Mfnj2pazCkKHXNnA1LaSUsDePJ6RyUylstAWwtnz XKhCnOnsusT9sUrpsUjLjRQJrooNvcDG2ITtOL05j8wtOnsLx3L8ONJW04x8recLbwbrVfld5ao5 i6YUzV5qJ2opjsWGAq3Eaa/m0Syde7O96EMbGgvImLOywtgP29DguMiTVynOCE4HcaTj5gt3lkpE gRsK5C1RWfKSSQuv6eN/Xd/9+oBSL/vyO235p9W22fa0qOEqsqKVKSpOXv/72sHu+GBHH6zT6Q0i pGivm4lCy4njVayx83v4UYhv+/PccWZiU4p7sU/mi2j2Rg/kfIGnSLMq0uyI4B9UWpVc3G3z7Lpu DSwgLQ2DoKH6dCgkCCYZvVrsxNxxZyckMpgpoLDZo274oS+d2mrDQWc3MrmdNkiHjK9wP8kqmWzm i3CGCPANHC3prjqUFbpi0xrSXhEo2TFF/opcR406V1zgjfzENpFXtysYkmgy6AovCKwwiuNYhKFv hSvulxvF8q4Wi4JxQorrWnkCz3JhIuKDP4cf6egBgq4j2QqdcNU1qRAPlMriLMoD/suC+jHgfuwy XhbZWSBzwHRFXVPXxBRpeSD0V2qHR3uqflNbg4517N60w/VwPcsPAjvubN83QqFTfeDmfFApXSXU QhnhaKvAAfyspGeHMyztmxFmWoa4HikgZNmRE4/5gVjgnW6FvQKXJcfSoXVkEhGKJwBHEpv0PEO5 GCbCkF2g6bQWJ5Vlw7OTjckkeKcesty0LS9ArPm7FopSJxTqkAO+DdewobQlMC6TutH8RNGypVQd 1I1cubDhRVFbGfqi0CWlUmMKTNPGECBQ6M5PTkkFe0DEHi5cef1WkIvWPsfqRY7h8sH5OBEg5FgQ USrVm6KE7hAnzaaOdgjFCbuOPKGp7x9Rsqv04Lqw6XQx3/MBCgxEzo+OGSKA7J8U05IclHkARHeQ 21hHZyyNgKiaWmZbLhNNRVSUhsRGbbcqPWZcy/JNVllJvPhKOCPslTn68YA2pW+Q4LBL8Gi+1nAv YZ71mKo14EIDOCMCuKFgtL7VRRf44zSbfgHsKfgNpUlxQ+JPI47hFvHcb1o8GBzOndlB9QATL/RL feCjavWS0WeU5G1ZifKlSVRBNYHvJxwk32SLqYG0uCUT7AGmKAAOmvsn5/AhdApJ5F+KYy0NcFsG NNSAxP8Gb25IH8fyHc/tWJVz3eegJh1Vl9uGe+RIVdrQGxXMlVwVxDOpoG7xq9BddAZHkDrIat/i 9tCyk0DOGLV5CeMKdEEZpMATpI6yjJhzih+VyJPNqFUHWHZNzwRu2DE4td6JjHDvX2/8ll7bBtbd iwjfgEUu7e3OYXuXvHAkmGy46XFBfY8DNaxNz6/3ctC2JC1oXHBq0+YHVDgMEZB2EYAFZ109CatE 1S15a9orzFRsM6CqNmrK+yCdPW6cuCO+PsC2jnnS8hnRX6ukWhl1//gnwsamlLUoyobCotEFiF2n uTG1a9oh2BMUalLbphUhAV4ytUt0J7dPKbFJcS4LSRCR36nl0mMzRIkWKDrCKJ7yeRtWQgifL0hl 1PyP25g6m/j0Qf9W8cTn3xFxy91XBJM/FkzeRDZ3UgxSKXCN+npPfgU3tDLF1JYtfEcqB45rxb5t h0YqR5DK9/Vl6VpFlZY5wAqyQxodbyx3n2Sxyak7VfZBPJZ1s1XfucC/53j0SQiTkpHynMTs+5Du 4ditd7Vn+P9rz8AGA0F7rrT2jC605ztkPBGfKP63vUIaJMEw3Q9UKBOwJs2WTUYDl5pkQwS73crq gzhJ8FfGg+VN0mYp0qTQL9SaBfhpNz1u65HW0fHEzg+ZzPvRpTsFqyS5XGkhwkL6uv+e9r+nnqHd yAhkD6K+U2H9MPiAk0S7ISU1x8eLScd/zX6yuQxC9HtLuj+NpTGv1o06HDOwaDvVNWWmlnAtlwjm As5/L89JxirjGvE4K8sL4i6a8+K3SkqCN59udF0lgL9HrUf+iuJSClHczztWC8h2AQ74J6Lt0zaI ZWWqZSyNqlXzaD1mWCL2zPqvHdUge9AWdEdQ4P0uk7skI9bGJzrtlFgsm9dDi7FZRKsOx1SOfQLc /ecoaxo3BiI1s+sLXbKmMOof0qVqSOXBRKKzMATND6BpbI+DneLM9AkYtKsafNQj44WTq1UBTfzk dGtIYQiP1A0NcYABU0HUBxZ1ZFRBtxIm3xcPsYWdsO/+lgQVQQj6EePsRTYnKYvbI9PDyETkqwvw kjtmUTE0W4tjt6J1iMYQ2yhmhK4gUnMuE+7A8oT23daeCeCRasr8/EFARjE/693gZhJCP+ymMZem dbLrq4r6qjkvtroJLkRENHBLT1vPtqLY9i/VoO6qzHQV4xFweG+eRu0QWH55skVaM9/bFog+DoSo 08JMB3sydCbTgbk/EL5rW3EQr1Y3h8+qtWuL3bXpe0Fd71uzY8v34lVgJvAKE/gbCTK1Ffekd+aO ayYtE3XTSn4isL3GgGQ6Av/dQAH6L/LdoIfxviizcneeOzZsLABlamRa03AqCUFI0u8NCLxRWQbx S/zK68ZAQNlOl81Fd/6gmCBCYGs8YrkAkMeBbbSqzvBl+qYLkeVGgd+5j8EoaG9IDpoa4CCJD90Y G05OybkZ5KTXe86KUxJYRIzaC84hZMo3CrennvqIkS0/vYeC+AcS5AbSwJHeKrT8wNR+9nl1VY1c duJEjDzQVjLqR1JktISBqnLV6LlIpTuV1Wu7lVK/4/dbOyhKGgChdtuXBe+FNSt3fJtlCZFRyZMA jIg5coK4gZ2B3OnmR/XDhcLxnGhEjrN7YDDLZNocMeQeKwybqjmLZ5wrxwV5gnNdTRz7GiU418lg Wh3X9iyf0iG8yDTlvmkOH5fL0+lk5SbZBA6Lt6V8mddpWR2W6rAckdTwIM9y+coJbSuENSvCvQfU 3m2HcEIJJqwyBIPTswo339R7L/QtJDWOe++f5xim91BB80UEtY5apLSsdBuLTwwOuNCV2FUJ76KG hW8snAs3sjw/8i7ou1K7fWN2SkpVycq2Ei1XadGJWOvDTcHwx2w0orVofZ6lxwqLa0Oz90yLLPTH BpDGq89zWi9vjDB3BVrv5cCJGj1PXkmDdr0jBfzHzZ6JBDroLeE5n/DOc01TLdpjL8Z6A1oSqR61 Yos522+jKkcfsSZHhhPWlczoOkXvy18IGs9x/DaAqSC9kDWcs1ZIcYQ8rAVHXsgBnU+DMqbGak3y 1DlRaYEPsAwFYAo+2HbwjoZRp15ezhzcP56gmW9VyLE8O+gCbHR+NmJdQe3lrDqNkVfxty0i5HTK N0iv14IiPP2P83LrTRsIovBf8VMVpARhwDV+qqqmkSLlIWor9dkxC13FN3m5yP++58zuGhuCUfvS EJF6PDNnznzD1KXaZOF9M4DS3kaMvOdIuEGSkp3NSQZCC37KR8SqeLWhpD91KUOk+L0bHdxZlZGP +i3/sKwACxBpmHSXEh8pGkGxcKVh5pDNJMGEtAEfxgfBckUdgETEGozQxXR2AYZidMMsWeHphlcn zkwKCKtTZiC1w8p9gb8oJqH0dl8HmwYkcGNSmQa0l0F0fIo0wcEsqKQp2AwU7TeqVR40ksQsIArH YWz/zE6deeQdiyIJWRoaFJYQjx6jmcX2XOMWSJ9fZdzKsjqkEnXNao/Nl+VR156iVju+smi3SJt3 tUOP/IQhNUyAbD8uUvwqR+W7ZC+MhpSvUWs4H4LDTTpdJVOYOph0niynyxj+Pgan4eIqlwwaGI+H Ws0FhGOHpomgaUsglZPMURKS3ojXU2b4Ucq/6x6ZYqLSPEfHv4xUZPk/KHV61zicLvExtCiVfIhS l4RzxlIvJBxMA71GOgvvVpRd3fCb7iaTD2DjAml5B8/TZqvug+OfPiJfnAGk5FXHVAXVhHhGb0s3 PPDNgB/k8Dkos5MtYdXeKKOcBS4A8CLoW1S1+Bwthg63hmHmVc2pxKPvg/NjLmgstEV3u8kcU6fy 1uEA0Q9my7VieuZzoSgMUhLPZp3PpXz3CXzRkD7hKPidFgNDM8GPT4+B2sCzxZowM78wbZXUe6tL gN/VDWVjDK3uGzrCDjWQlOjRnZBQYF3nbifyMj1CwBudw0lyMWC6iN1VCu9ySq63o6LEmXi06olG EcBjz4TwibVz0zUM0YtGM+WyZ/eNxgWjpADjHfTRBi3sZ+mXfp+TEIee9fz91xMK+so6gP1KKcLY /sWR1SP+XrkkCQz9gbkB52jfKBy6WYtasm4ypMU7XVi7pZKpomB0gzz4wEPc2FlCa9GSwEC0DcTQ qrQxrK60yfKI4vY/YvKUnK4jFx9EE8XLpOsd9lCQ5akujL2JEA+xPANXllqziqG3soHts7vHnDEf nmb2mMtMkJG5FxR08Axm5X7kjXTfOy4l4I0LDAvpxKx+qfLxpZ9KhgMa6WIMdmCXydyL9k7oHAdi qTJlTNrI1UbH/FgXD4vZdLWYn6M+gIcQexoxz/giTQekfSiw4qz8f4CUmqpN891YCWBhfcdsYR/A 0LfUdLMV7MWA3Y1x7mbY0YQBuA2sRqK1wZNghHCz76iLMshvkMqrrfWLP20tAiCzr1u8EBcGv0YZ HeePCh7hsMM7zmU3jtU+l7WZ63fhQvY4y1TNsqJVuVSR3Z9e36HRP1JFIu+HQzSMk2kUulU/xIq/ AgwAFBlroQ0KZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9G b250QkJveFstNTU4IC0zMDcgMjAwMCAxMDI2XS9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFMtQm9s ZE1UL0ZsYWdzIDM0L1N0ZW1WIDEzNi9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgMC9Bc2NlbnQgODkx L0Rlc2NlbnQgLTIxNi9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9G b250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDA+Pg1lbmRvYmoNNSAwIG9iajw8L1VSSSho dHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vbXNjb3JwL2lwLykvUy9VUkk+Pg1lbmRvYmoNNiAwIG9i ajw8L0gvSS9UeXBlL0Fubm90L1JlY3RbMjAzLjQwMDAwOSAzNzEuNzQzNTMgMzY0LjAyMzQzOCAz ODUuMDgwMDc4XS9Cb3JkZXJbMCAwIDBdL0JTPDwvVyAwL1R5cGUvQm9yZGVyL1MvUz4+L1N1YnR5 cGUvTGluay9BIDUgMCBSL1N0cnVjdFBhcmVudCAzPj4NZW5kb2JqDTcgMCBvYmo8PC9UeXBlL0Zv bnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L1RpbWVzTmV3Um9tYW5QUy1Cb2xk TVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDMyL1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0 b3IgNCAwIFIvV2lkdGhzWzI1MF0+Pg1lbmRvYmoNOCAwIG9iajw8L0xlbmd0aCA4OTIvRmlsdGVy L0ZsYXRlRGVjb2RlL1R5cGUvT2JqU3RtL0ZpcnN0IDM5MC9OIDUwPj5zdHJlYW0NCnja1JZNb9s4 EIb/ygC97B665PBLElAYSJymzTqJA9vFHowcFIdx3dqSociL5N/3pSjbCXpoCHQPC8gaDfXOM+Rw LJANSWJLLBWxI53hMSNdaOKcjC6IC3JFQUpS7pgUU6EU4WKpLSnIZGFIGWI2UCFa4aYcrIOfEWvW pHJYm5ECz0gmjZzGWNIMmxekwbNaEy62GfKD55AEKdg5+OBlDB+8DBwNXs6Gwvxy5DHgFZiEAa/I 4GOKEhCD1BJ8gykiISGl4uA7LCG8x5RU0OdYSojHlHUmyUosCeWwWLFxiix4VuZkwbPWEC7lJHRh qYBZ8FwBHXgZJmfByxxsKEGRkwMvRxFCBXO8BFLlOSx4BQr94YOYPW+9mLbNbtHOGu8ndd2KUdgZ SRMxXJePj1flNmxR8G/KxledLuzW65Fr/9SO/DMZManXvgvKg2QwQJbLslr+8fH6/afTP8VorrsX oYrBoIid4WhUNDoaE42NxkWTRdNTei/CbITZCLMRZiPMRpiNMBthKg6qOKj6wchUMYOKaB3ROqJ1 RKuI1r2JMB1huoPdihs0W1esqZj6RdsV5LpuNuU6bMS+RNe7zeM89FMXy6HzuwSh9zta6P7A69Tj XbteVdi5bVmJL9W9b45uZIsbMcOWnNZP4mz1rzhvyo2PT9jiqm49dLh9rO6PzvRriW44Xy13jRcX VUC+GpqNT/AbBnsRHsLtvB8570emu61vHhfNatvG6Ux3d6/ctll99/Wud8+aejsst/sMw3qzQUO9 U3LiHzx6a9Ev6jP6NKzxe+cOBv9JE/U1/y0tdYtdGs1Z7f9j49O/J2J89w2ftbjnoTFiJjTGZVjZ zZJcFl/Of09fqjd3aZyt/Hm2x8lGyovJ8qF5R/Nin4v5VgwPPbj/kkwPI6/D1KE+V8MJfhdnJF9o foXalyuwiN+el1SCVidoTYLWJmhdgjZL0OYJWk4pGqdUjVPKxgl1m/PhQ8o6qZmkOJm7+MFN60GE cXKYCmEyOUwjzBbJYSaE5clhNoRlyWEuRZyliPMUcZG0jTJJbZLUNkmdVD5Oqh8nFZCTKqiSKqj4 7eoxTpPP4fwQjjcn69WyEkMcGXzzf3j7T7NqV9Xyqr734rKZ3eE4VDbtBQ5wVUvyLxnOYy+8I6zT hbPPwp/6h7rx3fvOP3lAmoP8GD0Y/BBgAG0YbsINCmVuZHN0cmVhbQ1lbmRvYmoNOSAwIG9iajw8 L051bXNbMCAxMCAwIFJdPj4NZW5kb2JqDTEwIDAgb2JqPDwvUy9EPj4NZW5kb2JqDTExIDAgb2Jq PDwvQ291bnQgMi9LaWRzWzY3IDAgUiAxIDAgUl0vVHlwZS9QYWdlcz4+DWVuZG9iag0xMiAwIG9i ajw8L0xlbmd0aCAzOTIyL1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUw+PnN0cmVhbQ0KPD94cGFj a2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14 YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4NCjx4OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0 YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4NCjxyZGY6 UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5z IycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+DQo8cmRmOkRlc2NyaXB0 aW9uIHJkZjphYm91dD0ndXVpZDozZjJjZTdjMy1hZjM5LTQxMTYtODI3ZS02MTdmNWUyZTFhOWQn IHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOlByb2R1Y2VyPSdB Y3JvYmF0IERpc3RpbGxlciA2LjAgKFdpbmRvd3MpJz48L3JkZjpEZXNjcmlwdGlvbj4NCjxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjNmMmNlN2MzLWFmMzktNDExNi04MjdlLTYxN2Y1 ZTJlMWE5ZCcgeG1sbnM6cGRmeD0naHR0cDovL25zLmFkb2JlLmNvbS9wZGZ4LzEuMy8nIHBkZng6 Q29tcGFueT0nTWljcm9zb2Z0IENvcnBvcmF0aW9uJyBwZGZ4OlNvdXJjZU1vZGlmaWVkPSdEOjIw MDQwODI0MDE0MzUwJy8+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDozZjJjZTdj My1hZjM5LTQxMTYtODI3ZS02MTdmNWUyZTFhOWQnIHhtbG5zOnBob3Rvc2hvcD0naHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyc+PHBob3Rvc2hvcDpoZWFkbGluZT48cmRmOlNlcT48 cmRmOmxpPjwvcmRmOmxpPjwvcmRmOlNlcT48L3Bob3Rvc2hvcDpoZWFkbGluZT48L3JkZjpEZXNj cmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjNmMmNlN2MzLWFmMzkt NDExNi04MjdlLTYxN2Y1ZTJlMWE5ZCcgeG1sbnM6eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hh cC8xLjAvJyB4YXA6Q3JlYXRvclRvb2w9J0Fjcm9iYXQgUERGTWFrZXIgNi4wIGZvciBXb3JkJyB4 YXA6TW9kaWZ5RGF0ZT0nMjAwNC0wOC0yM1QxODo0NDo1NS0wNzowMCcgeGFwOkNyZWF0ZURhdGU9 JzIwMDQtMDgtMjNUMTg6NDQ6NDItMDc6MDAnIHhhcDpNZXRhZGF0YURhdGU9JzIwMDQtMDgtMjNU MTg6NDQ6NTUtMDc6MDAnPjwvcmRmOkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6 YWJvdXQ9J3V1aWQ6M2YyY2U3YzMtYWYzOS00MTE2LTgyN2UtNjE3ZjVlMmUxYTlkJyB4bWxuczp4 YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0n dXVpZDphMTM0ZTBjMi1jM2ViLTQ4YmUtODQ2Yy1kYjdiNzdmOWZiYzAnPjx4YXBNTTpWZXJzaW9u SUQ+PHJkZjpTZXE+PHJkZjpsaT4zPC9yZGY6bGk+PC9yZGY6U2VxPjwveGFwTU06VmVyc2lvbklE PjwvcmRmOkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6M2Yy Y2U3YzMtYWYzOS00MTE2LTgyN2UtNjE3ZjVlMmUxYTlkJyB4bWxuczpkYz0naHR0cDovL3B1cmwu b3JnL2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0 bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5RMWE8L3JkZjpsaT48L3Jk ZjpBbHQ+PC9kYzp0aXRsZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48cmRmOmxpPkFsYW4gSGFydmV5 PC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48ZGM6c3ViamVjdD48cmRmOlNlcT48cmRm OmxpPjwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOnN1YmplY3Q+PC9yZGY6RGVzY3JpcHRpb24+DQo8 L3JkZjpSREY+DQo8L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/Pg0KZW5kc3RyZWFtDWVuZG9i ag0xMyAwIG9iajw8L01vZERhdGUoRDoyMDA0MDgyMzE4NDQ1NS0wNycwMCcpL0NyZWF0aW9uRGF0 ZShEOjIwMDQwODIzMTg0NDQyLTA3JzAwJykvVGl0bGUoUTFhKS9DcmVhdG9yKEFjcm9iYXQgUERG TWFrZXIgNi4wIGZvciBXb3JkKS9Qcm9kdWNlcihBY3JvYmF0IERpc3RpbGxlciA2LjAgXChXaW5k b3dzXCkpL0F1dGhvcihBbGFuIEhhcnZleSkvQ29tcGFueShNaWNyb3NvZnQgQ29ycG9yYXRpb24p L1NvdXJjZU1vZGlmaWVkKEQ6MjAwNDA4MjQwMTQzNTApPj4NZW5kb2JqDXhyZWYNCjAgNjQNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAxMjQwOSAwMDAwMCBuDQowMDAwMDEyNjg0IDAwMDAwIG4N CjAwMDAwMTI3MDYgMDAwMDAgbg0KMDAwMDAxNjQ5OSAwMDAwMCBuDQowMDAwMDE2NzQzIDAwMDAw IG4NCjAwMDAwMTY4MDkgMDAwMDAgbg0KMDAwMDAxNjk2OSAwMDAwMCBuDQowMDAwMDE3MTMwIDAw MDAwIG4NCjAwMDAwMTgxMTcgMDAwMDAgbg0KMDAwMDAxODE1MSAwMDAwMCBuDQowMDAwMDE4MTc1 IDAwMDAwIG4NCjAwMDAwMTgyMzMgMDAwMDAgbg0KMDAwMDAyMjIzMiAwMDAwMCBuDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KdHJhaWxlcg0KPDwvU2l6ZSA2ND4+DQpzdGFydHhyZWYN CjExNg0KJSVFT0YNCg== ------_=_NextPart_001_01C4897E.2E71592E-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 22:25:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08822 for ; Mon, 23 Aug 2004 22:25:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O21M9p059246; Mon, 23 Aug 2004 19:01: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 i7O21M17059245; Mon, 23 Aug 2004 19:01:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O21Mr9059238 for ; Mon, 23 Aug 2004 19:01:22 -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); Mon, 23 Aug 2004 19:01:28 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Aug 2004 19:01:28 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Aug 2004 19:01:28 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 19:01:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination Date: Mon, 23 Aug 2004 19:01:28 -0700 Message-ID: Thread-Topic: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination thread-index: AcSGLJWeL6hF8tk7QNSysIB0ziktdgDQikrwAAIlNRA= From: "Harry Katz" To: "IETF MARID List" X-OriginalArrivalTime: 24 Aug 2004 02:01:19.0408 (UTC) FILETIME=[3F4C8300:01C4897E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7O21Mr9059239 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The following IPR disclosure statement was sent to statements@ietf.org earlier today. Please contact stdsreq@microsoft.com with any questions you may have. ---------------------------------------------------------------- This document is an IETF Patent Disclosure and Licensing Declaration Template and is submitted to inform the IETF of a) patent information regarding the IETF document or contribution listed in Section IV, and b) a Patent Holder's intention with respect to the licensing of its necessary patent claims. No actual license is implied by submission of this template. Please complete and submit a separate template for each IETF document or contribution to which the disclosed patent information relates. I. Patent Holder/Applicant ("Patent Holder") Legal Name: Microsoft Corporation II. Patent Holder's Contact for License Application Name: Microsoft Standards Inquiries Title: Department: Address: One Microsoft Way, Redmond, WA 98052 Telephone: Fax: Email: stdsreq@microsoft.com III. Contact Information for the IETF Participant Whose Personal Belief Triggered the Disclosure in this Template (Optional) Name: Harry Katz Title: Department: Address: Telephone: Fax: Email: IV. IETF Document or Contribution to Which Patent Disclosure Relates Title: 1) Sender ID: Authenticating E-mail 2) Purported Responsible Address in E-mail Messages RFC Number or I-D Tag: 1) draft-ietf-marid-core-03.txt 2) draft-ietf-marid-pra-00.txt Other Designations: V. Disclosure of Patent Information (i.e., patents or patent applications required to be disclosed by Section 6 of RFC 3668) A. For granted patents or published pending patent applications, please provide the following information: Patent, Serial, Publication, Registration, or Application/File number(s): Date(s) granted or applied for (YYYY-MM-DD): Country(ies): B. Does your disclosure relate to an unpublished pending patent application? Select one: Yes ___X___ No ______ C. If an Internet-Draft or RFC includes multiple parts and it is not reasonably apparent which part of such Internet-Draft or RFC is alleged to be covered by the patent information disclosed in Section V(A) or V(B), it is helpful if the discloser identifies here the sections of the Internet-Draft or RFC that are alleged to be so covered. Both Sender ID: Authenticating E-mail and Purported Responsible Address in E-mail Messages in combination. VI. Licensing Declaration The Patent Holder states that its position with respect to licensing any patent claims contained in the patent(s) or patent application(s) disclosed above that would necessarily be infringed by implementation of the technology required by the relevant IETF specification ("Necessary Patent Claims"), for the purpose of implementing such specification, is as follows (select one licensing declaration option only): a) ___ No License Required for Implementers Check here if commitment to forgo a license is limited solely to standards-track RFCs ___ 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 ___ c) ___ Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee Check here if this commitment to license is limited solely to standards-track RFCs ___ d) ___ Licensing Declaration to be Provided Later (implies a willingness to commit to the provisions of a), b), or c) above; otherwise, the next option - "Unwilling to Commit to the Provisions of a), b), or c) Above" - must be selected) e) ___ Unwilling to Commit to the Provisions of a), b), or c) Above NOTE: The individual submitting this template represents and warrants that he or she is authorized by the Patent Holder to agree to the above-selected licensing declaration. VII. Contact Information of Submitter of this Form (if different from IETF Participant in Section III above) Name: Microsoft Standards Inquiries Title: Department: Address: One Microsoft Way, Redmond, WA 98052 Telephone: Fax: Email: stdsreq@microsoft.com VIII. Other Notes: ** A license to implement these specifications will be made available at http://www.microsoft.com/mscorp/standards on or before September 15, 2004. From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 22:48: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 WAA10025 for ; Mon, 23 Aug 2004 22:48: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 i7O2OG8S060879; Mon, 23 Aug 2004 19:24: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 i7O2OGYj060878; Mon, 23 Aug 2004 19:24:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O2OFHV060872 for ; Mon, 23 Aug 2004 19:24:15 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7O2VAs3016941; Mon, 23 Aug 2004 19:31:10 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7O2VAS8016938; Mon, 23 Aug 2004 19:31:10 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 23 Aug 2004 19:31:10 -0700 (PDT) From: "william(at)elan.net" To: Harry Katz cc: IETF MARID List Subject: Re: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This implies that patent rights may exist only if the two documents are used in combination. Would you comment on if the same IPR disclosure would still be valid if any of the documents (i.e. ietf-marid-core and ietf-marid-pra) are used and considered by this or any other IETF WG separately? On Mon, 23 Aug 2004, Harry Katz wrote: > > The following IPR disclosure statement was sent to statements@ietf.org > earlier today. > > Please contact stdsreq@microsoft.com with any questions you may have. > > ---------------------------------------------------------------- > > This document is an IETF Patent Disclosure and Licensing Declaration > Template and is submitted to inform the IETF of a) patent information > regarding the IETF document or contribution listed in Section IV, and > b) a Patent Holder's intention with respect to the licensing of its > necessary patent claims. No actual license is implied by submission > of this template. Please complete and submit a separate template for > each IETF document or contribution to which the disclosed patent > information relates. > > > I. Patent Holder/Applicant ("Patent Holder") > > Legal Name: Microsoft Corporation > > II. Patent Holder's Contact for License Application > > Name: Microsoft Standards Inquiries > > Title: > > Department: > > Address: One Microsoft Way, Redmond, WA 98052 > > > Telephone: > > Fax: > > Email: stdsreq@microsoft.com > > III. Contact Information for the IETF Participant Whose Personal > Belief Triggered the Disclosure in this Template (Optional) > > Name: Harry Katz > > Title: > > Department: > > Address: > > > Telephone: > > Fax: > > Email: > > IV. IETF Document or Contribution to Which Patent Disclosure Relates > > > Title: 1) Sender ID: Authenticating E-mail > 2) Purported Responsible Address in E-mail Messages > > > RFC Number or I-D Tag: 1) draft-ietf-marid-core-03.txt > 2) draft-ietf-marid-pra-00.txt > > > Other Designations: > > > > V. Disclosure of Patent Information (i.e., patents or patent > applications required to be disclosed by Section 6 of RFC 3668) > > A. For granted patents or published pending patent applications, > please provide the following information: > > Patent, Serial, Publication, Registration, or Application/File > number(s): > > > Date(s) granted or applied for (YYYY-MM-DD): > > Country(ies): > > > B. Does your disclosure relate to an unpublished pending patent > application? > > Select one: Yes ___X___ No ______ > > C. If an Internet-Draft or RFC includes multiple parts and it is not > reasonably apparent which part of such Internet-Draft or RFC is > alleged to be covered by the patent information disclosed in Section > V(A) or V(B), it is helpful if the discloser identifies here the > sections of the Internet-Draft or RFC that are alleged to be so > covered. > > Both Sender ID: Authenticating E-mail > and Purported Responsible Address in E-mail Messages > in combination. > > VI. Licensing Declaration > > The Patent Holder states that its position with respect to licensing > any patent claims contained in the patent(s) or patent application(s) > disclosed above that would necessarily be infringed by implementation > of the technology required by the relevant IETF specification > ("Necessary Patent Claims"), for the purpose of implementing such > specification, is as follows (select one licensing declaration option > only): > > a) ___ No License Required for Implementers > Check here if commitment to forgo a license is limited > solely to standards-track RFCs ___ > > 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 ___ > > > c) ___ Reasonable and Non-Discriminatory License to All > Implementers with Possible Royalty/Fee > Check here if this commitment to license is limited solely > to standards-track RFCs ___ > > d) ___ Licensing Declaration to be Provided Later (implies a > willingness to commit to the provisions of a), b), or c) > above; otherwise, the next option - "Unwilling to Commit to > the Provisions of a), b), or c) Above" - must be selected) > > e) ___ Unwilling to Commit to the Provisions of a), b), or c) > Above > > NOTE: The individual submitting this template represents and warrants > that he or she is authorized by the Patent Holder to agree to the > above-selected licensing declaration. > > VII. Contact Information of Submitter of this Form (if different from > IETF Participant in Section III above) > > Name: Microsoft Standards Inquiries > > Title: > > Department: > > Address: One Microsoft Way, Redmond, WA 98052 > > > Telephone: > > Fax: > > Email: stdsreq@microsoft.com > > VIII. Other Notes: ** A license to implement these specifications > will be made available at http://www.microsoft.com/mscorp/standards on > or before September 15, 2004. From owner-ietf-mxcomp@mail.imc.org Mon Aug 23 22:56:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10338 for ; Mon, 23 Aug 2004 22:56: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 i7O2ZPNT061699; Mon, 23 Aug 2004 19: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 i7O2ZP9A061698; Mon, 23 Aug 2004 19:35: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 (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O2ZORo061667 for ; Mon, 23 Aug 2004 19:35:24 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 23 Aug 2004 21:35:25 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D0553E7@srv1.pan-am.ca> Thread-Topic: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Thread-Index: AcSJfjPipzSpEVvpRyC6u0S07ROV9wABBoOQ From: "Gordon Fecyk" To: "IETF MARID List" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7O2ZORo061693 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Is the only thing Microsoft asking for in any source code release is an IPR disclosure? And indemnification? I'm reading Section 2.2 of said license and I get the impression nothing would stop me from writing a library based on this and release it under the GPL, because 2.2 says I can release source if I also include that other text. Have I misinterpreted that? -- 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 Aug 23 23:00:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10604 for ; Mon, 23 Aug 2004 23:00: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 i7O2d7R9062730; Mon, 23 Aug 2004 19:39: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 i7O2d7VM062729; Mon, 23 Aug 2004 19:39:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from knecht.Neophilic.COM (dsl081-247-036.sfo1.dsl.speakeasy.net [64.81.247.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O2d5jR062705 for ; Mon, 23 Aug 2004 19:39:06 -0700 (PDT) (envelope-from eric@sendmail.com) Received: from [10.0.2.36] (knecht.Sendmail.ORG [10.0.2.36] (may be forged)) by knecht.Neophilic.COM (8.13.1/8.13.1) with ESMTP id i7O2d1IE026511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Aug 2004 19:39:01 -0700 (PDT) Date: Mon, 23 Aug 2004 19:39:01 -0700 From: Eric Allman To: ietf-mxcomp@imc.org Subject: DEPLOY: Sendmail position on Sender Id Message-ID: <4B43B270D7B343DB56E55E0B@knecht.sendmail.org> X-Mailer: Mulberry/3.1.5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on knecht.sendmail.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sendmail, Inc. has worked with Microsoft to help them produce a patent license that will be acceptable for ourselves, the IETF, and the open source community at large. This message summarizes our position. The following discussion refers to the Royalty Free Sender ID Patent License (RFSIPL), dated 23 August. Harry has already posted it to the list, although it will take a few days to appear on the Microsoft web site. The executive summary is that we believe that the Sender ID technology is promising, and will hopefully be adopted. We believe that although not ideal, the RFSIPL and associated IP disclosures satisfy the IPR requirements of the IETF and are compatible with most major open source licenses. It would be extremely disappointing if this potentially useful technology to combat fraud and spam failed for reasons unrelated to its technological merits. The revisions in the RFSIPL have clarified several important issues. Notably, it is now explicit that recipients of a Sender ID implementation who do not intend to redistribute the code do not need to get a patent license to use such an implementation. However, the license is not without restrictions. Sublicenseability Our key concern is that anyone redistributing open source code with Sender ID technology would need to execute a license with Microsoft to remain within the letter of the current license. Sections 2.1 and 2.2 provide patent license grants for object and source code respectively; in both cases they are non-sublicenseable. This restriction means that anyone distributing or redistributing Licensed Implementations (that is, Sender ID) should contact Microsoft for a patent license. This process is reasonably painless, requiring only that the licensee fax the signed license (available at ) to Microsoft. None the less, any time a license is involved friction is added to the process. Defensive Suspension A somewhat lesser concern is specific to the GPL: it has been claimed that section 6 of the GPL (version 2) prohibits invalidation of a license on the basis of a patent infringement claim as required by section 2.4 ("Defensive Suspension") of the RFSIPL. We believe this to be a reasonable term, common in many open source licenses (e.g., the Mozilla Public License, the IBM Common Public License, the Apache License). It is notable that many programs with similar license terms are already packaged in GPLed distributions, so the incompatibility claim is clearly not universally believed. Reciprocal Patent License Section 2.3 of the RFSIPL extends the patent license grant to apply to the licensee as well as the licensor. In other words, if the licensee also has a patent on IP necessary to implement Sender ID, then they in turn grant the rights to that patent under the same terms (including royalty-free and non-sublicenseability) to all other licensees. This ensures that any additional IP required from other suppliers will also be available royalty-free. We believe this to be a net positive term for the interests of the community. However, it may be expected that some organizations will want to review their own patent portfolio prior to signing, which adds additional friction. License Compatibility Viewed from the license compatibility perspective, our legal counsel has opined that the RFSIPL is consistent with the Sendmail Open Source License, and we believe it is also compatible with the BSD license, since neither of them refer to patents at all (nor does the Python license or the Artistic License, to name a few additional examples). Some other Open Source licenses explicitly state that it is the recipient's duty to acquire any necessary IP rights needed to run the software (e.g., the IBM Common Public License). In all such cases we think it is probably safe to presume compatibility from a "letter of the law" perspective, if not the "intent" perspective. The major exception to this may be the GPL, both as regards Defensive Suspension as noted above, and as regards the non-sublicenseability clause. Even this isn't completely clear; Eben Moglen (FSF Counsel) has published an example of at least one case (the Office 2003 XML Schema) where he found such conditions acceptable from the GPL legal perspective, albeit not within the original intent (http://www.theregister.co.uk/2003/11/18/fsf_eases_microsoft_schema_patent/). In particular, the article says: "I don't think the alarm is justified," the FSF's pro bono counsel Eben Moglen told us last night. "This is not a license that I would like to accept; Microsoft is saying we might have some patents. But it's not a problem if Microsoft is making it available to everyone to make use and sell. The Sendmail Perspective The non-sublicenseability element does present certain practical problems for Sendmail. On the open source side, the sendmail MTA is routinely bundled into other larger systems, notably open source operating system releases such as Linux and BSD distributions as well as commercial closed-source systems such as Solaris and AIX. Bundlers would need to execute their own copy of the RFSIPL. Those systems are in turn sometimes incorporated into other products, which would seemingly require another layer of patent licenses, and so on down the tree. As a practical matter, this makes the decision to include sendmail with Sender ID into their release more problematic. This is obviously not desirable from our point of view. On the commercial side, we have end user customers who install and use our product and channel partners who rebrand and/or redistribute our product. Although the RFSIPL does not require us to demand a license from any of our customers, our customers do demand IP disclosure as part of sales contracts. End-user customers are fine, since the RFSIPL permits them to use Sender Id without executing a license. But all of our channel partners would have to sign the RFSIPL to be within the terms of the license. They will want to have their own lawyers review the license, just as we have. This is not going to sit well with our partners, who expect us to take care of IPR issues when we bundle a technology into our product. This requires additional effort on the part of both ourselves and our partners and thus lengthens our sales cycle for these important customers. While these are pragmatic rather than legal reasons, our likely decision at Sendmail will be to distribute our Sender ID implementation as a separate package that is not required to run the sendmail MTA under a distinct (possibly modified) Sendmail Open Source license. Open source users will have the option of downloading and installing the Sender ID package should they want the additional functionality. Bundlers will be able to choose whether they want to include the Sender ID technology or not, but will still be able to use the base sendmail MTA without additional IPR issues. Considerations for MARID In regards to the MARID Working Group of the IETF, we believe that the IPR disclosure requirements of the IETF (RFC3668) are consistent with the RFSIPL, and hence we do not see any by-the-book impediment to proceeding forward using this license. In fact, Microsoft has gone beyond the strict requirements of RFC3668, which do not require royalty-free licenses, nor even any explicit disclosure of licensing terms at all (section 6.5). However, we understand that email is one of the most fundamental protocols on the Internet, and there may be reluctance to rely on any encumbered intellectual property, even with the promise of royalty-free licenses to all users. It is worth noting that IP encumbrances for popular standards are not a new problem. For example, the W3C Patent Policy does not require patent licenses to be sublicenseable. In his new book "Open Source Licensing, Software Freedom and Intellectual Property Law", Larry Rosen states (pp 309-310): Not every requirement of the W3C Royalty-Free license policy is friendly to open source, however. For example, because such licenses are "non-assignable" and "non-sublicenseable" each licensee theoretically must obtain a license directly from the patent owner. In practice hardly anybody does and because the W3C member commitments to each other, nobody needs to fear that the royalty free patent license wouldn't be available to anyone who actually wanted one. He does however say that such patent licenses need to be royalty-free (pp 306-307), as is the RFSIPL. Recommendation Although the RFSIPL is not ideal, we believe that it satisfies the requirements of the IETF and is compatible with a broad range of Open Source licenses. Sender ID seems to be a technologically appealing option in the IP address based authentication space. There is great urgency in the marketplace right now to combat fraud, phishing, and spam. As a result of these considerations, we recommend that MARID proceed with Sender ID. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 01:52:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20006 for ; Tue, 24 Aug 2004 01:52:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O5P5ks076160; Mon, 23 Aug 2004 22:25:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O5P5U0076159; Mon, 23 Aug 2004 22:25:05 -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 i7O5P4Af076140 for ; Mon, 23 Aug 2004 22:25:04 -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 ECB6C40E0 for ; Mon, 23 Aug 2004 22:25:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: TECH-ERROR: DNS Record Types Date: Mon, 23 Aug 2004 22:25:19 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 23, 2004, at 5:09 PM, Jim Lyon wrote: > I believe that the latest Protocol draft (draft-ietf-marid-protocol-03) > contains changes that don't correctly reflect the consensus of the > group > concerning DNS record types. The changes you cited were all made in response to review by the people of DNS-EXT. In particular, Olafur Gudmundsson, co-chair of DNS-EXT provided much of the wording you see verbatim. He and I discussed the changes and in particular the very points you bring up. He said he'd like to see this version of the wording go to last call, and that he'd be willing to be involved in discussions. Andy: Can we get him in? - Mark From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 03:01:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08304 for ; Tue, 24 Aug 2004 03:01:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O6cWFL083828; Mon, 23 Aug 2004 23: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 i7O6cWri083827; Mon, 23 Aug 2004 23:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O6cW1E083804 for ; Mon, 23 Aug 2004 23:38:32 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 748C494012; Tue, 24 Aug 2004 08:38:27 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx1.nic.fr (Postfix) with ESMTP id D103494011; Tue, 24 Aug 2004 08:38:26 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7O6cQig859734; Tue, 24 Aug 2004 08:38:26 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id A722E102C5; Tue, 24 Aug 2004 08:38:26 +0200 (CEST) Date: Tue, 24 Aug 2004 08:38:26 +0200 From: Stephane Bortzmeyer To: Daniel Quinlan Cc: IETF MARID WG Subject: Re: TECH-OMISSION: billing.victim.com is possible Message-ID: <20040824063826.GA13303@nic.fr> References: <16682.32568.397886.244207@proton.pathname.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16682.32568.397886.244207@proton.pathname.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 23, 2004 at 04:35:20PM -0700, Daniel Quinlan wrote a message of 18 lines which said: > all a spammer/phisher needs to do is fake their email to come from > "billing.victim.com" or some other undefined host. ... > It may be sufficient to state that an implementation MAY fail or > softfail in check_host() domain if no SPF2, MX, or A record exists. IMHO, every sensibly managed MTA already refuses email from unexisting addresses (smtpd_sender_restrictions = reject_unknown_sender_domain in Postfix), so I do not see this as an issue. The lack of a MX or an A or an AAAA (meaning the message is unreplyable) is a separate error (which is already addressed by implementations). [It has already been discussed on the spf-discuss list.] The only thing to change should be to ask the MTA authors to allow the testing of "unknown_sender_domain" to be performed on every address used by the PRA algorithm. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 03:03: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 DAA08413 for ; Tue, 24 Aug 2004 03:03: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 i7O6hHZg084411; Mon, 23 Aug 2004 23:43:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O6hHAV084410; Mon, 23 Aug 2004 23:43:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O6hHti084402 for ; Mon, 23 Aug 2004 23:43:17 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id D8A3C94012; Tue, 24 Aug 2004 08:43:16 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 397F594011; Tue, 24 Aug 2004 08:43:16 +0200 (CEST) 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 i7O6hGvm1262052; Tue, 24 Aug 2004 08:43:16 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 0DB8F102C5; Tue, 24 Aug 2004 08:43:16 +0200 (CEST) Date: Tue, 24 Aug 2004 08:43:16 +0200 From: Stephane Bortzmeyer To: Daniel Quinlan Cc: IETF MARID WG Subject: Re: TECH-ERROR: PTR should not be recommended against in -protocol Message-ID: <20040824064316.GB13303@nic.fr> References: <16682.32673.222833.688650@proton.pathname.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16682.32673.222833.688650@proton.pathname.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [IMHO, it should be DEPLOY and not TECH-ERROR.] On Mon, Aug 23, 2004 at 04:37:05PM -0700, Daniel Quinlan wrote a message of 8 lines which said: > PTR has useful semantics and has the same potential overhead as MX. > It should not be recommended against. At most, "A" should be > recommended over both "MX" and "PTR" Shouldn't it be an issue is for future HOWTOs or "best practices" document, not for -protocol? From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 03:10: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 DAA08625 for ; Tue, 24 Aug 2004 03:10: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 i7O6mG6J084850; Mon, 23 Aug 2004 23: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 i7O6mGuX084849; Mon, 23 Aug 2004 23:48:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O6mGPL084840 for ; Mon, 23 Aug 2004 23:48:16 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id BEE6494013; Tue, 24 Aug 2004 08:48:15 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 215F194012; Tue, 24 Aug 2004 08:48:15 +0200 (CEST) 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 i7O6mFvm1265293; Tue, 24 Aug 2004 08:48:15 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id F08B3102C5; Tue, 24 Aug 2004 08:48:14 +0200 (CEST) Date: Tue, 24 Aug 2004 08:48:14 +0200 From: Stephane Bortzmeyer To: Daniel Quinlan Cc: IETF MARID WG Subject: IDN and Sender-ID (Was: some other questions/comments Message-ID: <20040824064814.GC13303@nic.fr> References: <16682.33684.999278.517754@proton.pathname.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16682.33684.999278.517754@proton.pathname.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, Aug 23, 2004 at 04:53:56PM -0700, Daniel Quinlan wrote a message of 27 lines which said: > - US-ASCII requirement: internationalized DNS? You mean IDN, RFC 3490? I've understood that you're supposed to use Punycode (RFC 3492) on the Right-Hand Side of the Sender-ID record, for instance, when -protocol says: > For either type, the character content of the record is encoded as > US-ASCII. You can have: mx:xn--caf-dma.gennic.net and then you get the MX of café.gennic.net (warning: composed Latin character in the domain name). From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 03:33:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09622 for ; Tue, 24 Aug 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 i7O783eK087312; Tue, 24 Aug 2004 00:08: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 i7O783uD087311; Tue, 24 Aug 2004 00:08:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O782q7087305 for ; Tue, 24 Aug 2004 00:08:02 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 4CF7D9401A; Tue, 24 Aug 2004 09:08:02 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx1.nic.fr (Postfix) with ESMTP id 88E8894013; Tue, 24 Aug 2004 09:08:01 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7O781ig869967; Tue, 24 Aug 2004 09:08:01 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 49C4A102C5; Tue, 24 Aug 2004 09:08:01 +0200 (CEST) Date: Tue, 24 Aug 2004 09:08:01 +0200 From: Stephane Bortzmeyer To: Harry Katz , stdsreq@microsoft.com Cc: IETF MARID List Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License Message-ID: <20040824070801.GD13303@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 23, 2004 at 07:00:25PM -0700, Harry Katz wrote a message of 752 lines which said: > For the convenience of the working group, attached is the complete > text of the license. I have a problem with the following: > Whereas, Microsoft has developed a specification describing certain > attributes for eliminating the spoofing or forging of electronic > mail addresses; Microsoft did not develop Sender-ID. Does it mean that accepting the License mean you "grant" Microsoft this claim? From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 03:39: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 DAA10035 for ; Tue, 24 Aug 2004 03:39:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O7G4YJ088450; Tue, 24 Aug 2004 00:16:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O7G4VO088449; Tue, 24 Aug 2004 00:16:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O7G4tA088441 for ; Tue, 24 Aug 2004 00:16:04 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id E4BFE94012; Tue, 24 Aug 2004 09:16:03 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx1.nic.fr (Postfix) with ESMTP id 2ED2D94011; Tue, 24 Aug 2004 09:16:03 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7O7G3ig872258; Tue, 24 Aug 2004 09:16:03 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 033F1102C5; Tue, 24 Aug 2004 09:16:02 +0200 (CEST) Date: Tue, 24 Aug 2004 09:16:02 +0200 From: Stephane Bortzmeyer To: Harry Katz , stdsreq@microsoft.com Cc: IETF MARID List Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Message-ID: <20040824071602.GF13303@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 23, 2004 at 07:01:00PM -0700, Harry Katz wrote a message of 457 lines which said: > For the convenience of the working group, attached is the full text > of the FAQ. Reading the FAQ: > A7: [...] we believe you can distribute your implementation under > many open source software licenses, [...] Microsoft has not been > made aware of any specific incompatibilities between any of the > licenses used to distribute Sendmail, Postfix, or Qmail with > Microsoft's royalty-free patent license. There is a big free software licence missing, the GPL (none of the MTA mentioned uses the GPL. Exim, which does, is not mentioned and I assume it is not a coincidence). Taking this into account and reading Eric Allman analysis (http://www.imc.org/ietf-mxcomp/mail-archive/msg03500.html), it seems the most common free software licence, the GPL, is incompatible with Microsoft licence on SenderID. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 03:39:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10057 for ; Tue, 24 Aug 2004 03:39:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O7AWxR087501; Tue, 24 Aug 2004 00:10: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 i7O7AWMh087500; Tue, 24 Aug 2004 00:10:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O7AW0d087494 for ; Tue, 24 Aug 2004 00:10:32 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 1885894012; Tue, 24 Aug 2004 09:10:32 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx1.nic.fr (Postfix) with ESMTP id 520339401C; Tue, 24 Aug 2004 09:10:31 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7O7AVig871721; Tue, 24 Aug 2004 09:10:31 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 2154E102C5; Tue, 24 Aug 2004 09:10:31 +0200 (CEST) Date: Tue, 24 Aug 2004 09:10:31 +0200 From: Stephane Bortzmeyer To: Harry Katz , stdsreq@microsoft.com Cc: IETF MARID List Subject: Re: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination Message-ID: <20040824071031.GE13303@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 23, 2004 at 07:01:28PM -0700, Harry Katz wrote a message of 161 lines which said: > The following IPR disclosure statement was sent to statements@ietf.org > earlier today. ... > V. Disclosure of Patent Information (i.e., patents or patent > applications required to be disclosed by Section 6 of RFC 3668) ... > Patent, Serial, Publication, Registration, or Application/File > number(s): > > Date(s) granted or applied for (YYYY-MM-DD): > > Country(ies): > > B. Does your disclosure relate to an unpublished pending patent > application? > > Select one: Yes ___X___ No ______ Does the above mean that it is not possible to know anything about the patent itself? It is hard to take a decision about something you cannot read. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 03:57:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11034 for ; Tue, 24 Aug 2004 03:57:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O7aAea090103; Tue, 24 Aug 2004 00:36: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 i7O7aAaB090102; Tue, 24 Aug 2004 00:36:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O7a9Uv090093 for ; Tue, 24 Aug 2004 00:36:10 -0700 (PDT) (envelope-from roy@dnss.ec) Received: by mail.schlyter.se (Postfix, from userid 2038) id D07F8AC8B; Tue, 24 Aug 2004 09:36:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id CF609AC8A for ; Tue, 24 Aug 2004 09:36:06 +0200 (CEST) Date: Tue, 24 Aug 2004 09:36:06 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: IETF MARID List Subject: Re: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination 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 Mon, 23 Aug 2004, Harry Katz wrote: > The following IPR disclosure statement was sent to statements@ietf.org > earlier today. What I'm concerned about is that licensing of technology developed and published through the IETF sets a precedent. We'll be drifting from the mudpool to the quicksand. Roy Arends From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 04:06: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 EAA12298 for ; Tue, 24 Aug 2004 04:06: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 i7O7gw8d090603; Tue, 24 Aug 2004 00:42:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O7gwVt090602; Tue, 24 Aug 2004 00:42:58 -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 i7O7gvu0090592 for ; Tue, 24 Aug 2004 00:42:58 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id EC54E28570 for ; Tue, 24 Aug 2004 09:42:52 +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 28557-01-3 for ; Tue, 24 Aug 2004 09:42:49 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 61B6928616; Tue, 24 Aug 2004 09:42:49 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Tue, 24 Aug 2004 09:42:49 +0200 (CEST) Message-ID: <58796.127.0.0.1.1093333369.squirrel@127.0.0.1> In-Reply-To: References: Date: Tue, 24 Aug 2004 09:42:49 +0200 (CEST) Subject: Re: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Harry Katz a écrit : > > VIII. Other Notes: ** A license to implement these specifications > will be made available at http://www.microsoft.com/mscorp/standards on > or before September 15, 2004. Then the compatibility of this license with implementation of SenderID in Free Software cannot be determined before this license is actually published. Which makes it a show-stopper, as IETF cannot reasonably define as a standard any protocol for which licensing terms are currently unknown. So IMHO any IETF decision regarding SenderID has to be postponed as long as the license is unknown. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 04:16: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 EAA13392 for ; Tue, 24 Aug 2004 04:16: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 i7O7qfFM091522; Tue, 24 Aug 2004 00:52: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 i7O7qfq7091521; Tue, 24 Aug 2004 00:52:41 -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 i7O7qeSA091514 for ; Tue, 24 Aug 2004 00:52:41 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id AA07728570 for ; Tue, 24 Aug 2004 09:52:37 +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 28557-02 for ; Tue, 24 Aug 2004 09:52:34 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 97BBC28616; Tue, 24 Aug 2004 09:52:34 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Tue, 24 Aug 2004 09:52:34 +0200 (CEST) Message-ID: <58870.127.0.0.1.1093333954.squirrel@127.0.0.1> In-Reply-To: <20040823194803.GA2802@preston.sources.org> References: <20040823194803.GA2802@preston.sources.org> Date: Tue, 24 Aug 2004 09:52:34 +0200 (CEST) Subject: Re: [DEPLOY] Privacy and disclosure of addresses in -core From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Stephane Bortzmeyer a écrit : > > The whole purpose of Sender-ID is to disclose the real email address > used for the last introduction of the message. This can conflict with > privacy expectations [...] > The problem already exists with the Received headers but the advice in > -core (7.5 "MUA implementers") to display the addresses used in the > PRA makes it stronger, IMHO. [...] > Automatically adding headers like Resent-From and Sender, as mandated > here, may have privacy consequences for the users. This is a valid and important concern that should be addressed. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 04:40: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 EAA14770 for ; Tue, 24 Aug 2004 04:40: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 i7O8Btwq094346; Tue, 24 Aug 2004 01:11: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 i7O8BtKa094345; Tue, 24 Aug 2004 01:11:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O8BsHb094337 for ; Tue, 24 Aug 2004 01:11:55 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 154B194013; Tue, 24 Aug 2004 10:11:55 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 7A30C94011; Tue, 24 Aug 2004 10:11:54 +0200 (CEST) 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 i7O8Bsvm1282691; Tue, 24 Aug 2004 10:11:54 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 5F620102C5; Tue, 24 Aug 2004 10:11:54 +0200 (CEST) Date: Tue, 24 Aug 2004 10:11:54 +0200 From: Stephane Bortzmeyer To: Michel Bouissou Cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination Message-ID: <20040824081154.GA21836@nic.fr> References: <58796.127.0.0.1.1093333369.squirrel@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58796.127.0.0.1.1093333369.squirrel@127.0.0.1> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 09:42:49AM +0200, Michel Bouissou wrote a message of 19 lines which said: > > VIII. Other Notes: ** A license to implement these specifications > > will be made available at http://www.microsoft.com/mscorp/standards on > > or before September 15, 2004. > > Then the compatibility of this license with implementation of SenderID in > Free Software cannot be determined before this license is actually > published. The licence has been published on this Working Group mailing list. See http://www.imc.org/ietf-mxcomp/mail-archive/msg03496.html. There is a FAQ s well http://www.imc.org/ietf-mxcomp/mail-archive/msg03497.html Three weeks (until September 15) is just the time it takes to update a Web page on an IIS Web server. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 05:19: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 FAA17381 for ; Tue, 24 Aug 2004 05: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 i7O8iugs001192; Tue, 24 Aug 2004 01:44:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O8itdp001191; Tue, 24 Aug 2004 01:44:55 -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 i7O8ioP4001135 for ; Tue, 24 Aug 2004 01:44:51 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 1444B28632 for ; Tue, 24 Aug 2004 10:44:50 +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 30099-03 for ; Tue, 24 Aug 2004 10:44:36 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 9184D28633; Tue, 24 Aug 2004 10:44:36 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Tue, 24 Aug 2004 10:44:36 +0200 (CEST) Message-ID: <59181.127.0.0.1.1093337076.squirrel@127.0.0.1> In-Reply-To: <20040824081154.GA21836@nic.fr> References: <58796.127.0.0.1.1093333369.squirrel@127.0.0.1> <20040824081154.GA21836@nic.fr> Date: Tue, 24 Aug 2004 10:44:36 +0200 (CEST) Subject: Re: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Stephane Bortzmeyer a écrit : > > Michel Bouissou wrote >> > VIII. Other Notes: ** A license to implement these specifications >> > will be made available at http://www.microsoft.com/mscorp/standards on >> > or before September 15, 2004. >> >> Then the compatibility of this license with implementation of SenderID >> in Free Software cannot be determined before this license is actually >> published. > > The licence has been published on this Working Group mailing list. Yes, I've just seen it had been attached to a following mail from Harry Katz. The first email from Harry looked like the license wouldn't be available before Sept, 15, thus my reply at this stage. I note that this license remains "non-transferable and non-sublicenseable", and that, to benefit from this license, one still needs to return a written, signed copy to Microsoft. In understand that the distribution rights (in binary or source form) are only granted by this license, and thus, the issue remains of redistribution rights for makers of Linux or *BSD distributions, who simply couldn't afford to have to sign and return licenses, and track their status, for every software package in the thousands of software packages that modern Free Software distribution contains. So this still is a problem. Even though the license states that the licensee can redistribute "indirectly" the Sender-ID code, it doesn't give any clue about the right (or lack thereof) for the distributors themselves. I'm also wondering about the "FAQ" : A FAQ by itself has no legal weight. If a FAQ is needed, it tends to show that some points in the license may be unclear. I would much prefer if all possibly unclear points were stated in the license itself, as it would both make them clear, and have legal value, rather than in a separate FAQ. Yet, I'm concerned with the compatibility of this license with a GPL'd MTA, as a first read makes me think they remain incompatible, but IANAL... Could Microsoft give their written statement regarding the compatibility between their Sender-ID license and a GPL'd MTA ? (please do not reply that the GPL is just "yet another license" and that compatibility with every license cannot be examined...) > Three weeks (until September 15) is just the time it takes to update a > Web page on an IIS Web server. ROTFLMAOWPIMP -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 05:23: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 FAA17615 for ; Tue, 24 Aug 2004 05:23: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 i7O8rbeT004628; Tue, 24 Aug 2004 01:53:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O8rbqY004627; Tue, 24 Aug 2004 01:53:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O8ra9L004621 for ; Tue, 24 Aug 2004 01:53:37 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1BzX3g-0000Fh-00 for ietf-mxcomp@imc.org; Tue, 24 Aug 2004 09:53:37 +0100 Message-ID: <067601c489b7$881eb1f0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: DEPLOY: Sending of malicious 'bounce' messages to innocent victims Date: Tue, 24 Aug 2004 09:51:17 +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 Sender-ID has the capability to determine that an Original message is a forgery. The drafts require the rejection of a forged Original message, potentially occasioning the sending of a 'bounce' message to the Mail-From address. It is the experience here, and it has also been reported on the spf-discuss list, that there is common family of malicious emails in which a virus-carrying payload is distributed (in volume from compromised hosts) with the intended victim designated in the Mail-From: address. By implementing Sender-ID, we would become parties to the creation and propagation of malicious messages. Had we not implemented Sender-ID, those 'bounce' recipients would not otherwise have received those malicious messages. Active participation in the propagation of viruses, pornography, UBM and other forms of malice is counter to our policies on business ethics. I am therefore unable to deploy Sender-ID as presently drafted. Chris Haynes Names of businesses available on request. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 07:38: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 HAA26881 for ; Tue, 24 Aug 2004 07:38: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 i7OB1FV2037778; Tue, 24 Aug 2004 04:01: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 i7OB1FxY037777; Tue, 24 Aug 2004 04:01:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OB1ECB037763 for ; Tue, 24 Aug 2004 04:01:14 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7OB1D77015340 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Aug 2004 07:01:14 -0400 Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License From: Mark Shewmaker To: IETF MARID List In-Reply-To: References: Content-Type: text/plain Message-Id: <1093345347.8132.10371.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 24 Aug 2004 07:02:28 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Tue, 24 Aug 2004 07:01:15 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My non-lawyerly conclusion: =========================== This patent license is incompatible with the Open Source Definition, the Free Software Definition, the Debian Free Software Guidelines, and the GPL and LGPL licenses specifically. What this means: ================ The above incompatibility will severely restrict implementation and deployment of the standard, which is a problem that can only be solved by: 1. fixing the license to address all its problems (described in detail below), 2. assuming that the nebulous IPR claims are not valid and thus ignoring the license requirements completely, or 3. dropping the encumbered IPR from the standard. We've passed the deadline to fix the license, so (1) is out, and (2) and (3) are the only potential choices left. I believe the general consensus here is that the encumbered IPR at issue is the (obvious) PRA algorithm. Now even though I personally can't see how the PRA algorithm could possibly be considered a non-obvious idea, I'm guessing that enough people and companies will be unwilling to risk their livelyhood on that stance, which means that fear of lawsuits will probably keep (2) from being a viable option. That leaves (3), dropping the algorithm completely. Dropping that algorithm effectively means going back to Classic-SPF. I believe that is what must be done. I don't know how easily that can be done with the current wording and breakdown of the standard--perhaps it would be relatively straightforward since the PRA was pulled out, with just a few minor edits necessary here and there, perhaps not. Either way, I believe we have *no choice* in the matter: Like it or not, SPF-Classic is now effectively the only choice we have. (Personal Rant: I would have preferred a different solution. My personal opinion as to the best technical option, were there no licensing issues to muck things up, would have been some sort of Unified-SPF with sender_agents included. With Unified SPF and sender_agents, we'd get Return-Path protection, prevention of PRA forgeries, and phishing protections--protecting from forgeries all three things we're out to protect. That would have been just fantastic, but nothing with a PRA in it is possible now, and that leaves us with only SPF-Classic.) The specific problems with the license: ======================================= 1. Issue: ====== Whatever IPR rights you might obtain for yourself won't extend to everyone who gets a copy of your code. Source: ======= o Section 2.[12]'s wording of personal, nontransferable, and nonsublicenseable, o The wording under section 2.2. o The last sentence of section 2.5. Problems: ========= o Violates OSD #7, DFSG #7 | Distribution of License | | The rights attached to the program must apply to all to whom | the program is redistributed without the need for execution | of an additional license by those parties. o Fails Dissident test. | The Dissident test. | | Consider a dissident in a totalitarian state who wishes to | share a modified bit of software with fellow dissidents, but | does not wish to reveal the identity of the modifier, or | directly reveal the modifications themselves, or even | possession of the program, to the government. Any requirement | for sending source modifications to anyone other than the | recipient of the modified binary---in fact any forced | distribution at all, beyond giving source to those who receive | a copy of the binary---would put the dissident in danger. For | Debian to consider software free it must not require any such | "excess" distribution. o Violates Freedom #2 | The freedom to redistribute copies so you can help your | neighbor o Violates Freedom #3 | The freedom to improve the program, and release your | improvements to the public, so that the whole community | benefits 2. Issue: ====== Whatever Microsoft's unspecified IPR supposedly covers, you can't do anything with it except Sender-ID-ish things. Source: ======= Section 2.1's "solely for the purpose of conforming with" wording. Oddly enough the restriction isn't again specifically listed under section 2.2. Problems: ========= o Violates OSD #6, DFSG #6 | 6. No Discrimination Against Fields of Endeavor | | The license must not restrict anyone from making use | of the program in a specific field of endeavor. For | example, it may not restrict the program from being used | in a business, or from being used for genetic research. o Violates Freedoms #1 | The freedom to study how the program works, and adapt | it to your needs o Violates Freedom #3 | The freedom to improve the program, and release your | improvements to the public, so that the whole community | benefits 3. Issue: You must agree to comply with a set of (purportedly-applicable) laws that the license alerts you to. (As opposed to being merely alerted to the existence and purported applicability of these laws.) Source: ======= Section 6.2. Problems: ========= o Violates OSD #5 | 5. No Discrimination Against Persons or Groups | | The license must not discriminate against any person or | group of persons. | | Rationale: In order to get the maximum benefit from the | process, the maximum diversity of persons and groups should | be equally eligible to contribute to open sources. | Therefore we forbid any open-source license from locking | anybody out of the process. | | Some countries, including the United States, have export | restrictions for certain types of software. An | OSD-conformant license may warn licensees of applicable | restrictions and remind them that they are obliged to obey | the law; however, it may not incorporate such restrictions | itself. o Violates DFSG #5 | 5. No Discrimination Against Persons or Groups | | The license must not discriminate against any person or | group of persons. o Violates the Dissident test | The Dissident test. | | Consider a dissident in a totalitarian state who wishes to | share a modified bit of software with fellow dissidents, but | does not wish to reveal the identity of the modifier, or | directly reveal the modifications themselves, or even | possession of the program, to the government. Any requirement | for sending source modifications to anyone other than the | recipient of the modified binary---in fact any forced | distribution at all, beyond giving source to those who receive | a copy of the binary---would put the dissident in danger. For | Debian to consider software free it must not require any such | "excess" distribution. o Violates Freedom #2 | The freedom to redistribute copies so you can help your | neighbor o Violates Freedom #3 | The freedom to improve the program, and release your | improvements to the public, so that the whole community | benefits 4. Issue: ====== You must agree to be judged by the laws of a specific jurisdiction and be judged at a specific location. Source: ======= Section 6.4 Problems: ========= o Always objected to on license-discuss for practical reasons. (It creates superfluous incompatibilities with any other licenses with choice-of-law and choice-of-venue restrictions.) o GPL and LGPL incompatible. 5. Issue: ====== Your rights can be stripped away if you assert your patent rights or initiate a lawsuit. Source: ======= Section 2.4 Problems: ========= o GPL and LGPL-incompatible. (From http://www.gnu.org/licenses/license-list.html , "We don't think those patent termination cases are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.") o Possibly fails Tentacles of Evil test | The Tentacles of Evil test. | | Imagine that the author is hired by a large evil corporation | and, now in their thrall, attempts to do the worst to the | users of the program: to make their lives miserable, to make | them stop using the program, to expose them to legal | liability, to make the program non-free, to discover their | secrets, etc. The same can happen to a corporation bought out | by a larger corporation bent on destroying free software in | order to maintain its monopoly and extend its evil empire. The | license cannot allow even the author to take away the | required freedoms! 6. Issue: ====== The fact that either side has entered into this license is effectively public knowledge. Source: ======= Section 6.9 Problems: ========= Fails the Dissident Test | The Dissident test. | | Consider a dissident in a totalitarian state who wishes to | share a modified bit of software with fellow dissidents, but | does not wish to reveal the identity of the modifier, or | directly reveal the modifications themselves, or even | possession of the program, to the government. Any requirement | for sending source modifications to anyone other than the | recipient of the modified binary---in fact any forced | distribution at all, beyond giving source to those who receive | a copy of the binary---would put the dissident in danger. For | Debian to consider software free it must not require any such | "excess" distribution. 7. Issue: ====== You have to separately agree to and sign a Patent license at all. Source: ======= Section 2.5 Problems: ========= o Violates OSD #7, DFSG #7 | 7. Distribution of License | | The rights attached to the program must apply to all to whom | the program is redistributed without the need for execution | of an additional license by those parties. o Violates OSD #10 | 10. License Must Be Technology-Neutral | | No provision of the license may be predicated on any | individual technology or style of interface. | | Rationale: This provision is aimed specifically at licenses | which require an explicit gesture of assent in order to | establish a contract between licensor and licensee. | Provisions mandating so-called "click-wrap" may conflict | with important methods of software distribution such as | FTP download, CD-ROM anthologies, and web mirroring; such | provisions may also hinder code re-use. Conformant | licenses must allow for the possibility that (a) | redistribution of the software will take place over | non-Web channels that do not support click-wrapping of the | download, and that (b) the covered code (or re-used | portions of covered code) may run in a non-GUI environment | that cannot support popup dialogues. o Violates Freedom #2 | The freedom to redistribute copies so you can help your | neighbor o Violates Freedom #3 | The freedom to improve the program, and release your | improvements to the public, so that the whole community | benefits o Fails Desert Island Test | The Desert Island test. | | Imagine a castaway on a desert island with a solar-powered | computer. This would make it impossible to fulfil any | requirement to make changes "publicly available" or to send | patches to some particular place. This holds even if such | requirements are only "upon request", as the castaway might be | able to receive messages but be unable to send them. To be | free, software must be modifiable by this unfortunate castaway, | who must also be able to legally share modifications with | friends on the island. o Fails Dissident Test | The Dissident test. | | Consider a dissident in a totalitarian state who wishes to | share a modified bit of software with fellow dissidents, but | does not wish to reveal the identity of the modifier, or | directly reveal the modifications themselves, or even | possession of the program, to the government. Any requirement | for sending source modifications to anyone other than the | recipient of the modified binary---in fact any forced | distribution at all, beyond giving source to those who receive | a copy of the binary---would put the dissident in danger. For | Debian to consider software free it must not require any such | "excess" distribution. References: =========== OSD: Open Source Definition, according to OSI, at http://www.opensource.org/docs/definition.php DFSG: Debian Free Software Guidelines, according to SPI, at http://www.debian.org/social_contract#guidelines Freedoms: Free Software Definition, according to FSF, at http://www.gnu.org/philosophy/free-sw.html Tests: Desert Island Test, Dissident Test, Tentacles of Evil Test. These tests are used on debian-legal as thought experiments to help determine whether a license meets the DFSG. They can be found in a draft of a DFSG FAQ at: http://people.debian.org/~bap/dfsg-faq.html -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 08:08: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 IAA28537 for ; Tue, 24 Aug 2004 08:08: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 i7OBbUE5045891; Tue, 24 Aug 2004 04:37:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OBbUPq045890; Tue, 24 Aug 2004 04:37: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 i7OBbTOM045866 for ; Tue, 24 Aug 2004 04:37:29 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 21103 invoked from network); 24 Aug 2004 11:39:13 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 24 Aug 2004 11:39:13 -0000 In-Reply-To: References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Margaret Olson Subject: Re: TECH-ERROR: DNS Record Types Date: Tue, 24 Aug 2004 07:37:25 -0400 To: Mark Lentczner X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 1:25 AM, Mark Lentczner wrote: > > > On Aug 23, 2004, at 5:09 PM, Jim Lyon wrote: > >> I believe that the latest Protocol draft >> (draft-ietf-marid-protocol-03) >> contains changes that don't correctly reflect the consensus of the >> group >> concerning DNS record types. > > The changes you cited were all made in response to review by the > people of DNS-EXT. In particular, Olafur Gudmundsson, co-chair of > DNS-EXT provided much of the wording you see verbatim. He and I > discussed the changes and in particular the very points you bring up. > He said he'd like to see this version of the wording go to last call, > and that he'd be willing to be involved in discussions. > My comment about the current wording is that either senders or receivers who do not implement the "MAY" clauses are acting against their own best interests. This is misleading at best. As a sender, I am going to publish all record types that receivers might look up as soon as I can. As a receiver who is interested in discarding as much forgery as possible as quickly as possible, I'm going to look up whatever records I can look up as quickly as I can. As a practical matter, I'll be publishing and checking TXT records very shortly, and the SPF2 record type at some point in the future. As the spec is written, a new reader has to study carefully and work this out for themselves. This is not helpful to the email community and it will slow down adoption. Chairs: This has become a DEPLOY comment - do you want me to resubmit it under that heading? Margaret. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 08:52: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 IAA01745 for ; Tue, 24 Aug 2004 08:52: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 i7OCL5Bk055070; Tue, 24 Aug 2004 05:21:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OCL57r055069; Tue, 24 Aug 2004 05:21:05 -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 i7OCL3x8055059 for ; Tue, 24 Aug 2004 05:21:04 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 3C3E128567 for ; Tue, 24 Aug 2004 14:21:05 +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 31403-08-9 for ; Tue, 24 Aug 2004 14:21:00 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 43F0028566; Tue, 24 Aug 2004 14:21:00 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Tue, 24 Aug 2004 14:21:00 +0200 (CEST) Message-ID: <59999.127.0.0.1.1093350060.squirrel@127.0.0.1> In-Reply-To: <1093345347.8132.10371.camel@localhost.localdomain> References: <1093345347.8132.10371.camel@localhost.localdomain> Date: Tue, 24 Aug 2004 14:21:00 +0200 (CEST) Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License From: "Michel Bouissou" To: "IETF MARID List" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Thanks Mark for this very extensive and thourough analysis of the MS Sender-ID license issue. I actually saved your email as a Document Worth Keeping [TM] ;-) We might want to add that furthermore, this license fails the simple IANAL test, which means that it prevents individuals or businesses to easily figure out what they can or cannot or might or might not do or may do today but possibly not tomorrow with this algorithm, without recourse to expensive legal analysis by attorneys. Anyway, I believe your analysis clearly demonstrates that Sender-ID is doomed as becoming a standard that could be widely accepted and implemented, and in such a situation, if the MARID WG were to define it as a standard anyway, it would be a major failure in its primary goal and role. I had personally stopped emailing to this ML until the "last call" as it was obvious to me that all this was leading nowhere. Mark Shewmaker a écrit : > > My non-lawyerly conclusion: > =========================== > > This patent license is incompatible with the Open Source Definition, the > Free Software Definition, the Debian Free Software Guidelines, and the > GPL and LGPL licenses specifically. Which you clearly demonstrate. > What this means: > ================ > > The above incompatibility will severely restrict implementation and > deployment of the standard, which is a problem that can only be solved > by: > > 1. fixing the license to address all its problems (described in > detail below), > 2. assuming that the nebulous IPR claims are not valid and thus > ignoring the license requirements completely, or > 3. dropping the encumbered IPR from the standard. > > We've passed the deadline to fix the license, so (1) is out, and (2) and > (3) are the only potential choices left. > > I believe the general consensus here is that the encumbered IPR at issue > is the (obvious) PRA algorithm. > > Now even though I personally can't see how the PRA algorithm could > possibly be considered a non-obvious idea, I'm guessing that enough > people and companies will be unwilling to risk their livelyhood on that > stance, which means that fear of lawsuits will probably keep (2) from > being a viable option. > > That leaves (3), dropping the algorithm completely. > > Dropping that algorithm effectively means going back to Classic-SPF. > > I believe that is what must be done. I fully share this point of view. Cheers. -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 10:14: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 KAA08276 for ; Tue, 24 Aug 2004 10:14: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 i7ODfnVh074003; Tue, 24 Aug 2004 06:41: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 i7ODfnH9074002; Tue, 24 Aug 2004 06:41:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.generic-nic.net (postfix@eve.generic-nic.net [192.134.7.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ODfm2b073978 for ; Tue, 24 Aug 2004 06:41:49 -0700 (PDT) (envelope-from bortzmeyer@kiwi.generic-nic.net) Received: from kiwi.generic-nic.net (unknown [192.134.7.241]) by mail.generic-nic.net (Postfix) with ESMTP id 53B4822AFE4 for ; Tue, 24 Aug 2004 15:41:47 +0200 (CEST) Received: by kiwi.generic-nic.net (Postfix, from userid 1001) id 1F6C633C38; Tue, 24 Aug 2004 15:41:47 +0200 (CEST) Date: Tue, 24 Aug 2004 15:41:47 +0200 From: Stephane Bortzmeyer To: ietf-mxcomp@imc.org Subject: DOC-BUG: typo in -protocol Message-ID: <20040824134147.GA68862@kiwi.generic-nic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Organization: Generic NIC X-URL: http://www.generic-nic.net/ X-Operating-System: FreeBSD 5.2.1-RELEASE i386 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I believe that the last paragraph in "4. Mechanism definitions" should start with "Several mechanisms rely on information fetched from DNS" (without the p in "rely"). From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 10:26: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 KAA09701 for ; Tue, 24 Aug 2004 10:26:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ODxL54077334; Tue, 24 Aug 2004 06:59: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 i7ODxLPV077333; Tue, 24 Aug 2004 06:59:21 -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 i7ODxKoj077146 for ; Tue, 24 Aug 2004 06:59:20 -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 i7ODwXuc019290; Tue, 24 Aug 2004 06:58:34 -0700 In-Reply-To: <009a01c48944$6dd39220$6c62fea9@ibmrkydk2ufvdd> References: <009a01c48944$6dd39220$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Andrew Newton'" , "'IETF MARID WG'" From: Marshall Rose Subject: Re: Deadline for IPR filings Date: Tue, 24 Aug 2004 14:58:31 +0100 To: "John Glube" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 23, 2004, at 20:07, John Glube wrote: > I probably should have asked this question sooner. alternatively, you could have waited 12 hours and 29 minutes, and then you wouldn't have had to ask your question at all. given the posts from harry katz around midnight, your message appears moot. /mtr From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 10:28: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 KAA09924 for ; Tue, 24 Aug 2004 10: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 i7ODs4uJ076309; Tue, 24 Aug 2004 06:54: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 i7ODs4xW076308; Tue, 24 Aug 2004 06:54:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.generic-nic.net (postfix@eve.generic-nic.net [192.134.7.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ODs3Jx076296 for ; Tue, 24 Aug 2004 06:54:04 -0700 (PDT) (envelope-from bortzmeyer@kiwi.generic-nic.net) Received: from kiwi.generic-nic.net (unknown [192.134.7.241]) by mail.generic-nic.net (Postfix) with ESMTP id 6121F22AFE4 for ; Tue, 24 Aug 2004 15:54:05 +0200 (CEST) Received: by kiwi.generic-nic.net (Postfix, from userid 1001) id 31C8B33C38; Tue, 24 Aug 2004 15:54:05 +0200 (CEST) Date: Tue, 24 Aug 2004 15:54:05 +0200 From: Stephane Bortzmeyer To: ietf-mxcomp@imc.org Subject: DOC-BUG: two IPv6 problems in -protocol Message-ID: <20040824135405.GA68895@kiwi.generic-nic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Organization: Generic NIC X-URL: http://www.generic-nic.net/ X-Operating-System: FreeBSD 5.2.1-RELEASE i386 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [I gather two IPv6 problems in one message.] 1) In "4.4. mx", it says "Then perform an A lookup on each MX name returned". It should be "Then perform an address lookup on each MX name returned" to be consistent with "4. Mechanism Definitions" which talks about address (v4 or v6) lookups. 2) In "4.3. a", I suggest to add a note: Note: as explained before, "a" stands for "address" (IPv4 or IPv6) and not for the DNS A record. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 10:36: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 KAA10807 for ; Tue, 24 Aug 2004 10:36: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 i7OE4XOJ078400; Tue, 24 Aug 2004 07:04: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 i7OE4XLF078399; Tue, 24 Aug 2004 07:04:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost4.mail.uk.easynet.net (smarthost4.mail.uk.easynet.net [212.135.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OE4WPP078376 for ; Tue, 24 Aug 2004 07:04:33 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost4.mail.uk.easynet.net with smtp (Exim 4.10) id 1BzbuT-0001vc-00 for ietf-mxcomp@imc.org; Tue, 24 Aug 2004 15:04:25 +0100 Message-ID: <07b701c489e2$f45df8f0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 15:02:10 +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 Further to my post entitled DEPLOY: Sending of malicious 'bounce' messages to innocent victims I have an additional reason why I cannot deploy Sender-ID. Suppose I detect a forged message (PRA test result = 'fail') and either my own server or the one offering it to me generates a 'bounce' message to an innocent victim. Suppose the original message, copied into the bounce, contains pornography which is illegal under English law. It is entirely conceivable that I could be held criminally liable under English law, since I caused the sending of a message containing illegal material - even though I did not know what that material was. Up till now, I understand that the courts in most jurisdictions have accepted that those transporting messages (e.g. common carriers) cannot be held liable for the content. But Sender-ID could be argued to change that legal position. If someone propagates a message, _knowing_ the content to have been repudiated by the domain owning the PRA, i.e. knowing its origins to have been forged, the entity generating the bounce could be held to be complicit in the illegal communication. At the very least one could be charged in England with something like 'Failing in the duty of care' by ignoring the warning that the message was forged and propagating the illegal material. It would be interesting to hear if anyone has obtained legal opinion on the new situation which Sender-ID creates, with respect to English Law or any other legal jurisdiction. Since I have no desire to become a defendant in a criminal law test-case, this is a further reason for my being unable to deploy Sender-ID. Chris Haynes Evesham England From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 10:59: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 KAA12450 for ; Tue, 24 Aug 2004 10:59:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OEWQCr084318; Tue, 24 Aug 2004 07:32: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 i7OEWQ3j084317; Tue, 24 Aug 2004 07:32:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OEWPGA084310 for ; Tue, 24 Aug 2004 07:32:25 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7OEWR0e009763; Tue, 24 Aug 2004 07:32:27 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 07:32:27 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mark Shewmaker'" , IETF MARID List Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License Date: Tue, 24 Aug 2004 07:32:20 -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 patent license is incompatible with the Open Source > Definition, the > Free Software Definition, the Debian Free Software Guidelines, and the > GPL and LGPL licenses specifically. I disagree. I believe that the fundamental error made by the author is to confuse a patent use license with a copyright distribution license. A patent is not a source code. A patent does not do anything on its own. Source code does. Patents are a completely different form of intellectual property. The license terms that are appropriate for a standard are completely different from those that are appropriate for an application. > 1. fixing the license to address all its problems (described in > detail below), I believe that this has been achieved. > 1. Issue: > ====== > > Whatever IPR rights you might obtain for yourself > won't extend to everyone who gets a copy of your code. > > o Violates OSD #7, DFSG #7 > > | Distribution of License > | > | The rights attached to the program must apply to all to whom > | the program is redistributed without the need for execution > | of an additional license by those parties. TO THE PROGRAM > o Fails Dissident test. > > | The Dissident test. > | > | Consider a dissident in a totalitarian state who wishes to > | share a modified bit of software with fellow dissidents, but > | does not wish to reveal the identity of the modifier, or I find this use of language pretty offensive. I have spent quite a bit of time with real dissidents in real totalitarian states. > o Violates Freedom #2 > > | The freedom to redistribute copies so you can help your > | neighbor You can redistribute copies of the software to your neighbor, they can modify them. The only party that can't use the technology is someone who is making an IP claim over it. So if there was a company called OCS who decided to sue Microsoft over the use of their technology in SenderID, they could not obtain a license. > o Violates Freedom #3 > > | The freedom to improve the program, and release your > | improvements to the public, so that the whole community > | benefits Actually you can, read it. > 2. Issue: > ====== > > Whatever Microsoft's unspecified IPR supposedly covers, > you can't do anything with it except Sender-ID-ish things. Any claims that do not relate to Sender-ID are by definition irrelevant to this working group. > 3. Issue: > > You must agree to comply with a set of (purportedly-applicable) > laws that the license alerts you to. (As opposed to being merely > alerted to the existence and purported applicability of > these laws.) This is a standard and essential license clause. Without it the license is meaningless since there is no way of knowing what law the courts would attempt to apply in interpretation. This is equivalent to writing %% csh or whatever it is at the top of a shell script so you know what it is. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 11:03:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12692 for ; Tue, 24 Aug 2004 11:03: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 i7OEZHgJ084927; Tue, 24 Aug 2004 07:35: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 i7OEZHdN084926; Tue, 24 Aug 2004 07:35:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OEZFNp084900 for ; Tue, 24 Aug 2004 07:35:16 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7OEZCOI015912 for ; Tue, 24 Aug 2004 15:35:12 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7OEZCHc015911; Tue, 24 Aug 2004 15:35:12 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: DEPLOY - IPR on Sender-ID not sufficiently disclosed From: Graham Murray Date: Tue, 24 Aug 2004 15:35:12 +0100 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Despite the 23rd August deadline, the full IPR claims on Sender-ID have not been disclosed. The licence terms have been disclosed, but insufficient (almost no) information has been given on what the claimed IPR covers. It is not possible for me to deploy Sender-ID without knowing what is covered by the claimed IPR. Therefore, I suggest that Sender-ID be abandoned and an alternative - such as SPF - be submitted instead. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 11:39: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 LAA15570 for ; Tue, 24 Aug 2004 11:39: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 i7OF7uCL092379; Tue, 24 Aug 2004 08:07: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 i7OF7uOb092378; Tue, 24 Aug 2004 08:07:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from deepskytech.com (mail.deepskytech.com [63.175.177.49] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OF7svS092351 for ; Tue, 24 Aug 2004 08:07:55 -0700 (PDT) (envelope-from sgwillis@deepskytech.com) Received: from [63.175.177.201] (63.175.177.201) by deepskytech.com with ESMTP (Eudora Internet Mail Server 3.2.5) for ; Tue, 24 Aug 2004 15:07:54 +0100 Date: Tue, 24 Aug 2004 15:08:01 +0000 From: "Steven G. Willis" Subject: Re: TECH-OMISSION: failure action is too restrictive in -core To: IETF MARID WG X-Priority: 3 In-Reply-To: <16682.31328.393827.721202@proton.pathname.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: Mailsmith 2.1.2 (Blindsider) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OF7tvS092366 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit It hath once been written: > >In section 5.3, this specification assumes all SPF checking will be done >at SMTP time which is not realistic. Some examples: some >implementations may retest a message later to either verify Sender-ID >results, because the load was too high when the message was received, >because the SPF checking was done after-SMTP (SpamAssassin). >... Sorry, but I do think this should be the case. The SPF checks are not excessively intensive in almost all cases. Now, given, I did say in _almost_ all cases. Of course, excessive loads may be an issue to have to consider. But, considering the SPF checks are RFC 2821 checks, it would be much better for all SPF checks to be done during the envelope exchange. If you are having a load issue, would it not be better to defer the connection with a 4XX response? Having the remote MTA try the connection again at a later time would allow for an abatement to the the heavy load the receiving MTA may be experiencing. This seems much preferable as it would alleviate the need for any DATA to be transmitted during the session. Cheers! ================================================================ Steven G. Willis sgwillis@deepskytech.com 772.794.9494 Deep Sky Technologies, Inc. http://www.deepskytech.com/ http://www.badchickens.com/ http://www.store-secure.com/ AIM-iChat: dstisgwillis ================================================================ A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon? ================================================================ From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 12:29: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 MAA19271 for ; Tue, 24 Aug 2004 12:29:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFwVc6004728; Tue, 24 Aug 2004 08:58: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 i7OFwViW004727; Tue, 24 Aug 2004 08:58:31 -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 i7OFwVDd004691 for ; Tue, 24 Aug 2004 08:58:31 -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 i7OFwQ57028242; Tue, 24 Aug 2004 08:58:26 -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 i7OFwLRG009022; Tue, 24 Aug 2004 08:58:24 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsof t.com> References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsof t.com> Date: Tue, 24 Aug 2004 08:58:19 -0700 To: "Jim Lyon" , "IETF MARID WG" From: Ted Hardie Subject: Re: TECH-ERROR: DNS Record Types 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:09 PM -0700 8/23/04, Jim Lyon wrote: > >I respectfully request that the above requirements be replaced with: > >1.Pushblishers SHOULD publish using the new SPF2 record type, > if they are able to do so. >2. Regardless of whether they published using the SPF2 record > type, publishers MUST publish a TXT record. I am concerned that MUST here means that we can never transition. While I would agree with shifting SPF2 from MUST to SHOULD, I believe, speaking personally, that strengthening MAY to MUST goes to far. Both as SHOULDs makes some sense; at the moment someone can deploy without SPF2 if they cannot publish the new record, but in the future someone can deploy without publishing a TXT record (which they may want to do in order to use TXT for something else). Again, speaking personally, regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 12:53:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22004 for ; Tue, 24 Aug 2004 12:53:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGMWI2009661; Tue, 24 Aug 2004 09:22: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 i7OGMWS1009660; Tue, 24 Aug 2004 09:22:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGMWNi009649 for ; Tue, 24 Aug 2004 09:22:32 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7OGMTXM016343; Tue, 24 Aug 2004 09:22:30 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 09:22:29 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Chris Haynes'" , IETF MARID WG Subject: RE: DEPLOY: Legal liability for creating bounces from forged mess ages Date: Tue, 24 Aug 2004 09:22:22 -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: > Suppose the original message, copied into the bounce, > contains pornography which is illegal under English law. First off, there is nothing that requires you to copy anything into the bounce. Secondly if it is an automatic process your liability would be no greater than it would be following original SMTP. There is no English law against 'pornography', the actual offense is publication of obscenity. There is a whole rack of issues here, first publication on the Internet has been addressed in the English courts, there has to be actual knowledge or at the very least a constructive effort to avoid knowledge of the contents for publication to have occured. Then when you get into the obscenity definitions you have a whole rack of further intent issues. If you are worried about creating liability don't copy information. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 12:57:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22408 for ; Tue, 24 Aug 2004 12:57: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 i7OGQx9p010588; Tue, 24 Aug 2004 09:26: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 i7OGQxKn010587; Tue, 24 Aug 2004 09:26:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGQw8x010578 for ; Tue, 24 Aug 2004 09:26:58 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7OGR0At013669; Tue, 24 Aug 2004 09:27:01 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 09:27:00 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Graham Murray'" , ietf-mxcomp@imc.org Subject: RE: DEPLOY - IPR on Sender-ID not sufficiently disclosed Date: Tue, 24 Aug 2004 09:26:54 -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: > Despite the 23rd August deadline, the full IPR claims on Sender-ID > have not been disclosed. The licence terms have been disclosed, but > insufficient (almost no) information has been given on what the > claimed IPR covers. > > It is not possible for me to deploy Sender-ID without knowing what is > covered by the claimed IPR. Therefore, I suggest that Sender-ID be > abandoned and an alternative - such as SPF - be submitted instead. You do not know whether the claimed IPR covers SPF. CallerID predates the origin of SPF. There is no requirement for the specific terms claimed to be raised, only the license is relevant. Nobody can tell you what the claims are until the USPTO makes its decision. As of today there are no claims whatsoever, only potential claims. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:15: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 NAA24322 for ; Tue, 24 Aug 2004 13:15: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 i7OGhCWp014581; Tue, 24 Aug 2004 09:43:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OGhCGx014580; Tue, 24 Aug 2004 09:43:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGhBH5014568 for ; Tue, 24 Aug 2004 09:43:12 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OGqOpt018321; Tue, 24 Aug 2004 12:52:24 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Mark Shewmaker'" , "'IETF MARID List'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License Date: Tue, 24 Aug 2004 12:41:34 -0400 Message-ID: <00a801c489f9$387d1500$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > Sent: Tuesday, August 24, 2004 10:32 AM > To: 'Mark Shewmaker'; IETF MARID List > Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License > > > > > > This patent license is incompatible with the Open Source > > Definition, the > > Free Software Definition, the Debian Free Software > Guidelines, and the > > GPL and LGPL licenses specifically. > > I disagree. I believe that the fundamental error made by the author > is to confuse a patent use license with a copyright distribution > license. Irrelevant when the patent is used to control the software that would otherwise be distributed under the copyright distribution. > > A patent is not a source code. A patent does not do anything on > its own. Source code does. Patents are a completely different form of > intellectual property. True, but if the patent is used to control the source code, the difference is trivial and irrelevant. > > The license terms that are appropriate for a standard are completely > different from those that are appropriate for an application. IFF the license for the standard is not used to exert control over the application. The license described DOES exert control over the application, via source revisions and licensing redistribution thereof. > > > 1. fixing the license to address all its problems (described in > > detail below), > > I believe that this has been achieved. You are incorrect. (see above and below) > > > 1. Issue: > > ====== > > > > Whatever IPR rights you might obtain for yourself > > won't extend to everyone who gets a copy of your code. > > > > > o Violates OSD #7, DFSG #7 > > > > | Distribution of License > > | > > | The rights attached to the program must apply to > all to whom > > | the program is redistributed without the need for execution > > | of an additional license by those parties. > > TO THE PROGRAM So what? A standard is irrelevant if there is no program that implements it. > > > > o Fails Dissident test. > > > > | The Dissident test. > > | > > | Consider a dissident in a totalitarian state who wishes to > > | share a modified bit of software with fellow > dissidents, but > > | does not wish to reveal the identity of the modifier, or > > I find this use of language pretty offensive. I have spent quite a bit > of time with real dissidents in real totalitarian states. Stick to the facts please. It was a concise and well illustrated example. Bullying a valid and well thought expression of opinion does not accomplish anything. > > > o Violates Freedom #2 > > > > | The freedom to redistribute copies so you can help your > > | neighbor > > You can redistribute copies of the software to your neighbor, > they can > modify them. > > The only party that can't use the technology is someone who is making > an IP claim over it. So if there was a company called OCS who decided > to sue Microsoft over the use of their technology in SenderID, they > could not obtain a license. Huh? As indicated in a previous thread channel partners of sendmail would have to sign the license, only because they change the source code, nothing to do with if the have an IP claim or not. > > > o Violates Freedom #3 > > > > | The freedom to improve the program, and release your > > | improvements to the public, so that the whole community > > | benefits > > Actually you can, read it. Free means "without restriction". Having to sign a license is NOT "without restriction" hence not FREE > > > > 2. Issue: > > ====== > > > > Whatever Microsoft's unspecified IPR supposedly covers, > > you can't do anything with it except Sender-ID-ish things. > > Any claims that do not relate to Sender-ID are by definition > irrelevant to this working group. But the license issue *is* relevant. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:19: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 NAA24482 for ; Tue, 24 Aug 2004 13: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 i7OGqFX3016790; Tue, 24 Aug 2004 09:52: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 i7OGqFVW016789; Tue, 24 Aug 2004 09:52:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGqECQ016772 for ; Tue, 24 Aug 2004 09:52:14 -0700 (PDT) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id i7OGqAbn033418; Tue, 24 Aug 2004 16:52:10 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.12.9-20030917/8.12.9) with ESMTP id i7OGqAI9013594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 18:52:10 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i7OGqAvK013593; Tue, 24 Aug 2004 18:52:10 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Tue, 24 Aug 2004 18:52:10 +0200 From: gmc@metro.cx To: Harry Katz Cc: IETF MARID List Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Message-ID: <20040824165210.GB13538@metro.cx> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, Again, I come out of the darkness of my lurking position and speak up my mind. I have been watching the discussions on this list continuously, and technically there is not a lot against Sender-ID (although some proper objections have been made, which I will not repeat here). I have been worried about the licensing issue, but have been convinced to wait it out. Now, with the 23 august deadline passed, I still see that there is reason for concern. Although a license has been prepared, it still does not say what exactly is licensed. I refer to Harry Katz' remark: > If you have any further questions about the license, I encourage you to > consult with your own attorney and/or email your question to > stdsreq@microsoft.com. Someone from our legal department will answer > your questions. I am not prepared to contact my attorney (i don't have one) to do open-source development on Sender-ID. For me, this means all work on Sender-ID is a nono. I will continue to labour for SPF+SRS. I can only hope the SPF Classic drafts (or better, Unified SPF) will be MARID's proposal, replacing the technically imperfect and legally troublesome Sender-ID proposal, but failing that I (and I believe many others) will continue work on SPF. It would be a shame if this leads to a split, where one part of the industry/community works on Sender-ID and another works on SPF. This will frustrate the general cause we are 'fighting' for. Koen Martens P.s.: note that there are many people lurking on the list as did I, reluctant to step in and join a debate among real experts that seem to have a more than thorough knowledge of email. I hope many of them will step forward, and voice their concern about this IPR business now, or else it might just be too late. -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:19: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 NAA24508 for ; Tue, 24 Aug 2004 13:19: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 i7OGtfpD017502; Tue, 24 Aug 2004 09:55: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 i7OGtfnT017501; Tue, 24 Aug 2004 09:55:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGtfMO017493 for ; Tue, 24 Aug 2004 09:55:41 -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, 24 Aug 2004 09:55:41 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 2004 09:55:41 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 09:55:41 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 09:55: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: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination Date: Tue, 24 Aug 2004 09:55:28 -0700 Message-ID: Thread-Topic: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination thread-index: AcSJrmEIpb+gkDmMRkyKrFNl8FjXegATBwKA From: "Harry Katz" To: "Roy Arends" , "IETF MARID List" X-OriginalArrivalTime: 24 Aug 2004 16:55:57.0109 (UTC) FILETIME=[39B3AE50:01C489FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OGtfMO017496 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tuesday, August 24, 2004 12:36 AM, Roy Arends wrote: > On Mon, 23 Aug 2004, Harry Katz wrote: > > > The following IPR disclosure statement was sent to statements@ietf.org > > earlier today. > > What I'm concerned about is that licensing of technology > developed and published through the IETF sets a precedent. > We'll be drifting from the mudpool to the quicksand. There are dozens and dozens of IETF specifications that have associated IPR claims. Please refer to http://www.ietf.org/ipr.html for a current list. In fact this "precedent" has long been established and, as I understand it, deliberately so in order to encourage organizations to contribue their IPR to standards efforts. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:23: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 NAA24811 for ; Tue, 24 Aug 2004 13:23:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGsldx017281; Tue, 24 Aug 2004 09:54: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 i7OGslb8017280; Tue, 24 Aug 2004 09:54:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGskHL017267 for ; Tue, 24 Aug 2004 09:54:46 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OH3tpt018970; Tue, 24 Aug 2004 13:03:55 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Graham Murray'" , Subject: RE: DEPLOY - IPR on Sender-ID not sufficiently disclosed Date: Tue, 24 Aug 2004 12:53:06 -0400 Message-ID: <00b401c489fa$d4678580$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit So people agreeing to move forward with PRA in sender id have to proceed knowing that the license may or may not be acceptable, but even if it is they have to proceed now knowing exactly what it will cover? Hence will now know what they can/cannot implement from sender id? > CallerID predates the origin of SPF. IRRELEVANT: We are not talking about CallerID, we are talking about Sender Id, remember? And MS merged with (some of) the spf community to form Sender ID. > As of today there are no claims whatsoever, only potential claims. IRRELEVANT: As of today there is no standard or software, just a potential standard that potentially software could be based on. Why are you so pushing people to proceed blindly without all the facts being laid out??? Microsoft was given plenty of time, and then plenty of time again to clarify. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > Sent: Tuesday, August 24, 2004 12:27 PM > To: 'Graham Murray'; ietf-mxcomp@imc.org > Subject: RE: DEPLOY - IPR on Sender-ID not sufficiently disclosed > > > > > > Despite the 23rd August deadline, the full IPR claims on Sender-ID > > have not been disclosed. The licence terms have been disclosed, but > > insufficient (almost no) information has been given on what the > > claimed IPR covers. > > > > It is not possible for me to deploy Sender-ID without > knowing what is > > covered by the claimed IPR. Therefore, I suggest that Sender-ID be > > abandoned and an alternative - such as SPF - be submitted instead. > > You do not know whether the claimed IPR covers SPF. > > CallerID predates the origin of SPF. > > There is no requirement for the specific terms claimed to be raised, > only the license is relevant. > > Nobody can tell you what the claims are until the USPTO makes its > decision. > > As of today there are no claims whatsoever, only potential claims. > From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:32:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26283 for ; Tue, 24 Aug 2004 13:32:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OH7Thb019847; Tue, 24 Aug 2004 10: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 i7OH7Tw6019846; Tue, 24 Aug 2004 10:07:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OH7SIT019839 for ; Tue, 24 Aug 2004 10:07:29 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OHGcpt019519; Tue, 24 Aug 2004 13:16:38 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 13:05:49 -0400 Message-ID: <00bf01c489fc$9b54b400$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > Sent: Tuesday, August 24, 2004 12:22 PM > To: 'Chris Haynes'; IETF MARID WG > Subject: RE: DEPLOY: Legal liability for creating bounces from forged > messages > > > > > > Suppose the original message, copied into the bounce, > > contains pornography which is illegal under English law. > > First off, there is nothing that requires you to copy > anything into the > bounce. Providing that you are willing to accept the original email LOST. Bounces are done to: 1) inform the sender the delivery failed 2) inform the sender WHICH email the deliver failed, where the WHICH is best defined by including the email so one can view the specifics of the email to deal with the matter further > > Secondly if it is an automatic process your liability would > be no greater > than it would be following original SMTP. Wrong. When you bounce it now knowing the validity of the bounce recipient has you have less liability then if you bounce it KNOWING that the bounce recipient is invalid. > > > There is no English law against 'pornography', the actual offense is > publication of obscenity. Irrelevant, especially for many other countries, but even for areas under "English" laws because "publication" is not sufficiently concise in this context and hence open to interpretation. > > There is a whole rack of issues here, first publication on > the Internet has > been addressed in the English courts, there has to be actual > knowledge or at > the very least a constructive effort to avoid knowledge of > the contents for > publication to have occured. Then when you get into the obscenity > definitions you have a whole rack of further intent issues. That may be sufficient for some to believe, but "ignorance is no excuse" has been the big stick that many courts have wielded time and again. > > If you are worried about creating liability don't copy information. > If your "mail as reliable communication" means nothing to you, yes. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:34:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26566 for ; Tue, 24 Aug 2004 13:34:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHBTAO020769; Tue, 24 Aug 2004 10:11: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 i7OHBTev020768; Tue, 24 Aug 2004 10:11:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHBSR7020758 for ; Tue, 24 Aug 2004 10:11:28 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OHKept019833; Tue, 24 Aug 2004 13:20:40 -0400 From: To: , "'Harry Katz'" Cc: "'IETF MARID List'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Tue, 24 Aug 2004 13:09:51 -0400 Message-ID: <00c101c489fd$2bbdb280$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20040824165210.GB13538@metro.cx> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I concur, the vague license application issues, as they currently remain (un)stated, are unacceptable. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of gmc@metro.cx > Sent: Tuesday, August 24, 2004 12:52 PM > To: Harry Katz > Cc: IETF MARID List > Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent > License FAQ > > > > All, > > Again, I come out of the darkness of my lurking position and > speak up my > mind. > > I have been watching the discussions on this list continuously, and > technically there is not a lot against Sender-ID (although some proper > objections have been made, which I will not repeat here). > > I have been worried about the licensing issue, but have been convinced > to wait it out. Now, with the 23 august deadline passed, I still see > that there is reason for concern. Although a license has been > prepared, > it still does not say what exactly is licensed. > > I refer to Harry Katz' remark: > > > If you have any further questions about the license, I > encourage you to > > consult with your own attorney and/or email your question to > > stdsreq@microsoft.com. Someone from our legal department > will answer > > your questions. > > I am not prepared to contact my attorney (i don't have one) to do > open-source development on Sender-ID. For me, this means all work on > Sender-ID is a nono. I will continue to labour for SPF+SRS. I can only > hope the SPF Classic drafts (or better, Unified SPF) will be MARID's > proposal, replacing the technically imperfect and legally troublesome > Sender-ID proposal, but failing that I (and I believe many others) > will continue work on SPF. > > It would be a shame if this leads to a split, where one part of the > industry/community works on Sender-ID and another works on SPF. This > will frustrate the general cause we are 'fighting' for. > > > Koen Martens > > P.s.: note that there are many people lurking on the list as did I, > reluctant to step in and join a debate among real experts that seem to > have a more than thorough knowledge of email. I hope many of them will > step forward, and voice their concern about this IPR business now, or > else it might just be too late. > > -- > K.F.J. Martens, Sonologic, http://www.sonologic.nl/ > Networking, embedded systems, unix expertise, artificial intelligence. > Public PGP key: http://www.metro.cx/pubkey-gmc.asc > Wondering about the funny attachment your mail program > can't read? Visit http://www.openpgp.org/ > From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:47: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 NAA27598 for ; Tue, 24 Aug 2004 13:47: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 i7OHK7Gt022891; Tue, 24 Aug 2004 10:20: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 i7OHK74E022890; Tue, 24 Aug 2004 10:20:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHK6Uj022877 for ; Tue, 24 Aug 2004 10:20:06 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OHT7pt020600; Tue, 24 Aug 2004 13:29:07 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 13:17:50 -0400 Message-ID: <00c801c489fe$59742960$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <00bf01c489fc$9b54b400$2766f30a@development.greatgulfhomes.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry for the typo, that should read: Wrong. When you bounce it knowing the validity of the bounce recipient you have less liability then if you bounce it KNOWING that the bounce recipient is invalid. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of > terry@ashtonwoodshomes.com > Sent: Tuesday, August 24, 2004 1:06 PM > To: 'Hallam-Baker, Phillip'; 'Chris Haynes'; 'IETF MARID WG' > Subject: RE: DEPLOY: Legal liability for creating bounces from forged > messages > > > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > > Phillip > > Sent: Tuesday, August 24, 2004 12:22 PM > > To: 'Chris Haynes'; IETF MARID WG > > Subject: RE: DEPLOY: Legal liability for creating bounces > from forged > > messages > > > > > > > > > > > Suppose the original message, copied into the bounce, > > > contains pornography which is illegal under English law. > > > > First off, there is nothing that requires you to copy > > anything into the > > bounce. > > Providing that you are willing to accept the original email > LOST. Bounces are done to: > 1) inform the sender the delivery failed > 2) inform the sender WHICH email the deliver failed, where > the WHICH is best defined by including > the email so one can view the specifics of the email to deal > with the matter further > > > > > Secondly if it is an automatic process your liability would > > be no greater > > than it would be following original SMTP. > > Wrong. When you bounce it now knowing the validity of the > bounce recipient has you have less > liability then if you bounce it KNOWING that the bounce > recipient is invalid. > > > > > > > There is no English law against 'pornography', the actual offense is > > publication of obscenity. > Irrelevant, especially for many other countries, but even for > areas under "English" laws because > "publication" is not sufficiently concise in this context and > hence open to interpretation. > > > > > There is a whole rack of issues here, first publication on > > the Internet has > > been addressed in the English courts, there has to be actual > > knowledge or at > > the very least a constructive effort to avoid knowledge of > > the contents for > > publication to have occured. Then when you get into the obscenity > > definitions you have a whole rack of further intent issues. > That may be sufficient for some to believe, but "ignorance is > no excuse" has been the big stick that > many courts have wielded time and again. > > > > > > If you are worried about creating liability don't copy information. > > > > If your "mail as reliable communication" means nothing to you, yes. > From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:49:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27762 for ; Tue, 24 Aug 2004 13:49: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 i7OHPQ9E024372; Tue, 24 Aug 2004 10:25:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHPQvb024371; Tue, 24 Aug 2004 10:25:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from knecht.Neophilic.COM (dsl081-247-036.sfo1.dsl.speakeasy.net [64.81.247.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHPQsD024346 for ; Tue, 24 Aug 2004 10:25:26 -0700 (PDT) (envelope-from eric@sendmail.org) Received: from [10.0.2.36] (knecht.Sendmail.ORG [10.0.2.36] (may be forged)) by knecht.Neophilic.COM (8.13.1/8.13.1) with ESMTP id i7OHPJNQ041915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 10:25:19 -0700 (PDT) Date: Tue, 24 Aug 2004 10:25:19 -0700 From: Eric Allman To: Roy Arends cc: IETF MARID List Subject: Re: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on knecht.sendmail.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit If I'm understanding you, there is no new precedent. http://www.ietf.org/ipr.html shows many preexisting IPR claims on a variety of IETF drafts and RFCs. eric --On Tuesday, August 24, 2004 09:36:06 +0200 Roy Arends wrote: | | On Mon, 23 Aug 2004, Harry Katz wrote: | | > The following IPR disclosure statement was sent to | > statements@ietf.org earlier today. | | What I'm concerned about is that licensing of technology developed | and published through the IETF sets a precedent. We'll be drifting | from the mudpool to the quicksand. | | Roy Arends | | From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:52: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 NAA27925 for ; Tue, 24 Aug 2004 13:52: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 i7OHQWE9024609; Tue, 24 Aug 2004 10:26:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHQW6J024608; Tue, 24 Aug 2004 10:26:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHQVQW024575 for ; Tue, 24 Aug 2004 10:26:31 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i7OHQQ3V005972 for ; Tue, 24 Aug 2004 10:26:30 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id B8C1E84F866; Tue, 24 Aug 2004 10:26:26 -0700 (PDT) Date: Tue, 24 Aug 2004 10:26:26 -0700 From: "Mark C. Langston" To: "'IETF MARID List'" Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Message-ID: <20040824172626.GZ41046@bitshift.org> References: <20040824165210.GB13538@metro.cx> <00c101c489fd$2bbdb280$2766f30a@development.greatgulfhomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c101c489fd$2bbdb280$2766f30a@development.greatgulfhomes.com> User-Agent: Mutt/1.4.1i X-Uptime: 10:19AM up 70 days, 18:26, 7 users, load averages: 0.67, 0.28, 0.12 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd have to agree with Koen. I'm adding SPFv1 checks to GOSSiP. I'd like to support the eventual product of MARID, but given the current license confusion, I can't, nor am I inclined to. This isn't a "I won't support anything from Microsoft" position; this is a "It's not entirely clear to me what rights I retain and which I surrender by including a Sender-ID implementation in my code." position. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:54:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28149 for ; Tue, 24 Aug 2004 13:54:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHUFvE025484; Tue, 24 Aug 2004 10:30: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 i7OHUF1Z025482; Tue, 24 Aug 2004 10:30:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHUE1H025472 for ; Tue, 24 Aug 2004 10:30:15 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1Bzf7c-0005E8-00; Tue, 24 Aug 2004 18:30:12 +0100 Message-ID: <094101c489ff$b3ffd450$0200000a@ringo> From: "Chris Haynes" To: "Hallam-Baker, Phillip" Cc: "IETF MARID WG" References: Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 18:27:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "Hallam-Baker, Phillip" replied: > > > Suppose the original message, copied into the bounce, > > contains pornography which is illegal under English law. > > First off, there is nothing that requires you to copy anything into the > bounce. If I reject at SMPT time with a 5**, it is common practice, over which I have no control, for the offering MTA to include the message content. Nevertheless I will have been the 'agent' requesting that message to be propogated, when it was I who knew that it had been forged. Also note the repost of terry@ashtonwoodshomes.com > > Secondly if it is an automatic process your liability would be no greater > than it would be following original SMTP. > I am legally liable for any process I put in place, automated or manual. Original SMTP had no way of telling me 'this is a forgery'. The whole point of this thread is that it appears to me that Sender-ID may change the legal liabilities and obligations. In the absence of authoritative legal advice, I choose caution, I choose not to deploy Sender-ID. > > > There is no English law against 'pornography', the actual offense is > publication of obscenity. I never said there was. I was using teminology which would be appropriate for an international readership. In any case, substitute Phishing a.k.a. Attempted Fraud throughout my argument, if you prefer. > > There is a whole rack of issues here, first publication on the Internet has > been addressed in the English courts, there has to be actual knowledge or at > the very least a constructive effort to avoid knowledge of the contents for > publication to have occured. Then when you get into the obscenity > definitions you have a whole rack of further intent issues. Are you / your employer / Microsoft / the IETF prepared to indemnify my businesses against prosocution? > > If you are worried about creating liability don't copy information. > All I need to do to avoid this worry is to not deploy Sender-ID. Then I can continue with my business of copying and moving information with a clear conscience. Chris From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 13:58:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28380 for ; Tue, 24 Aug 2004 13:58:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHXN9f026269; Tue, 24 Aug 2004 10:33:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHXNLY026268; Tue, 24 Aug 2004 10:33:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHXNGX026251 for ; Tue, 24 Aug 2004 10:33:23 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 24 Aug 2004 13:33:24 -0400 id 0015F9D5.412B7BE4.0000482C In-Reply-To: References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Mark Lentczner , IETF MARID WG From: Andrew Newton Subject: Re: TECH-ERROR: DNS Record Types Date: Tue, 24 Aug 2004 13:33:23 -0400 To: "=?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?=" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 1:25 AM, Mark Lentczner wrote: > Andy: Can we get him in? Olafur, Can you please provide comment on the DNS record type language in draft-ietf-marid-protocol and the last call comments made by Jim Lyon regarding compliance. -andy From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 14:03: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 OAA28810 for ; Tue, 24 Aug 2004 14:03: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 i7OHdm3m027781; Tue, 24 Aug 2004 10:39: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 i7OHdmtU027780; Tue, 24 Aug 2004 10:39:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHdliE027769 for ; Tue, 24 Aug 2004 10:39:47 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7OHdZeL019183; Tue, 24 Aug 2004 10:39:35 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 10:39:35 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'terry@ashtonwoodshomes.com'" , "Hallam-Baker, Phillip" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged mess ages Date: Tue, 24 Aug 2004 10:39:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > First off, there is nothing that requires you to copy > > anything into the > > bounce. > > Providing that you are willing to accept the original email > LOST. Bounces are done to: In this case it would suffice to notify the purported sender that a message from them failed validation. It is not necessary to quote any of the text of the message. > > Secondly if it is an automatic process your liability would > > be no greater > > than it would be following original SMTP. > > Wrong. When you bounce it now knowing the validity of the > bounce recipient has you have less > liability then if you bounce it KNOWING that the bounce > recipient is invalid. One way that the spec could be improved would be to state that the sender SHOULD notify the purported sender without mandating the use of a particular mechanism, specify bounces as the fallback mechanism. At some point we need a better mechanism for reporting failures of all kinds. Something that is authenticated and out of band. > That may be sufficient for some to believe, but "ignorance is > no excuse" has been the big stick that > many courts have wielded time and again. Ignorance of the law is no excuse. Absence of intent or knowledge on the other hand is one of the strongest defenses possible in almost all cases. Look up Mens Rea. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 14:10:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29478 for ; Tue, 24 Aug 2004 14:10:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHhpvN028535; Tue, 24 Aug 2004 10:43: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 i7OHhpVW028534; Tue, 24 Aug 2004 10:43:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHhmYN028520 for ; Tue, 24 Aug 2004 10:43:50 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7OHhX7n021784; Tue, 24 Aug 2004 10:43:33 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 10:43:33 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'terry@ashtonwoodshomes.com'" , "Hallam-Baker, Phillip" , "'Mark Shewmaker'" , "'IETF MARID List'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License Date: Tue, 24 Aug 2004 10:43: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: > > I disagree. I believe that the fundamental error made by the author > > is to confuse a patent use license with a copyright distribution > > license. > > Irrelevant when the patent is used to control the software > that would otherwise be distributed under > the copyright distribution. On the contrary, it is like the difference between constraints on a compiler and constraints on the code produced with that compiler. > > A patent is not a source code. A patent does not do anything on > > its own. Source code does. Patents are a completely > different form of > > intellectual property. > > True, but if the patent is used to control the source code, > the difference is trivial and irrelevant. This is a very complex legal argument, calling it trivial shows a distinct lack of comprehension. > > TO THE PROGRAM > > So what? A standard is irrelevant if there is no program > that implements it. Plans are irrelevant if no house is ever built to them. But that does not mean that a plans are the same as a house, the fact that a plan is copyright and certain rights on the distribution are reserved does not mean that the copy is encumbered. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 14:23: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 OAA00510 for ; Tue, 24 Aug 2004 14:23:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHxLPM032201; Tue, 24 Aug 2004 10:59: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 i7OHxL1W032200; Tue, 24 Aug 2004 10:59:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHxK08032191 for ; Tue, 24 Aug 2004 10:59:21 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OI8Upt022690; Tue, 24 Aug 2004 14:08:30 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 13:57:39 -0400 Message-ID: <00fa01c48a03$da141260$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > That may be sufficient for some to believe, but "ignorance is > > no excuse" has been the big stick that > > many courts have wielded time and again. > > Ignorance of the law is no excuse. Absence of intent or knowledge > on the other hand is one of the strongest defenses possible in > almost all cases. > > Look up Mens Rea. > The "culpable mental state" of Mens Rea is not applicable here: 1) We are bouncing BECAUSE we know the email to be bad with reasonable high probability, 2) the bounce recipient is known to be invalid (which is what I object to, don't bounce to when you *know* the bounce target is an uninvolved third party) Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 14:28: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 OAA00707 for ; Tue, 24 Aug 2004 14:28: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 i7OI50Wg033437; Tue, 24 Aug 2004 11:05:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OI50fL033436; Tue, 24 Aug 2004 11:05:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OI50qt033429 for ; Tue, 24 Aug 2004 11:05:00 -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; Tue, 24 Aug 2004 14:05:03 -0400 id 0015FA7C.412B834F.00004BE4 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: Andrew Newton Subject: Re: DEPLOY - IPR on Sender-ID not sufficiently disclosed Date: Tue, 24 Aug 2004 14:05:02 -0400 To: Graham Murray X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 10:35 AM, Graham Murray wrote: > The licence terms have been disclosed, but > insufficient (almost no) information has been given on what the > claimed IPR covers. Please reread: http://www.imc.org/ietf-mxcomp/mail-archive/msg03495.html -andy From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 14:32: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 OAA01136 for ; Tue, 24 Aug 2004 14:32: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 i7OI7rpi034205; Tue, 24 Aug 2004 11: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 i7OI7rfr034204; Tue, 24 Aug 2004 11:07:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OI7qCJ034196 for ; Tue, 24 Aug 2004 11:07:52 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OIH6pt023377; Tue, 24 Aug 2004 14:17:06 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Mark Shewmaker'" , "'IETF MARID List'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License Date: Tue, 24 Aug 2004 14:06:17 -0400 Message-ID: <010701c48a05$0d95b0c0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Tuesday, August 24, 2004 1:44 PM > To: 'terry@ashtonwoodshomes.com'; Hallam-Baker, Phillip; 'Mark > Shewmaker'; 'IETF MARID List' > Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License > > > > > > I disagree. I believe that the fundamental error made by > the author > > > is to confuse a patent use license with a copyright distribution > > > license. > > > > Irrelevant when the patent is used to control the software > > that would otherwise be distributed under > > the copyright distribution. > > On the contrary, it is like the difference between constraints on > a compiler and constraints on the code produced with that compiler. Valid point. But the question is, will it just be applied to the compiler or the compiled code. As stated elsewhere, the license is now published, the scope of the IPR is NOT. > > > > > A patent is not a source code. A patent does not do anything on > > > its own. Source code does. Patents are a completely > > different form of > > > intellectual property. > > > > True, but if the patent is used to control the source code, > > the difference is trivial and irrelevant. > > This is a very complex legal argument, calling it trivial shows a > distinct lack of comprehension. Your bullying tactics are still not worthy of your intelligence (or perhaps I misjudge that). The literal interpretation of my statement was, and still is, the "difference" that YOU stated is "trivial and irrelevant", not the legal arguments themselves. > > > > > TO THE PROGRAM > > > > So what? A standard is irrelevant if there is no program > > that implements it. > > Plans are irrelevant if no house is ever built to them. But that > does not mean that a plans are the same as a house, the fact that > a plan is copyright and certain rights on the distribution are > reserved does not mean that the copy is encumbered. > But it does not mean the copy is NOT encumbered, either. And you keep forgetting that the IPR is STILL UNSTATED!!! All we have been given is the (unacceptable) license, but not what the license covers! From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 14:43:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01983 for ; Tue, 24 Aug 2004 14:43: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 i7OIJ7NJ036540; Tue, 24 Aug 2004 11:19: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 i7OIJ7Sk036539; Tue, 24 Aug 2004 11:19:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIJ6vM036533 for ; Tue, 24 Aug 2004 11:19:06 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7OIGklr024048; Tue, 24 Aug 2004 11:16:46 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 11:16:46 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'terry@ashtonwoodshomes.com'" , "Hallam-Baker, Phillip" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged mess ages Date: Tue, 24 Aug 2004 11:16: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: > Sorry for the typo, that should read: > Wrong. When you bounce it knowing the validity of the > bounce recipient you have less liability then if you bounce > it KNOWING that the bounce > recipient is invalid. Where is the Mens Rea? The UK obscene publications act is a criminal offense, the issue is whether the action is criminal, not whether there is a civil liability. What the computer 'knows' is not relevant to Mens Rea, only individuals and corporations are subject to criminal law. The last time an animal was prosecuted under English common law was when the citizens of Sunderland hung a monkey as a spy during the Napoleonic wars. The only occasion I am aware of in which an inanimate object was put on trial was before the Norman Conquest when a statue of the Virgin Mary was convicted of murder and is believed to lie in a grave that can be seen from my parent's house. Sure you can find some really obscure offenses if you dredge up obscure parts of English law. That does not mean that there is the slightest chance that a Home Secretary is ever going to allow a prosecution. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 14:43: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 OAA02001 for ; Tue, 24 Aug 2004 14:43: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 i7OIJAe9036553; Tue, 24 Aug 2004 11:19: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 i7OIJAio036552; Tue, 24 Aug 2004 11:19:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIJ9m8036545 for ; Tue, 24 Aug 2004 11:19:09 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OIS1pt024122; Tue, 24 Aug 2004 14:28:01 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 14:17:12 -0400 Message-ID: <011801c48a06$9458c920$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > Sent: Tuesday, August 24, 2004 1:40 PM > To: 'terry@ashtonwoodshomes.com'; Hallam-Baker, Phillip; > 'Chris Haynes'; > 'IETF MARID WG' > Subject: RE: DEPLOY: Legal liability for creating bounces from forged > messages > > > > > > > First off, there is nothing that requires you to copy > > > anything into the > > > bounce. > > > > Providing that you are willing to accept the original email > > LOST. Bounces are done to: > > In this case it would suffice to notify the purported sender that > a message from them failed validation. It is not necessary to > quote any of the text of the message. NOT if you are among those who believe the email is reliable transport. Once your MTA has accepted an email you are obliged to either: 1) deliver it 2) return it as undeliverable In this case, refusing it in the first place is MUCH MUCH better (see SPF classic, or the middle ground Unified SPF) But, as the list was requested, I am simply pointing out DEPLOYment problems. > > > > > Secondly if it is an automatic process your liability would > > > be no greater > > > than it would be following original SMTP. > > > > Wrong. When you bounce it now knowing the validity of the > > bounce recipient has you have less > > liability then if you bounce it KNOWING that the bounce > > recipient is invalid. > > > One way that the spec could be improved would be to state that the > sender SHOULD notify the purported sender without mandating the > use of a particular mechanism, specify bounces as the fallback > mechanism. Fine. But if you believe that SMTP is used for reliable communication, you have to do *something* with it. What do you propose instead? Silently delete it? Pass it off to the original recipients postmaster? Neither is viable or acceptable in the context of RELIABLE message transfer. > > At some point we need a better mechanism for reporting failures > of all kinds. Something that is authenticated and out of band. Uh, yeah. Thanks for stating that, but better SMTP is *exactly* what we are all working towards here. I am just not sure that SenderID (as stated) is better then what we have (if it creates more bounces, or allows bounces to known forged recipient address). > > > > That may be sufficient for some to believe, but "ignorance is > > no excuse" has been the big stick that > > many courts have wielded time and again. > > Ignorance of the law is no excuse. Absence of intent or knowledge > on the other hand is one of the strongest defenses possible in > almost all cases. > > Look up Mens Rea. > The "culpable mental state" of Mens Rea is not applicable here: 1) We are bouncing BECAUSE we know the email to be bad with reasonable high probability, 2) the bounce recipient is known to be invalid (which is what I object to, don't bounce to when you *know* the bounce target is an uninvolved third party) From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 14:45: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 OAA02139 for ; Tue, 24 Aug 2004 14:45: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 i7OIMJRA037101; Tue, 24 Aug 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 i7OIMJUY037100; Tue, 24 Aug 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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIMJvW037094 for ; Tue, 24 Aug 2004 11:22:19 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7OIM1nK024377; Tue, 24 Aug 2004 11:22:01 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 11:22:01 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'terry@ashtonwoodshomes.com'" , "Hallam-Baker, Phillip" , "'Mark Shewmaker'" , "'IETF MARID List'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License Date: Tue, 24 Aug 2004 11:21:58 -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: > Valid point. But the question is, will it just be applied to > the compiler or the compiled code. As > stated elsewhere, the license is now published, the scope of > the IPR is NOT. The scope is precisely defined in the license as the intersection between the patent claims and the necessary claims required to implement the spec. > > This is a very complex legal argument, calling it trivial shows a > > distinct lack of comprehension. > > Your bullying tactics are still not worthy of your > intelligence (or perhaps I misjudge that). What is 'bullying' about answering an argument with facts. You asserted that the argument was trivial. > The literal interpretation of my statement was, and still is, > the "difference" that YOU stated is > "trivial and irrelevant", not the legal arguments themselves. The difference between the patent and the realization of the patent is the whole core of the legal arguments. > But it does not mean the copy is NOT encumbered, either. And > you keep forgetting that the IPR is > STILL UNSTATED!!! All we have been given is the > (unacceptable) license, but not what the license > covers! Again, read the license, it is very clear that it covers the intersection between any patent claims owned by or granted to Microsoft and those needed to implement Sender-ID. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15:12:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04210 for ; Tue, 24 Aug 2004 15:12: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 i7OIkE3p043031; Tue, 24 Aug 2004 11:46:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OIkEPm043030; Tue, 24 Aug 2004 11:46:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIkEYB043022 for ; Tue, 24 Aug 2004 11:46:14 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7OIk5hW024158; Tue, 24 Aug 2004 11:46:05 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 11:46:04 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'terry@ashtonwoodshomes.com'" , "Hallam-Baker, Phillip" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged mess ages Date: Tue, 24 Aug 2004 11:46:02 -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 this case it would suffice to notify the purported sender that > > a message from them failed validation. It is not necessary to > > quote any of the text of the message. > > NOT if you are among those who believe the email is reliable > transport. Once your MTA has accepted > an email you are obliged to either: > 1) deliver it > 2) return it as undeliverable If your understanding of English law is that you would be performing a criminal act by doing so, then your duty to the Queen would surely claim a higher priority than the mere opinions of this group? > > One way that the spec could be improved would be to state that the > > sender SHOULD notify the purported sender without mandating the > > use of a particular mechanism, specify bounces as the fallback > > mechanism. > > Fine. But if you believe that SMTP is used for reliable > communication, you have to do *something* > with it. Like fix the mess that is the SMTP spec. > What do you propose instead? Silently delete it? Lets see, more than 90% sure its garbage, delete it unless the sender suggests some other disposition. > Pass it off to the original recipients > postmaster? Neither is viable or acceptable in the context > of RELIABLE message transfer. SMTP is not a reliable mail transfer protocol, neither as originally described or as implemented. The first step towards making SMTP reliable is to put authentication in place. > The "culpable mental state" of Mens Rea is not applicable here: > 1) We are bouncing BECAUSE we know the email to be bad with > reasonable high probability, We have no specific knowledge that the email is pornographic. Mens Rea is not applicable to inanimate objects such as computers and statues and has not been since 950 or thereabouts. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15:18: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 PAA05073 for ; Tue, 24 Aug 2004 15:18: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 i7OIs83t045243; Tue, 24 Aug 2004 11:54:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OIs8dY045242; Tue, 24 Aug 2004 11:54:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIs8Ts045235 for ; Tue, 24 Aug 2004 11:54:08 -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); Tue, 24 Aug 2004 11:54:12 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 2004 11:54:12 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 11:54:11 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 11:54:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 11:54:09 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Legal liability for creating bounces from forged messages Thread-Index: AcSKCPRsgSO6V6lyT06jd3e5ur3oPgAAjokw From: "Jim Lyon" To: "Hallam-Baker, Phillip" , , "Chris Haynes" , "IETF MARID WG" X-OriginalArrivalTime: 24 Aug 2004 18:54:11.0727 (UTC) FILETIME=[BE6C79F0:01C48A0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OIs8Ts045236 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit This thread has devolved into a fascinating discussion of arcane points of British law, but it misses the fundamental point: A reasonable use of SenderID is to use it at SMTP time, and to refuse to accept forged mail. If you refuse to accept it (by giving an error at end of DATA), you won't generate a bounce. The MTA that was sending the mail might or might not generate a bounce, but that's his problem, not yours. In fact, most of the forged mail is sent by specialized spam engines or virus propagation engines. These engines won't generate bounces, they'll just give up and go on to the next victim. So, deploying SenderID should result in fewer bounces, not more. -- Jim Lyon -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Tuesday, August 24, 2004 11:17 AM To: 'terry@ashtonwoodshomes.com'; Hallam-Baker, Phillip; 'Chris Haynes'; 'IETF MARID WG' Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages > Sorry for the typo, that should read: > Wrong. When you bounce it knowing the validity of the > bounce recipient you have less liability then if you bounce > it KNOWING that the bounce > recipient is invalid. Where is the Mens Rea? The UK obscene publications act is a criminal offense, the issue is whether the action is criminal, not whether there is a civil liability. What the computer 'knows' is not relevant to Mens Rea, only individuals and corporations are subject to criminal law. The last time an animal was prosecuted under English common law was when the citizens of Sunderland hung a monkey as a spy during the Napoleonic wars. The only occasion I am aware of in which an inanimate object was put on trial was before the Norman Conquest when a statue of the Virgin Mary was convicted of murder and is believed to lie in a grave that can be seen from my parent's house. Sure you can find some really obscure offenses if you dredge up obscure parts of English law. That does not mean that there is the slightest chance that a Home Secretary is ever going to allow a prosecution. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15:21: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 PAA05222 for ; Tue, 24 Aug 2004 15:21:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIrgbM044736; Tue, 24 Aug 2004 11: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 i7OIrgc4044735; Tue, 24 Aug 2004 11:53:42 -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 i7OIrfV5044718 for ; Tue, 24 Aug 2004 11:53:41 -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 1BzgQJ-0003F2-41 for ietf-mxcomp@imc.org; Tue, 24 Aug 2004 13:53:42 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Tue, 24 Aug 2004 13:51:43 -0500 In-Reply-To: (Harry Katz's message of "Tue, 24 Aug 2004 09:55:28 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Harry Katz" writes: > On Tuesday, August 24, 2004 12:36 AM, Roy Arends wrote: > >> On Mon, 23 Aug 2004, Harry Katz wrote: >> >> > The following IPR disclosure statement was sent to > statements@ietf.org >> > earlier today. >> >> What I'm concerned about is that licensing of technology >> developed and published through the IETF sets a precedent. >> We'll be drifting from the mudpool to the quicksand. > > There are dozens and dozens of IETF specifications that have associated > IPR claims. Please refer to http://www.ietf.org/ipr.html for a current > list. There are, indeed, many other RFCs that have IPR claims. Several points, however: 1) Many people are not happy about this situation. (IIRC, there is an IETF IPR mailing for such discussions.) 2) Not all licenses are equal. For example, Cisco's patent license on http://www.ietf.org/ietf/IPR/cisco-ipr-draft-fenton-identified-mail-00.txt seems *much* more reasonable to me than MS's license for SenderID. (In particular, requiring a signed license for source code distributions is very burdensome.) 3) To quote directly from RFC3668 section 8: | 8. Evaluating alternative technologies in IETF working groups | | In general, IETF working groups prefer technologies with no known IPR | claims or, for technologies with claims against them, an offer of | royalty-free licensing. But IETF working groups have the discretion | to adopt technology with a commitment of fair and non-discriminatory | terms, or even with no licensing commitment, if they feel that this | technology is superior enough to alternatives with fewer IPR claims | or free licensing to outweigh the potential cost of the licenses. So, the question is: are there alternatives to the PRA that don't have the burden of IPR licenses and work just as well if not better? I think the answer to that is clearly yes. More over, I think the only reason why those alternatives have not been more fully explored is because it was assumed that Microsoft would make a license available that would not be burdensom. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15: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 PAA05242 for ; Tue, 24 Aug 2004 15: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 i7OItk6B045576; Tue, 24 Aug 2004 11:55:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OItklq045575; Tue, 24 Aug 2004 11:55:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OItjJE045566 for ; Tue, 24 Aug 2004 11:55:45 -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, 24 Aug 2004 11:55:46 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 2004 11:55:46 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 11:55:46 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 11:55: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: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Tue, 24 Aug 2004 11:34:48 -0700 Message-ID: Thread-Topic: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ thread-index: AcSKAvtIDph/TzDLTM+kdL0sX1/LFwABYdYg From: "Harry Katz" To: "Mark C. Langston" , "IETF MARID List" X-OriginalArrivalTime: 24 Aug 2004 18:55:46.0964 (UTC) FILETIME=[F7307D40:01C48A0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OItjJE045568 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Mark, if there's a specific part of the license you'd like clarified, I'd encourage you to send mail to stdsreq@microsoft.com. Someone from our legal department will answer your question. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Mark C. Langston > Sent: Tuesday, August 24, 2004 10:26 AM > To: 'IETF MARID List' > Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent > License FAQ > > > > I'd have to agree with Koen. I'm adding SPFv1 checks to > GOSSiP. I'd like to support the eventual product of MARID, > but given the current license confusion, I can't, nor am I > inclined to. This isn't a "I won't support anything from > Microsoft" position; this is a "It's not entirely clear to me > what rights I retain and which I surrender by including a > Sender-ID implementation in my code." position. > > -- > Mark C. Langston GOSSiP Project Sr. Unix SysAdmin > mark@bitshift.org http://sufficiently-advanced.net mark@seti.org > Systems & Network Admin Distributed SETI Institute > http://bitshift.org E-mail Reputation http://www.seti.org > > From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15:29:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05878 for ; Tue, 24 Aug 2004 15:29:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJ1XSA046791; Tue, 24 Aug 2004 12:01:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OJ1Xol046790; Tue, 24 Aug 2004 12:01:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from localhost.localdomain (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJ1Wux046766 for ; Tue, 24 Aug 2004 12:01:32 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (vodka [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i7OJ1JqK013269; Tue, 24 Aug 2004 12:01:19 -0700 Subject: Re: DEPLOY - IPR on Sender-ID not sufficiently disclosed From: Ryan Ordway To: Andrew Newton Cc: Graham Murray , ietf-mxcomp@imc.org In-Reply-To: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> References: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1093374079.12516.16.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 24 Aug 2004 12:01:19 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-24 at 11:05, Andrew Newton wrote: > On Aug 24, 2004, at 10:35 AM, Graham Murray wrote: > > > The licence terms have been disclosed, but > > insufficient (almost no) information has been given on what the > > claimed IPR covers. > > Please reread: > http://www.imc.org/ietf-mxcomp/mail-archive/msg03495.html Thanks Andrew. It sounds like some people may have missed the fact that IPR claims are being made on both -pra and -core: > C. If an Internet-Draft or RFC includes multiple parts and it is not > reasonably apparent which part of such Internet-Draft or RFC is > alleged to be covered by the patent information disclosed in > Section V(A) or V(B), it is helpful if the discloser identifies > here the sections of the Internet-Draft or RFC that are alleged to > be so covered. > > Both Sender ID: Authenticating E-mail > > and Purported Responsible Address in E-mail Messages > in combination. My question is, what portions of -core are covered? Harry's answer above seems to suggest that the entirety of -core and -pra are covered by Microsoft's IPR claim, am I right? Until this is explicitly spelled out, I think any discussion or action is moot. Ryan -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15:30:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05922 for ; Tue, 24 Aug 2004 15:30:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJ58KU047622; Tue, 24 Aug 2004 12:05:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OJ58vw047621; Tue, 24 Aug 2004 12:05:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJ5756047610 for ; Tue, 24 Aug 2004 12:05:07 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OJEJpt026771; Tue, 24 Aug 2004 15:14:19 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 15:03:05 -0400 Message-ID: <012301c48a0d$0b112f20$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Tuesday, August 24, 2004 2:17 PM > To: 'terry@ashtonwoodshomes.com'; Hallam-Baker, Phillip; > 'Chris Haynes'; > 'IETF MARID WG' > Subject: RE: DEPLOY: Legal liability for creating bounces from forged > messages > > > > > Sorry for the typo, that should read: > > Wrong. When you bounce it knowing the validity of the > > bounce recipient you have less liability then if you bounce > > it KNOWING that the bounce > > recipient is invalid. > > Where is the Mens Rea? KNOWING that: 1) the email is bad 2) the recipient of the bounce was not valid 3) sending the bounce message anyway > > The UK obscene publications act is a criminal offense, the issue is > whether the action is criminal, not whether there is a civil > liability. > > What the computer 'knows' is not relevant to Mens Rea, only > individuals > and corporations are subject to criminal law. Wrong. If what you say is true then I could create a computer program that creates/collects illegal material (credit cards, kiddie porn, whatever) and because it is the computer that is doing the work I am not criminally liable. > > The last time an animal was prosecuted under English common law was > when the citizens of Sunderland hung a monkey as a spy during the > Napoleonic wars. The only occasion I am aware of in which an inanimate > object was put on trial was before the Norman Conquest when a statue > of the Virgin Mary was convicted of murder and is believed to lie in a > grave that can be seen from my parent's house. Your being silly. If someone uses a knife or gun to commit the crime, the justice system prosecutes the person. The computer is just another such tool. > > > Sure you can find some really obscure offenses if you dredge > up obscure > parts of English law. That does not mean that there is the slightest > chance that a Home Secretary is ever going to allow a prosecution. > But we are not talking obscure. Porn and Phishing are serious criminal offences perpetrated every day on the internet using the SMTP protocol. And FYI the internet is not just for the UK. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15:43:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06747 for ; Tue, 24 Aug 2004 15:43: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 i7OJFWAi049133; Tue, 24 Aug 2004 12:15: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 i7OJFWvw049132; Tue, 24 Aug 2004 12:15:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJFVYZ049121 for ; Tue, 24 Aug 2004 12:15:31 -0700 (PDT) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id i7OJFRB6038277; Tue, 24 Aug 2004 19:15:27 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.12.9-20030917/8.12.9) with ESMTP id i7OJFQI9013970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 21:15:26 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i7OJFQ9i013969; Tue, 24 Aug 2004 21:15:26 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Tue, 24 Aug 2004 21:15:26 +0200 From: Koen Martens To: Andrew Newton Cc: Graham Murray , ietf-mxcomp@imc.org Subject: Re: DEPLOY - IPR on Sender-ID not sufficiently disclosed Message-ID: <20040824191526.GF13538@metro.cx> References: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> User-Agent: Mutt/1.4.1i X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 X-Helo-Milter: checked X-Helo-Reject: No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OJFWYZ049127 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, Aug 24, 2004 at 02:05:02PM -0400, Andrew Newton wrote: > On Aug 24, 2004, at 10:35 AM, Graham Murray wrote: > > >The licence terms have been disclosed, but > >insufficient (almost no) information has been given on what the > >claimed IPR covers. > > Please reread: > http://www.imc.org/ietf-mxcomp/mail-archive/msg03495.html Is it correct that the only phrases giving any hint of what is being patented are: Both Sender ID: Authenticating E-mail and Purported Responsible Address in E-mail Messages in combination. Furthermore, I see a couple of checkboxes repeating what is in the pdf document posted by Harry Katz and a lot of blank fields. Is it correct that this means that Sender-ID itself as well as PRA are patent pending by microsoft? Does this also mean that in effect, large parts of the spf syntax are now microsofts property or will be so in the near future? I don't see how the post you mentioned clarifies anything. It only adds to the concern. Koen Martens -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15:44: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 PAA06808 for ; Tue, 24 Aug 2004 15:44: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 i7OJK637049430; Tue, 24 Aug 2004 12:20: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 i7OJK6Jv049429; Tue, 24 Aug 2004 12:20:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJK5ov049419 for ; Tue, 24 Aug 2004 12:20:05 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7OJK1RG020282 for ; Tue, 24 Aug 2004 20:20:01 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7OJK1V3020281; Tue, 24 Aug 2004 20:20:01 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License References: From: Graham Murray Date: Tue, 24 Aug 2004 20:20:01 +0100 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 24 Aug 2004 11:21:58 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hallam-Baker, Phillip" writes: >> But it does not mean the copy is NOT encumbered, either. And >> you keep forgetting that the IPR is >> STILL UNSTATED!!! All we have been given is the >> (unacceptable) license, but not what the license >> covers! > > Again, read the license, it is very clear that it covers the > intersection between any patent claims owned by or granted to > Microsoft and those needed to implement Sender-ID. But the intersection between an unknown and anything else is also an unknown. As Microsoft have given very little information about "Patent claims owned by or granted to Microsft". This seems like a very open and vague. If the patent has already been applied for, then surely it does no harm to state exactly what will be covered by that patent if it is granted. Sender-ID is the amalgum of Microsoft's Caller-ID and SPF-classic. This apparent reluctance of Microsoft to specify exactly what is (or would be) covered by their potential IPR seems to me to just as ridiculous as has happened (probably more than once) when an author submitted a book to the UK security service for clearing under the Official Secrets Act only to be told "You must change parts of the book, but we cannot tell you which parts as that would let you know what you have correctly deduced." From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15:48: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 PAA06990 for ; Tue, 24 Aug 2004 15:48:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJLFLU049568; Tue, 24 Aug 2004 12:21: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 i7OJLFGZ049567; Tue, 24 Aug 2004 12:21:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJLEPK049558 for ; Tue, 24 Aug 2004 12:21:14 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i7OJLF3V002260 for ; Tue, 24 Aug 2004 12:21:15 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 6ABD884F867; Tue, 24 Aug 2004 12:21:15 -0700 (PDT) Date: Tue, 24 Aug 2004 12:21:15 -0700 From: "Mark C. Langston" To: IETF MARID List Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Message-ID: <20040824192115.GD41046@bitshift.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 11:55AM up 70 days, 20:01, 7 users, load averages: 0.25, 0.15, 0.06 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 11:34:48AM -0700, Harry Katz wrote: > Mark, if there's a specific part of the license you'd like clarified, > I'd encourage you to send mail to stdsreq@microsoft.com. Someone from > our legal department will answer your question. I appreciate the offer of assistance Harry, and probably will take advantage of it. However, I can't in good conscience base my decisions on the advice of your legal team, as it isn't a disinterested party. Since I can't afford to pay a lawyer to consult with me on the matter, I think the best approach will be to sit back and watch to see how things play out once others have deployed open-source projects supporting Sender-ID, and once the patent filings have become public knowledge. In particular, I'm concerned about the potential leverage agreeing to the license terms gives the IP holders against those who implement both Sender-ID and SPF simultaneously. It's not clear to me whether the IP holder would pursue as infringing those who implement SPF. I also concur with another poster's statement: having to submit a paper agreement to the IP holder is, in my opinion, burdensome. The very short version of all this is: if I feel I need to consult a lawyer before integrating this into my software, I'm just not going to implement it. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 15:56: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 PAA07361 for ; Tue, 24 Aug 2004 15:56: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 i7OJUWuc050401; Tue, 24 Aug 2004 12:30: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 i7OJUWe2050400; Tue, 24 Aug 2004 12:30:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJUVRU050394 for ; Tue, 24 Aug 2004 12:30:31 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OJdjpt028570; Tue, 24 Aug 2004 15:39:45 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Mark Shewmaker'" , "'IETF MARID List'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License Date: Tue, 24 Aug 2004 15:28:08 -0400 Message-ID: <013301c48a10$99270e80$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Tuesday, August 24, 2004 2:22 PM > To: 'terry@ashtonwoodshomes.com'; Hallam-Baker, Phillip; 'Mark > Shewmaker'; 'IETF MARID List' > Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License > > > > Valid point. But the question is, will it just be applied to > > the compiler or the compiled code. As > > stated elsewhere, the license is now published, the scope of > > the IPR is NOT. > > The scope is precisely defined in the license as the > intersection between > the patent claims and the necessary claims required to implement the > spec. Specifically: Both Sender ID: Authenticating E-mail and Purported Responsible Address in E-mail Messages in combination. i.e. THE WHOLE THING. In other words there is no line between what is, or is not covered by the IPR. Because certainly some of sender id CANNOT be covered by the IPR by IETF rules (if I understand them correctly) because at least some of the sender id concepts were invented on the mailing list. > > > > This is a very complex legal argument, calling it trivial shows a > > > distinct lack of comprehension. > > > > Your bullying tactics are still not worthy of your > > intelligence (or perhaps I misjudge that). > > What is 'bullying' about answering an argument with facts. > You asserted > that the argument was trivial. Statements like "distinct lack of comprehension" is bullying because it is habitually cruel or overbearing and its not a fact because it is neither known, nor demonstrated. > > > > The literal interpretation of my statement was, and still is, > > the "difference" that YOU stated is > > "trivial and irrelevant", not the legal arguments themselves. > > The difference between the patent and the realization of the patent > is the whole core of the legal arguments. And the lack of distinction is the problem. > > > But it does not mean the copy is NOT encumbered, either. And > > you keep forgetting that the IPR is > > STILL UNSTATED!!! All we have been given is the > > (unacceptable) license, but not what the license > > covers! > > Again, read the license, it is very clear that it covers the > intersection between any patent claims owned by or granted to > Microsoft and those needed to implement Sender-ID. > Again, the license is stated as "everything" despite at least some of the ideas in sender Id cannot be part of the IPR because: 1) The IPR occurred before sender id was formed (or has the IPR evolved to include new stuff) 2) The IETF policy on ideas originally submitted via IETF (do I need to cite this for you?) Despite it is stated, it is not "very clear" at all. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 16:00:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07656 for ; Tue, 24 Aug 2004 16:00:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJZJtF050700; Tue, 24 Aug 2004 12:35: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 i7OJZJuV050698; Tue, 24 Aug 2004 12:35:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJZJud050692 for ; Tue, 24 Aug 2004 12:35:19 -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; Tue, 24 Aug 2004 15:35:21 -0400 id 0015FA7D.412B9879.0000553C In-Reply-To: <20040824191526.GF13538@metro.cx> References: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> <20040824191526.GF13538@metro.cx> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: DEPLOY - IPR on Sender-ID not sufficiently disclosed Date: Tue, 24 Aug 2004 15:35:18 -0400 To: Koen Martens X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 3:15 PM, Koen Martens wrote: > Is it correct that this means that Sender-ID itself as well as PRA are > patent pending by microsoft? Please don't get hung up on the file names of the drafts. > Does this also mean that in effect, large parts of the spf syntax are > now microsofts property or will be so in the near future? Just how do you arrive at this conclusion? -andy From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 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 QAA07783 for ; Tue, 24 Aug 2004 16:02: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 i7OJdMcl051156; Tue, 24 Aug 2004 12: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 i7OJdMnO051155; Tue, 24 Aug 2004 12:39:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJdMKc051148 for ; Tue, 24 Aug 2004 12:39:22 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i7OJdO3V005127; Tue, 24 Aug 2004 12:39:24 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 2DDEA84F868; Tue, 24 Aug 2004 12:39:24 -0700 (PDT) Date: Tue, 24 Aug 2004 12:39:24 -0700 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Cc: spf-discuss@v2.listbox.com Subject: Re: DEPLOY - IPR on Sender-ID not sufficiently disclosed Message-ID: <20040824193924.GF41046@bitshift.org> References: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> <20040824191526.GF13538@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040824191526.GF13538@metro.cx> User-Agent: Mutt/1.4.1i X-Uptime: 12:34PM up 70 days, 20:41, 7 users, load averages: 0.21, 0.31, 0.16 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 09:15:26PM +0200, Koen Martens wrote: > > Does this also mean that in effect, large parts of the spf syntax are > now microsofts property or will be so in the near future? > That's my current worry, and now I'm actually considering having an IP lawyer friend of mine look over the language to see whether or not Microsoft would have a case if they came after me for implementing SPFv1 checks in my software. If that's true, it's a crying shame. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 16:04: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 QAA07911 for ; Tue, 24 Aug 2004 16:04: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 i7OJeGK6051231; Tue, 24 Aug 2004 12:40: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 i7OJeGeb051230; Tue, 24 Aug 2004 12:40:16 -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 i7OJeFWZ051220 for ; Tue, 24 Aug 2004 12:40:15 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 11399 invoked from network); 24 Aug 2004 19:42:04 -0000 Received: from unknown (HELO ?192.168.254.133?) (208.198.98.24) by ns1.hoster907.com with SMTP; 24 Aug 2004 19:42:04 -0000 In-Reply-To: References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D296A19-F605-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: Mark Lentczner From: Margaret Olson Subject: DEPLOY: DNS Record Types Date: Tue, 24 Aug 2004 15:40:17 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 1:25 AM, Mark Lentczner wrote: > > > On Aug 23, 2004, at 5:09 PM, Jim Lyon wrote: > >> I believe that the latest Protocol draft >> (draft-ietf-marid-protocol-03) >> contains changes that don't correctly reflect the consensus of the >> group >> concerning DNS record types. > > The changes you cited were all made in response to review by the > people of DNS-EXT. In particular, Olafur Gudmundsson, co-chair of > DNS-EXT provided much of the wording you see verbatim. He and I > discussed the changes and in particular the very points you bring up. > He said he'd like to see this version of the wording go to last call, > and that he'd be willing to be involved in discussions. > My comment about the current wording is that either senders or receivers who do not implement the "MAY" clauses are acting against their own best interests. This is misleading at best. As a sender, I am going to publish all record types that receivers might look up as soon as I can. As a receiver who is interested in discarding as much forgery as possible as quickly as possible, I'm going to look up whatever records I can look up as quickly as I can. As a practical matter, I'll be publishing and checking TXT records very shortly, and the SPF2 record type at some point in the future. As the spec is written, a new reader has to study carefully and work this out for themselves. This is not helpful to the email community and it will slow down adoption. I am strongly in favor of Sender ID, and would like to see it deployed as quickly as possible. Margaret. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 16:11: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 QAA08454 for ; Tue, 24 Aug 2004 16:11: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 i7OJkVfX051671; Tue, 24 Aug 2004 12:46:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OJkVMg051670; Tue, 24 Aug 2004 12:46:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJkUGH051663 for ; Tue, 24 Aug 2004 12:46:30 -0700 (PDT) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id i7OJkRvf039389; Tue, 24 Aug 2004 19:46:27 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.12.9-20030917/8.12.9) with ESMTP id i7OJkRI9014180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 21:46:27 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i7OJkQZe014179; Tue, 24 Aug 2004 21:46:26 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Tue, 24 Aug 2004 21:46:26 +0200 From: Koen Martens To: Andrew Newton Cc: IETF MARID WG Subject: Re: DEPLOY - IPR on Sender-ID not sufficiently disclosed Message-ID: <20040824194626.GB14099@metro.cx> References: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> <20040824191526.GF13538@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 X-Helo-Milter: checked X-Helo-Reject: No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OJkUGH051665 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, Aug 24, 2004 at 03:35:18PM -0400, Andrew Newton wrote: > On Aug 24, 2004, at 3:15 PM, Koen Martens wrote: > >Is it correct that this means that Sender-ID itself as well as PRA are > >patent pending by microsoft? > > Please don't get hung up on the file names of the drafts. What else is there? I can reread the post again and again, but frankly i know of more useful things to do with my time (developing software is one, spending time with my loved ones is another). I'll repeat: Is microsoft patenting Sender-ID and PRA ? If no: what is being patented? If yes: who will bother with Sender-ID and PRA ? > >Does this also mean that in effect, large parts of the spf syntax are > >now microsofts property or will be so in the near future? > > Just how do you arrive at this conclusion? It's mere speculation. Give us some facts, and the speculation will stop. Sender-ID uses SPF syntax, Microsoft claims to have patents pending on Sender-ID and PRA, therefore it is not impossible that microsoft is trying to patent SPF syntax. Is that so illogical? Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 16:25: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 QAA09084 for ; Tue, 24 Aug 2004 16:25: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 i7OJw3Ad052266; Tue, 24 Aug 2004 12:58: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 i7OJw3pC052265; Tue, 24 Aug 2004 12:58:03 -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 i7OJw00i052250 for ; Tue, 24 Aug 2004 12:58:03 -0700 (PDT) (envelope-from aland@nitros9.org) Received: by mail.nitros9.org (Postfix, from userid 1000) id 1CBDB17111; Tue, 24 Aug 2004 16:06:37 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: DEPLOY: spam problem solved, addressed, or ??? In-Reply-To: Your message of "Sat, 21 Aug 2004 19:50:09 EDT." Message-Id: <20040824200637.1CBDB17111@mail.nitros9.org> Date: Tue, 24 Aug 2004 16:06:37 -0400 (EDT) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: ... First, I'd like to thank Dean for forwarding a private message to a public list. > Someone was saying on-list that the objective of SPF isn't to reduce spam. > I was just discussing that subject off-list. If MTA authorization doesn't > reduce spam, there is little purpose to the MARID WG, as the MARID charter > indicates. In your opinion. Tools may be intended for one purpose, but still be effective in others. Ask anyone who's used a dime to turn a screw. > FYI: from the MARID charter > http://www.ietf.org/html.charters/marid-charter.html It's nice to quote things out of context. The sentence before the one you quoted qualifies the remarks in your quote: "The primary current use case for this facility is to allow recipient MTAs to confirm that peer MTAs' actions are authorized by specific domains or networks. " For me, the charter is clear: MTA authorization is the goal, any anti-spam benefit may be a known side-effect. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 16: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 QAA09690 for ; Tue, 24 Aug 2004 16:35: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 i7OK8CwK052891; Tue, 24 Aug 2004 13:08:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OK8CGL052890; Tue, 24 Aug 2004 13:08:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OK89xG052884 for ; Tue, 24 Aug 2004 13:08:11 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OKHJpt000931; Tue, 24 Aug 2004 16:17:19 -0400 From: To: "'Jim Lyon'" , "'Hallam-Baker, Phillip'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 16:06:31 -0400 Message-ID: <014e01c48a15$d8fca9c0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_014F_01C489F4.51EB09C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-MS-TNEF-Correlator: 00000000C8689303D474D71196E900201855F5B3E486EE02 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_014F_01C489F4.51EB09C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Well said, well put, I agree to get off UK law and back to the point. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: Jim Lyon [mailto:jimlyon@exchange.microsoft.com] > Sent: Tuesday, August 24, 2004 2:54 PM > To: Hallam-Baker, Phillip; terry@ashtonwoodshomes.com; Chris Haynes; > IETF MARID WG > Subject: RE: DEPLOY: Legal liability for creating bounces from forged > messages > > > This thread has devolved into a fascinating discussion of > arcane points > of British law, but it misses the fundamental point: > > A reasonable use of SenderID is to use it at SMTP time, and > to refuse to > accept forged mail. If you refuse to accept it (by giving an error at > end of DATA), you won't generate a bounce. The MTA that was > sending the > mail might or might not generate a bounce, but that's his problem, not > yours. > > In fact, most of the forged mail is sent by specialized spam > engines or > virus propagation engines. These engines won't generate bounces, > they'll just give up and go on to the next victim. > > So, deploying SenderID should result in fewer bounces, not more. > > > -- Jim Lyon > > > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Hallam-Baker, > Phillip > Sent: Tuesday, August 24, 2004 11:17 AM > To: 'terry@ashtonwoodshomes.com'; Hallam-Baker, Phillip; > 'Chris Haynes'; > 'IETF MARID WG' > Subject: RE: DEPLOY: Legal liability for creating bounces from forged > messages > > > > > Sorry for the typo, that should read: > > Wrong. When you bounce it knowing the validity of the > > bounce recipient you have less liability then if you bounce > > it KNOWING that the bounce > > recipient is invalid. > > Where is the Mens Rea? > > The UK obscene publications act is a criminal offense, the issue is > whether the action is criminal, not whether there is a civil > liability. > > What the computer 'knows' is not relevant to Mens Rea, only > individuals > and corporations are subject to criminal law. > > The last time an animal was prosecuted under English common law was > when the citizens of Sunderland hung a monkey as a spy during the > Napoleonic wars. The only occasion I am aware of in which an inanimate > object was put on trial was before the Norman Conquest when a statue > of the Virgin Mary was convicted of murder and is believed to lie in a > grave that can be seen from my parent's house. > > > Sure you can find some really obscure offenses if you dredge > up obscure > parts of English law. That does not mean that there is the slightest > chance that a Home Secretary is ever going to allow a prosecution. > > ------=_NextPart_000_014F_01C489F4.51EB09C0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ih8UAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHCAAYABAABgAAAAIAEwEB A5AGAMwMAAAqAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA AAAAAwA2AAAAAAAeAHAAAQAAAEIAAABERVBMT1k6IExlZ2FsIGxpYWJpbGl0eSBmb3IgY3JlYXRp bmcgYm91bmNlcyBmcm9tIGZvcmdlZCBtZXNzYWdlcwAAAAIBcQABAAAAFgAAAAHEihXY00pHbLGA DUpmtGzEe3Fy2qEAAAIBHQwBAAAAHgAAAFNNVFA6VEVSUllAR1JFQVRHVUxGSE9NRVMuQ09NAAAA CwABDgAAAABAAAYOAMRaxhWKxAECAQoOAQAAABgAAAAAAAAAyGiTA9R01xGW6QAgGFX1s0KFAAAD ABQOAQAAAAsAHw4BAAAAAwAGEKqgw4EDAAcQYQgAAB4ACBABAAAAZQAAAFdFTExTQUlELFdFTExQ VVQsSUFHUkVFVE9HRVRPRkZVS0xBV0FOREJBQ0tUT1RIRVBPSU5UVEVSUllGSUVMREVSTUFOQUdF UlNPRlRXQVJFREVWRUxPUE1FTlRBTkRERVBMT1kAAAAAAgEJEAEAAADhBwAA3QcAAKkNAABMWkZ1 TscZFwMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwEC AGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQswsJAWQzNhZQC6dj ATBQIFdlbAMgcwtwZIgsIHcdQnB1dB3ACEkgYQnCIHRvIBJnFCAgbwEgIFVLjiALYAfgAHBkIGIA 0JJrHvJ0aB7gcG8LgLh0LiAK4wqECoBUBJDQcnkgRgiQbASBIaQuTQBwHqASgVMfcHR3IwrAHuBE ZXYdQG9w3weAAjAgEySgC1BvBsAlIRUhpEcYIGEFQEd1bC0fkEgDcAeRLxDAc2jzHwADoFdvBHAE ICdTIaRbDrAigUAJwSbQZycRaBUnYi4FoG0hlUZheAA6ICg0MTYpIII0K6AtOTA4NSGqUSGkPiAt LbJPBRBn/wuAB0AF0AeQHYAfMC2zLTYWRgNhK3BKB3AgTHmdKBFbAMADEB8AOmoHcFpsMIFADsAT 0W4fMC62bQ3gA2BzJCEqkl0tNhcGYAIwK3BUClBzZGFSeR3AQXUqAHMFQDImNB3AAdAwNDUAOjXp NYBQTS02VDEgJ0AHQMELYG0tQmFrBJAdwNRQaAMQbAUgOx7wKWM6YSfjdyhSKkc4IENodwUQKIE0 YG4HkBkwLUVJCEVURgXQQVJJRMUdIEczN3ViagWQM+EEUkUrcERFUExP4lkrcExlZy5hN/ABoPkD EGl0IqACEAXABQAmwc0LgGcgUAhgbmMHkQNS/z7iHzALMS1UB4EuwijlLZD9Qf5UN8AEICDgJrEg QBPg+wQgAQB2BvAkwCBAIUEfELZhPuA4oGMuQT9zZAQAfmM00ACQKBEfcEJnCsBj7wBwIQVB50bh QgUQP3An4Psf0h3AYh5ARPAFQDJQBBD7B5Eg4mY/4DRQJRIuYSEj8jpB/kEgJrEyoCOwAmD/HuA0 0B7gRuEzsQSBO9FDkg8fEE3ySiEm0VNNVFD/HvAHcR3AICItNh8BGCBLAPdOAR8ARxdjQAAFMUCU QWDbMOEhcUkfkDCAdVGIUpbZSiEoYiKgLjB2P4IDkT8icQWxJtAtNk5xRtJEQThUQSkdwFQiOQBu J/cFQB8wOpByJtAe4EVQP8T/IXFDcB7gUABNICDgJtEkUP8EIS1FFBAgMD+CIOFA9zDhPUpBZyfw H2AFwF1Ubm9vWO9AAEnEWsInBCBDgnD7A2BNsW0dwF5BLTZUIRQA+i5B/kkDoEVwPPAdwARg/zTh RuFKw1MoTuJb0QVAVbHMc3AFkAcxaXpE0WYA/zcQQmcJ8C4xB5EFsC02VgD+cjTQYJIKsD4QP3Ao EWeV31oUTgFnllitP8UsUOcg8HR5Jx1RajTSVeFN0XD9IBNnHxAoESC1OpAO0VYA/zzwB3BiPyQQ HcABACXCP4LfTmc5QScQIEAYIHMnEEoB/2NRB9ASgWxGXjMEYBggIXB/Qf8tRzAndX8tTy5fL2tv mndZIS0IkAAwLW0x0JkDcHBAU4MHcGMuQKGPeKYwxnuvfLtdIE8DoOxCZRPgJyFPJzE26nimDze1 Mz80TzVTMTE6Mb43EMA2C1jQOF8qVic4IPc23zfkeKYnOgqIcIoXO1v+JzwvPT8+Tz9fQG9Bf5Lf /3jEcUIigo/CIOKPkCEgHcDfWsNy10QATBd5AFcDYDIQfSFxVyDwA6BUIpCUShI86E5PVHkAa15A A/BcJP9ooGZRRjCPkWQllEiY5Rgg/UWgcAiQJTFUIhPgbjFNwP8EEY8oIOEDoAaQmJqUSEohwkuZ kFdJTkdatCDi/5+fnLg6MQuAmqNwX5hRJHGvQ5NaYQnwBCBSJsA/Qn//IPEfsWDABPBZER4hAmAN 4P9pcwQgY4FO4kVQBQEyUHnC/x9xpiFQcSDiBAEKUE7heKb+dyDwIOGVZGOBRqI6Man2/3S0rFml dKnRVfEDIXi1jye/pD+YUKF1f1IeQBKBJ5ni/4tQTuJeQhggTcCaoCUxHwH/phYdwAIgMXCTtwuA RjBWAPxkdQdAkrcgIgWhISBZQf+pFCRxc2CNkx7yqfcf4XVf/1ozC2A04VBCVkIAcAdwedH/WxJg oRQQRmAOsCBASxESgf5FMhA38ElhKqEEYAOgH+L/WxGr2W8RsqJJMWaABjFOMne+AwtgIDFokLBW MWPBbv83YCKgREFFUGYAIqC24AUQ85o1eKZOYSEgTcACIA3g71sBYhFaM7Wzb1KwhzBGov8egSrA H/AkYkbhc7GsUA3g/0lwA5F5sbyyDrBIZ7kkvRPvSfFvAgciWwNiARB1ISDTzk4FsAOCCFBucYQB rnN3vIEdcAGQdApQSGkg4lb/aMB5oQXQCsAioFsSBaCj0PdwAUTRRuFtCHC+IiAiOjF/y4A38CSx IEAfAdHBc6Jh/3imCcCdolrDR7HLcVvBmHH9kRNtIqAKsSUhYDIIYBQQ37E/jPgkcVQi1BJmtoEd cP8nYU0yHVCbEagh19KqhaOh/VQEZBghHzDWt25h2aV4pn8KsUhARtK+ZrpDQ3Am0WR+bweRdNMm wMByoXSleHP/N/BdcczxeKYx4pkhWsNFUP8nUgZRkAEBkCKROjEksQXA/27QXBNFMR1QfoBFQb1W RqEL1j8hpH3ngAAAAAMAEBAAAAAAAwAREAMAAAAeAEIQAQAAAFEAAAA8ODFBQzA4NTA0NEQwNEI0 MjlGNUZCODgzRDk0RkExQUY4ODk4MkZAZGYtZmlkby1tc2cuZXhjaGFuZ2UuY29ycC5taWNyb3Nv ZnQuY29tPgAAAAADAACACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAKYAIIAYAAAAAAMAA AAAAAABGAAAAAFKFAADwEwAAHgAqgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41 AB4AK4AIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeACyACCAGAAAAAADAAAAA AAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAtgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAAB AAAAAAAAAAsALoAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAvgAggBgAAAAAAwAAAAAAA AEYAAAAAAYUAAAAAAAALADCACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMYAIIAYAAAAA AMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALADOA CCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAsANIALIAYAAAAAAMAAAAAAAABGAAAAAACIAAAA AAAACwA1gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAAAAACAfgPAQAAABAAAADIaJMD1HTXEZbp ACAYVfWzAgH6DwEAAAAQAAAAyGiTA9R01xGW6QAgGFX1swIB+w8BAAAATQAAAAAAAAA4obsQBeUQ GqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcbWFpbFxvdXRsb29r bmV3Mi5wc3QAAAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwQzg2ODkzMDNE NDc0RDcxMTk2RTkwMDIwMTg1NUY1QjNFNDg2RUUwMgAAAAAzrw== ------=_NextPart_000_014F_01C489F4.51EB09C0-- From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 16:50:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10569 for ; Tue, 24 Aug 2004 16:50: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 i7OKKkuD053440; Tue, 24 Aug 2004 13:20:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OKKkKS053439; Tue, 24 Aug 2004 13:20:46 -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 i7OKKiJf053427 for ; Tue, 24 Aug 2004 13:20:46 -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 BF8C140D8 for ; Tue, 24 Aug 2004 13:20:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040824134147.GA68862@kiwi.generic-nic.net> References: <20040824134147.GA68862@kiwi.generic-nic.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D65A32E-F60B-11D8-A96D-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: DOC-BUG: typo in -protocol Date: Tue, 24 Aug 2004 13:21:00 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 6:41 AM, Stephane Bortzmeyer wrote: > I believe that the last paragraph in "4. Mechanism definitions" should > start with "Several mechanisms rely on information fetched from DNS" > (without the p in "rely"). Fixed. - Mark From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 16:51: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 QAA10664 for ; Tue, 24 Aug 2004 16:51:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKOQgN053732; Tue, 24 Aug 2004 13:24:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OKOQFv053731; Tue, 24 Aug 2004 13:24:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKOPXv053721 for ; Tue, 24 Aug 2004 13:24:25 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 22B1D40D8 for ; Tue, 24 Aug 2004 13:24:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040824135405.GA68895@kiwi.generic-nic.net> References: <20040824135405.GA68895@kiwi.generic-nic.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: DOC-BUG: two IPv6 problems in -protocol Date: Tue, 24 Aug 2004 13:24:41 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 6:54 AM, Stephane Bortzmeyer wrote: > 1) In "4.4. mx", it says "Then perform an A lookup on each MX name > returned". It should be "Then perform an address lookup on each MX > name returned" to be consistent with "4. Mechanism Definitions" which > talks about address (v4 or v6) lookups. Fixed. > 2) In "4.3. a", I suggest to add a note: > > Note: as explained before, "a" stands for "address" (IPv4 or IPv6) > and not for the DNS A record. Fixed by rewording the text to refer to doing an "address lookup". - Mark From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 16: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 QAA10818 for ; Tue, 24 Aug 2004 16:52:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKMjXl053651; Tue, 24 Aug 2004 13:22:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OKMjv2053650; Tue, 24 Aug 2004 13:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKMiIQ053643 for ; Tue, 24 Aug 2004 13:22:44 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OKVl4t001985; Tue, 24 Aug 2004 16:31:47 -0400 From: To: "'Harry Katz'" , "'Mark C. Langston'" , "'IETF MARID List'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Tue, 24 Aug 2004 16:20:58 -0400 Message-ID: <016601c48a17$de735dc0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0167_01C489F6.5761BDC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-MS-TNEF-Correlator: 00000000C8689303D474D71196E900201855F5B36489EE02 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_0167_01C489F6.5761BDC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Right, and then get the clarification put into the license itself so it does not need the clarification. Or will that take several weeks to do also? Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Harry Katz > Sent: Tuesday, August 24, 2004 2:35 PM > To: Mark C. Langston; IETF MARID List > Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent > License FAQ > > > > Mark, if there's a specific part of the license you'd like clarified, > I'd encourage you to send mail to stdsreq@microsoft.com. Someone from > our legal department will answer your question. > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Mark > C. Langston > > Sent: Tuesday, August 24, 2004 10:26 AM > > To: 'IETF MARID List' > > Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent > > License FAQ > > > > > > > > I'd have to agree with Koen. I'm adding SPFv1 checks to > > GOSSiP. I'd like to support the eventual product of MARID, > > but given the current license confusion, I can't, nor am I > > inclined to. This isn't a "I won't support anything from > > Microsoft" position; this is a "It's not entirely clear to me > > what rights I retain and which I surrender by including a > > Sender-ID implementation in my code." position. > > > > -- > > Mark C. Langston GOSSiP Project Sr. > Unix SysAdmin > > mark@bitshift.org http://sufficiently-advanced.net > mark@seti.org > > Systems & Network Admin Distributed SETI > Institute > > http://bitshift.org E-mail Reputation http://www.seti.org > > ------=_NextPart_000_0167_01C489F6.5761BDC0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjsUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHCAAYABAAFAAAAAIAIQEB A5AGAFQKAAAqAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA AAAAAwA2AAAAAAAeAHAAAQAAADwAAABERVBMT1k6IE1pY3Jvc29mdCBSb3lhbHR5IEZyZWUgU2Vu ZGVyIElEIFBhdGVudCBMaWNlbnNlIEZBUQACAXEAAQAAABYAAAABxIoX3aDm+U4y+HBBpJrYs694 XWv1AAACAR0MAQAAAB4AAABTTVRQOlRFUlJZQEdSRUFUR1VMRkhPTUVTLkNPTQAAAAsAAQ4AAAAA QAAGDgCYCLsXisQBAgEKDgEAAAAYAAAAAAAAAMhokwPUdNcRlukAIBhV9bNChQAAAwAUDgEAAAAL AB8OAQAAAAMABhAOp0odAwAHEFwFAAAeAAgQAQAAAGUAAABSSUdIVCxBTkRUSEVOR0VUVEhFQ0xB UklGSUNBVElPTlBVVElOVE9USEVMSUNFTlNFSVRTRUxGU09JVERPRVNOT1RORUVEVEhFQ0xBUklG SUNBVElPTk9SV0lMTFRIQVRUQUtFAAAAAAIBCRABAAAAcQUAAG0FAABgCQAATFpGdfUNYYYDAAoA cmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNl dDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAULMLCQFkMzYWUAunYwEwgQfwaWdo dCwgAHCQZCB0aAnwIGcUIDkd0iBjC2AGgQ3gYXRiaQIgIHB1BUALgHR6bx5jbA3gCfAUEB/AdGEU EGxmIHMgACDgIKRkbweRbm8FQG4J4MMdwx6sLiAgTwXAA/CebAMgHeAfMB3QYWsekL0UEHYEkAdA I/AJ4GsEINcf8SGwHZBsIVA/CqIKhIUKgFQEkHJ5IEYIkNZsBIEmhE0AcGEeMAXAtFNvAYB3CsAe kEQlAX0XsHAHgAIwHZMpgAtQbzcGwCoBJoRHGCAkcUd1rSEhSANwB5EvEMBzHWD5H2FXbwRwBCAs MyaEDrCtJ2FACcEfMGcr8WgsQhouBaBtCuMKgEZheAA6ICg0MTYpIII0MIAtOTA4NSaK8SaEPiAt MpIj0B1AC4B1JUFNB5BzKKEykzIWRpMDYTBQb3ciQHItCJCRADAtbXgvgXBAAMClAxAuB3BjLgWw ZzIWNls2Mh/wOjUfNitdT9kDoEJlE+AhIU8sEQrA9SdxSx8wejIWBmACMDBQQlQKUHNkYXkdgEHK dS7gcwVAMjQdgAHQBDA0PSA6MzUgULpNMhZUN9AF0ArAaxIgNSOgTABwZz0AAiA7IBBJRVRGBdBB UkkeRD9gBAArFTuxdWJqEwWQPAFSRTBQREVQ+ExPWT7RDeADYCFQAYD1B/F5B0B0J4EJ0TvCBIH7 QABAoFAfMCoCMhZAwCCE+EZBUTIWRo8yJT7yHYBXBpAd0hggJwQgYSFAcH8FkB7yH4AKwAVAKQAg G3l9CGAnHcAgYCTBHrUJgCz9MhZJS7EJ8AWgCHAooUty3yXCFBAdsTYyTmN0LVAYIP5xNiBC5i9y I6Eo8AeAAiCfHpADUjIWCGEgUGVnJUH/AQBKQinzJAMAcSVwBcBLgf0FwHE8QSNlRw4yfzOPViL/ NL84rzbQVbk3f1mfOZMjwH85+j7zMhY/SVXIO9887DFwMDoyNhDAPic+lCftQB0nYGlBl2VCP0NP RF//VddF31Yiay9sO01SE+AlEP8lwiigaIID8B3gOwAhwCOSY01QL6BhZGQLgFrQU7BQRnYxHqAd 8GMlpIFVyEdPU1NpUG9T40vFTnJ1cHAXwSKDJQHVAjB1JUFwA2BkGtBKc/dAYx2AVchiH6FW4HPx IoSfCHAYICoRIGYFoG5mPPDbH1EdgEkeoABwJx1xIgD9BcBhL6B4wFXIC4AesAuAZSJibyOhVGgE AB/Ac+t5AUmBInjAdwIge+FzJn0AcHkd4G/yA1JVuWdXIv8fgGeQIOAfUT/wfXF7knwD12VAIeQq AWkYIGwngB6w3yugBcAf8QeAVbl3JGJWwf8dYAQgeMAYIAGQC4Adk4NAvw3gbvB4wHMgdzJo8mIn gL16gnVv40mQYGsEgS1AkbsHcAtQZSnyHzSEYW2BwfUEcS5/WC5sb1Yzfho/DX8jsI2IcdQ+AANg QbKNiFNWciOgMhZVAwB4FFFzPEFkT/BgWQDAPxBAYj8g4XtwUGFasiOwHWB0cPg6Ly9zIAEgDeAI kAIwNYGwLW/AdgBwIIBkLt8iQI8TMhaR8xQRaTa6YOHrkOAOsG0EICYHsSkgBbD3PyCRA42EREDR BRB2MSJh7ZnsU0AgechJAIAfQHQg3w6wVciTNZJNjYJFXLBPAr9mkB+RHzSNhCaEkzV3oMAWLpZO oYx9ovAAAAADABAQAAAAAAMAERACAAAAHgBCEAEAAABSAAAAPEQ5NjUyMkExMzhGNEQ0NDc5Q0I1 RjdGNTgzQjk4RjA1N0I0Nzk1QGRmLWNoZXd5LW1zZy5leGNoYW5nZS5jb3JwLm1pY3Jvc29mdC5j b20+AAAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADACmACCAGAAAAAADAAAAAAAAA RgAAAABShQAA8BMAAB4AKoAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguNQAeACuA CCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAsgAggBgAAAAAAwAAAAAAAAEYA AAAAN4UAAAEAAAABAAAAAAAAAB4ALYAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAA AAALAC6ACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAL4AIIAYAAAAAAMAAAAAAAABGAAAA AAGFAAAAAAAACwAwgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADGACCAGAAAAAADAAAAA AAAARgAAAAARhQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAACwAzgAggBgAA AAAAwAAAAAAAAEYAAAAABoUAAAAAAAALADSACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAAAsA NYALIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAAAgH4DwEAAAAQAAAAyGiTA9R01xGW6QAgGFX1 swIB+g8BAAAAEAAAAMhokwPUdNcRlukAIBhV9bMCAfsPAQAAAE0AAAAAAAAAOKG7EAXlEBqhuwgA KypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XG1haWxcb3V0bG9va25ldzIu cHN0AAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMEM4Njg5MzAzRDQ3NEQ3 MTE5NkU5MDAyMDE4NTVGNUIzNjQ4OUVFMDIAAAAAEa0= ------=_NextPart_000_0167_01C489F6.5761BDC0-- From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:08: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 RAA11675 for ; Tue, 24 Aug 2004 17:08: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 i7OKl8W3055138; Tue, 24 Aug 2004 13:47: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 i7OKl8Aj055137; Tue, 24 Aug 2004 13:47:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.well.com (smtp.well.com [206.14.209.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKl8LQ055111 for ; Tue, 24 Aug 2004 13:47:08 -0700 (PDT) (envelope-from cpm@well.com) X-WELL-Auth: Yes Received: from [192.168.0.9] (orthanc.avwashington.com [199.227.4.34]) by smtp.well.com (8.13.0/8.13.0) with ESMTP id i7OKkwaj020476 for ; Tue, 24 Aug 2004 13:47:00 -0700 (PDT) Message-ID: <412BA903.5080207@well.com> Date: Tue, 24 Aug 2004 16:45:55 -0400 From: Chip Mefford User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'IETF MARID List'" Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License References: In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on smtp X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallam-Baker, Phillip wrote: | SNIP | | Again, read the license, it is very clear that it covers the | intersection between any patent claims owned by or granted to | Microsoft and those needed to implement Sender-ID. Well, I have read it, and it is not clear to me at all. There's that stickly little piece of language in there; "Patent claims owned by or granted to Microsft", that are not enumerated. All the standard IANAL caveats, but I do know how to read, and I know something about sentence structure. There are vague areas in this license. Further, there are assurances about what actions will be, or not be taken that are not spelled out exactly. In short, it's a contract I wouldn't sign without knowing exactly what kind of entity I was dealing with. In this particular case, I say let the legal history be a guide. Now that patents seem to almost never expire, and corporations and are at least in theory immortal, a license such as this could morph into almost anything, give the time, money and legal talent. No thanks. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBK6kBa44x14FCa6ARAnYyAJ9SgPTSanApCTVIHBTRMw2+7EzGVQCeOTM5 yo1Xd/xGWeENG+aXauO0Hac= =tYDq -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:08:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11736 for ; Tue, 24 Aug 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 i7OKmqol055249; Tue, 24 Aug 2004 13:48: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 i7OKmqCh055248; Tue, 24 Aug 2004 13:48:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from knecht.Neophilic.COM (dsl081-247-036.sfo1.dsl.speakeasy.net [64.81.247.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKmqoJ055235 for ; Tue, 24 Aug 2004 13:48:52 -0700 (PDT) (envelope-from eric@sendmail.org) Received: from [10.210.202.73] (natted.sendmail.com [63.211.143.38]) by knecht.Neophilic.COM (8.13.1/8.13.1) with ESMTP id i7OKmhkv045730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Aug 2004 13:48:44 -0700 (PDT) Date: Tue, 24 Aug 2004 13:48:43 -0700 From: Eric Allman To: Stephane Bortzmeyer , Harry Katz , stdsreq@microsoft.com cc: IETF MARID List Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Message-ID: In-Reply-To: <20040824071602.GF13303@nic.fr> References: <20040824071602.GF13303@nic.fr> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on knecht.sendmail.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit | Taking this into account and reading Eric Allman analysis | (http://www.imc.org/ietf-mxcomp/mail-archive/msg03500.html), it | seems the most common free software licence, the GPL, is | incompatible with Microsoft licence on SenderID. I didn't say that. I said that _some_ people may believe this, but there is also some significant reason to believe that they are incorrect, including statements from both Eben Moglen and Lawrence Rosen, both of whom are lawyers. As near as I can tell, the question of GPL compatibility is quite ambiguous at this time. eric From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:10: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 RAA11808 for ; Tue, 24 Aug 2004 17:10:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKotPO055463; Tue, 24 Aug 2004 13:50: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 i7OKotYR055461; Tue, 24 Aug 2004 13:50:55 -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 i7OKotZ0055449 for ; Tue, 24 Aug 2004 13:50:55 -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 CE4CF40E8 for ; Tue, 24 Aug 2004 13:50:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <6D296A19-F605-11D8-BD7E-000A95BC6A7E@margaretolson.com> References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> <6D296A19-F605-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <54A0E1AE-F60F-11D8-A96D-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: DEPLOY: DNS Record Types Date: Tue, 24 Aug 2004 13:51:11 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 12:40 PM, Margaret Olson wrote: > As the spec is written, a new reader has to study carefully and work > this out for themselves. This is not helpful to the email community > and it will slow down adoption. [ This is a little off-topic, but... ] I'm not so concerned that a reader has to study the document to work out what a best practice should be. The eventual specification document needs to clearly and concisely state the technical parameters. It does not serve as a How-To document. I should hope that the vast majority of the e-mail community will never read this document, and will learn what to do from helpful web sites and record generating wizards. I already fear that the protocol document has far too much exegesis in it. If you have a tighter, clearer and more concise way of saying what is allowed and what must be done, then I'm all ears. I'm going to resist adding paragraphs of explanation, best practices, expository examples and helpful hints. - Mark From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:14: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 QAA09101 for ; Tue, 24 Aug 2004 16:25:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJxxtb052440; Tue, 24 Aug 2004 12:59:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OJxxRv052439; Tue, 24 Aug 2004 12:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJxw3S052433 for ; Tue, 24 Aug 2004 12:59:58 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7OK9Bpt031859; Tue, 24 Aug 2004 16:09:11 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 15:58:15 -0400 Message-ID: <014b01c48a14$b4f74720$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Tuesday, August 24, 2004 2:46 PM > To: 'terry@ashtonwoodshomes.com'; Hallam-Baker, Phillip; > 'Chris Haynes'; > 'IETF MARID WG' > Subject: RE: DEPLOY: Legal liability for creating bounces from forged > messages > > > > > In this case it would suffice to notify the purported sender that > > > a message from them failed validation. It is not necessary to > > > quote any of the text of the message. > > > > NOT if you are among those who believe the email is reliable > > transport. Once your MTA has accepted > > an email you are obliged to either: > > 1) deliver it > > 2) return it as undeliverable > > If your understanding of English law is that you would be performing > a criminal act by doing so, then your duty to the Queen would surely > claim a higher priority than the mere opinions of this group? I fail to see the relevance, but anyway, I am only loosely a British subject, I am Canadian. And whether or not I am/am not criminally liable, does not protect me from civil liability. And although much civil suits are done frivolously, suits with less subtance then what we described have been won (bouncing when email known bad and bounce recipient known invalid). I need to protect myself from criminal AND civil liability in ALL countries where I do business. > > > > One way that the spec could be improved would be to state that the > > > sender SHOULD notify the purported sender without mandating the > > > use of a particular mechanism, specify bounces as the fallback > > > mechanism. > > > > Fine. But if you believe that SMTP is used for reliable > > communication, you have to do *something* > > with it. > > Like fix the mess that is the SMTP spec. > Correct. > > What do you propose instead? Silently delete it? > > Lets see, more than 90% sure its garbage, delete it unless the > sender suggests some other disposition. > And that's what I do not consider to be acceptable behaviour. Nor should anyone. If we did, we could just set our spamassassin scores low and let spamassassin kill anything that looks even remotely bad. That's just an example, so before you say "MARID is not about killing spam..." but the charter is about mail authentication which is supposed to be a stepping stone toward fighting phishing, spam etc. > > Pass it off to the original recipients > > postmaster? Neither is viable or acceptable in the context > > of RELIABLE message transfer. > > SMTP is not a reliable mail transfer protocol, neither as > originally described or as implemented. WRONG on both counts. Try to stick to the facts please, I quote from RFC 821: "The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently." http://www.faqs.org/rfcs/rfc821.html And most MTA's (all that I have used) treat SMTP as a reliable messaging system, either send the message, or indicate that it was not sent. > > The first step towards making SMTP reliable is to put authentication > in place. > > > > The "culpable mental state" of Mens Rea is not applicable here: > > 1) We are bouncing BECAUSE we know the email to be bad with > > reasonable high probability, > > We have no specific knowledge that the email is pornographic. > > Mens Rea is not applicable to inanimate objects such as computers > and statues and has not been since 950 or thereabouts. > No, but it IS applicable to those who use tools/weapons to perform deeds to their design. I am going to quite, because the argument is moot, suppose in some countries there is no criminal liability. In a significant portion of the internet (United States comes to mind) there could be criminal and/or civil liability implications by implementing sender id. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:15:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12281 for ; Tue, 24 Aug 2004 17:15: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 i7OKtUke056210; Tue, 24 Aug 2004 13:55: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 i7OKtU7J056209; Tue, 24 Aug 2004 13:55:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKtUFm056197 for ; Tue, 24 Aug 2004 13:55:30 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.151] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id E9A1940E1 for ; Tue, 24 Aug 2004 13:55:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040824194626.GB14099@metro.cx> References: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> <20040824191526.GF13538@metro.cx> <20040824194626.GB14099@metro.cx> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: DEPLOY - IPR on Sender-ID not sufficiently disclosed Date: Tue, 24 Aug 2004 13:55:46 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 12:46 PM, Koen Martens wrote: > Sender-ID uses SPF syntax, Microsoft claims to have patents pending on > Sender-ID and PRA, therefore it is not impossible that microsoft is > trying to patent SPF syntax. Is that so illogical? Yes, that doesn't follow. The IPR specifically states that it only covers what is in the core and pra drafts. It does not cover anything in the protocol draft, which is where the syntax of the records and the interpretation of that syntax are defined. If Microsoft was going to claim any IP rights over that they would have had to file an IPR for the protocol draft as well. They did not. - Mark From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:19: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 RAA12573 for ; Tue, 24 Aug 2004 17:19: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 i7OKwFYT056389; Tue, 24 Aug 2004 13:58: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 i7OKwFSQ056388; Tue, 24 Aug 2004 13:58:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OKwEi2056381 for ; Tue, 24 Aug 2004 13:58:15 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7OKw36U004204; Tue, 24 Aug 2004 13:58:03 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 13:58:03 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'terry@ashtonwoodshomes.com'" , "Hallam-Baker, Phillip" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged mess ages Date: Tue, 24 Aug 2004 13:57:54 -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 the computer 'knows' is not relevant to Mens Rea, only > > individuals > > and corporations are subject to criminal law. > > Wrong. If what you say is true then I could create a > computer program that creates/collects illegal > material (credit cards, kiddie porn, whatever) and because it > is the computer that is doing the work > I am not criminally liable. This is 1) A non sequitor 2) Sophistry 3) Written by someone lacking the standing to say 'wrong'. In this particular hypothetical it is clear that the Mens Rea existed when you configured the computer with the express intent of performing that action. It is no different from pulling a trigger on a gun to commit murder. The computer and gun are merely a tool. There is no comparison between those scenarios and a case where the consequence is neither intended nor likely. And here 'likely' has a very specific meaning which your hypotheticals do not reach. > Your being silly. If someone uses a knife or gun to commit > the crime, the justice system prosecutes > the person. The computer is just another such tool. But you do not claim that the knife or the gun had 'knowledge' or 'intent' which was exactly what you did claim. The operator of a mail server clearly does not have knowledge or intent in these cases. > > Sure you can find some really obscure offenses if you dredge > > up obscure > > parts of English law. That does not mean that there is the slightest > > chance that a Home Secretary is ever going to allow a prosecution. > > > > But we are not talking obscure. Porn and Phishing are > serious criminal offences perpetrated every > day on the internet using the SMTP protocol. > > And FYI the internet is not just for the UK. You brought up English law, not me. The same arguments hold for any common law jurisdiction. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:23: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 RAA12916 for ; Tue, 24 Aug 2004 17:23: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 i7OL1LeH056597; Tue, 24 Aug 2004 14: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 i7OL1L71056596; Tue, 24 Aug 2004 14:01:21 -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 i7OL1Khk056585 for ; Tue, 24 Aug 2004 14:01:21 -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 1BziPv-000Jx7-00; Tue, 24 Aug 2004 22:01:19 +0100 Message-ID: <0a0d01c48a1d$32cf0810$0200000a@ringo> From: "Chris Haynes" To: "Jim Lyon" Cc: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 21:59:03 +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 "Jim Lyon" commented: > > This thread has devolved into a fascinating discussion of arcane points > of British law, but it misses the fundamental point: > > A reasonable use of SenderID is to use it at SMTP time, and to refuse to > accept forged mail. If you refuse to accept it (by giving an error at > end of DATA), you won't generate a bounce. The MTA that was sending the > mail might or might not generate a bounce, but that's his problem, not > yours. I beg to differ. I am the one who has discovered that I am being offered a forgery. If I reject at SMTP time and a bounce is generated it is my responsibility, my karma. I knew full well that his machine may send a bounce, and include the malicious content. It is my decision, my responsibility, regardless of how the technology works. If we had on offer a Mail-From test (with HELO/EHLO where needed) and new SMTP semantics that said we MAY/SHOULD/MUST discard the message (with no bounce) if the Mail-From test fails, then I would be satisfied. > > In fact, most of the forged mail is sent by specialized spam engines or > virus propagation engines. These engines won't generate bounces, > they'll just give up and go on to the next victim. That may be true, but I'm concerned about everything that may happen, not just 'most'. > > So, deploying SenderID should result in fewer bounces, not more. And incorporating the tests & semantics developed in SPF would result in even fewer bounces - and totally eliminate the situations which concern me. > -- Jim Lyon > Chris Haynes From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:23: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 RAA12934 for ; Tue, 24 Aug 2004 17:23:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OL0t5R056560; Tue, 24 Aug 2004 14:00:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OL0t1j056559; Tue, 24 Aug 2004 14:00:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts16-srv.bellnexxia.net (tomts16-srv.bellnexxia.net [209.226.175.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OL0s9p056547 for ; Tue, 24 Aug 2004 14:00:54 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040824210053.UTBC14082.tomts16-srv.bellnexxia.net@ibmrkydk2ufvdd>; Tue, 24 Aug 2004 17:00:53 -0400 From: "John Glube" To: "'Jim Lyon'" , "'Hallam-Baker, Phillip'" , , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 17:00:39 -0400 Message-ID: <00c601c48a1d$69502040$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OL0s9p056554 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit From: Jim Lyon Sent: August 24, 2004 2:54 PM >A reasonable use of SenderID is to use it at SMTP time, and >to refuse to accept forged mail. If you refuse to accept >it (by giving an error at end of DATA), you won't generate >a bounce. >The MTA that was sending the mail might or might not >generate a bounce, but that's his problem, not yours. >In fact, most of the forged mail is sent by specialized >spam engines or virus propagation engines. These engines >won't generate bounces, they'll just give up and go on to >the next victim. A number of issues: * Your position presumes wide spread implementation of Submitter, allowing for extraction of the PRD at the data stage. * Until this happens, as Sender-ID is presently drafted, the receiving MTA has to 'swallow' the message and extract the PRA from the headers. As has been previously stated this leads to a greater risk of false positives. * Sender-ID does not call for SMTP mail from checks at the DATA stage in the absence of PRA. If you are suggesting either amending Sender-ID or preparing a BCP document to suggest that receivers do carry out SMTP mail from checks at the DATA stage in the absence of PRA, I would whole heartedly support this. * I am concerned about the suggestion that: >If you refuse to accept it (by giving an error at end of >DATA), you won't generate a bounce. I agree if there is no domain found in either Submitter or SMTP mail from this may be appropriate. However, the appropriate 55x error message must be generated, so that legitimate senders with mis-configured mail servers can rectify the situation. Also, in the event of Submitter or SMTP mail from spoofing, again it is important to generate the appropriate 55x error message, so that legitimate senders with mis-configured email policy records can sort out the problems. There is no love lost for forged headers. At the same time, I suggest we need to take care not to throw out senders who are endeavouring to comply but for some reason are using mis-configured mail servers, who have made errors in publishing their email policy records, or who have failed to update their email policy records as a result of system changes. Finally you write: >In fact, most of the forged mail is sent by specialized >spam engines or virus propagation engines. These engines >won't generate bounces, they'll just give up and go on to >the next victim. My understanding is different. Apparently according to published reports earlier this summer between 60 to 80% of UBE is now sent by spammers accessing zombie computers on infected networks. The use of specialized spam engines is apparently no longer the spammer's weapon of choice. (See in particular comments made by Stephen Linford in June at an anti spam conference in London, England, along with an article published by Tom Donnelly through Circle-ID.) Recent reports indicate less than 1% of all filtered email is CAN SPAM compliant. This leads me to believe most UBE coming from zombie computers uses forged return paths. Anecdotal evidence seems to confirm this understanding. Therefore I am not sure the conclusion you reach is correct. Having said all of this, from my personal perspective, having made a fuss about the license, I am satisfied with the IPR statement given the representations made by MS in the FAQ and the form of license. Others will strongly disagree and let the discussion continue. From my perspective, the core issues involve technical concerns surrounding the need to protect the return path and related deployment concerns arising from the failure to protect the return path against spoofing or fraud in Sender-ID. Having said this I acknowledge the Sender-ID specifications does not focus on these issues. I have previously stated these concerns can be resolved through the use of a Best Current Practices document. For more on this, see my earlier discussions in the threads What Meng Said, Point of Order, Incomplete Flawed Response to MARID WG Charter and Forged Sender (Resent From Attacks). Unless this 'circle is squared' Sender-ID will in my view continue to meet with opposition in the open source community as it compels software developers to utilize the PRA algorithm. I don't know whether this will ultimately result in the WG rejecting Sender-ID. But I strongly believe without resolution it will ultimately result in an attitude of two solitudes between those supporting Sender-ID and those supporting SPF. I come from a country which has dealt with the problem of two solitudes existing between founding national groups for over 100 years. This has lead to the development of a confederation which allows for co-existence of diverse ethnic groups within one nation state. This WG is essentially confronted with the same reality. There is not just one way of dealing with sender authentication. It would be tragic if this WG was to ignore the underlying problems now facing implementation of sender authentication given the developing split between the SPF and Sender-ID communities. This is also why I support the CSV proposal. 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.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:27:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13113 for ; Tue, 24 Aug 2004 17:27:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OL79JO057039; Tue, 24 Aug 2004 14:07: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 i7OL79jE057038; Tue, 24 Aug 2004 14:07:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OL77ZK057019 for ; Tue, 24 Aug 2004 14:07:08 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7OL77AU021551 for ; Tue, 24 Aug 2004 22:07:07 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7OL77t7021550; Tue, 24 Aug 2004 22:07:07 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: DEPLOY - IPR on Sender-ID not sufficiently disclosed References: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> <1093374079.12516.16.camel@vodka> From: Graham Murray Date: Tue, 24 Aug 2004 22:07:07 +0100 In-Reply-To: <1093374079.12516.16.camel@vodka> (Ryan Ordway's message of "Tue, 24 Aug 2004 12:01:19 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ryan Ordway writes: > My question is, what portions of -core are covered? > Harry's answer above seems to suggest that the entirety of > -core and -pra are covered by Microsoft's IPR claim, am I > right? Until this is explicitly spelled out, I think any > discussion or action is moot. And a sizeable portion of -core is based on SPF, which was merged with Microsoft's Caller-ID to form Sender-ID. So if Microsoft are claiming their IPR covers all of -core then (logically) one of the following must be true Either:- a) Microsoft already had pending (or potential) IPR claims covering SPF-classic before the merge into -core. OR b) They are now claiming IPR on someone else's work. The alternative is that the IPR does not cover all of -core, in which case please can they clarify which parts of -core are (potentially) encumbered by the IPR? From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:28: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 RAA13150 for ; Tue, 24 Aug 2004 17:28: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 i7OL5uHp056957; Tue, 24 Aug 2004 14:05: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 i7OL5ujV056956; Tue, 24 Aug 2004 14:05:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OL5tl0056937 for ; Tue, 24 Aug 2004 14:05:55 -0700 (PDT) (envelope-from george@m5p.com) Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by mailhost.m5p.com (8.12.11/8.12.11) with ESMTP id i7OL5pSF045918 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Aug 2004 14:05:52 -0700 (PDT) Received: (from defang@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7OL1mi7045890 for ; Tue, 24 Aug 2004 14:01:48 -0700 (PDT) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (MIMEDefang) with ESMTP id i7OL1mBB045889; Tue, 24 Aug 2004 14:01:48 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7OL1llP001114; Tue, 24 Aug 2004 14:01:47 -0700 (PDT) Date: Tue, 24 Aug 2004 14:01:47 -0700 (PDT) From: George Mitchell Message-Id: <200408242101.i7OL1llP001114@m5p.com> To: gmc@metro.cx, hkatz@exchange.microsoft.com Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Cc: ietf-mxcomp@imc.org In-Reply-To: <20040824165210.GB13538@metro.cx> X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Koen Martens wrote: > > All, > > Again, I come out of the darkness of my lurking position and speak up my > mind. > > I have been watching the discussions on this list continuously, and > technically there is not a lot against Sender-ID (although some proper > objections have been made, which I will not repeat here). > > I have been worried about the licensing issue, but have been convinced > to wait it out. Now, with the 23 august deadline passed, I still see > that there is reason for concern. Although a license has been prepared, > it still does not say what exactly is licensed. > > I refer to Harry Katz' remark: > > > If you have any further questions about the license, I encourage you to > > consult with your own attorney and/or email your question to > > stdsreq@microsoft.com. Someone from our legal department will answer > > your questions. > > I am not prepared to contact my attorney (i don't have one) to do > open-source development on Sender-ID. For me, this means all work on > Sender-ID is a nono. I will continue to labour for SPF+SRS. I can only > hope the SPF Classic drafts (or better, Unified SPF) will be MARID's > proposal, replacing the technically imperfect and legally troublesome > Sender-ID proposal, but failing that I (and I believe many others) > will continue work on SPF. > > It would be a shame if this leads to a split, where one part of the > industry/community works on Sender-ID and another works on SPF. This > will frustrate the general cause we are 'fighting' for. > > > Koen Martens > > P.s.: note that there are many people lurking on the list as did I, > reluctant to step in and join a debate among real experts that seem to > have a more than thorough knowledge of email. I hope many of them will > step forward, and voice their concern about this IPR business now, or > else it might just be too late. > > -- > K.F.J. Martens, Sonologic, http://www.sonologic.nl/ > Networking, embedded systems, unix expertise, artificial intelligence. > Public PGP key: http://www.metro.cx/pubkey-gmc.asc > Wondering about the funny attachment your mail program > can't read? Visit http://www.openpgp.org/ I second Koen's remarks. Based on these facts: * SPF+SRS is embodied in working code. (Two widely publicized implementations, and there are probably others.) * SPF+SRS is deployed. * SPF+SRS is not encumbered by any intellectual property claims. what do you think we should do next? -- George Mitchell From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17:35: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 RAA13671 for ; Tue, 24 Aug 2004 17:35: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 i7OLGtFu057746; Tue, 24 Aug 2004 14:16: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 i7OLGt2a057745; Tue, 24 Aug 2004 14:16: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 i7OLGtSZ057739 for ; Tue, 24 Aug 2004 14:16: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 D09A2414C3; Tue, 24 Aug 2004 14:16:59 -0700 (PDT) Subject: DEPLOY: Creating bounces from forged messages From: Douglas Otis To: Jim Lyon Cc: terry@ashtonwoodshomes.com, Chris Haynes , IETF MARID WG In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1093382218.2762.32.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 24 Aug 2004 14:16: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 Tue, 2004-08-24 at 11:54, Jim Lyon wrote: > A reasonable use of SenderID is to use it at SMTP time, and to refuse to > accept forged mail. A reasonable use of SMTP may be for relaying mail without completing all checks at each MTA, such as ensuring recipients within the local domain are all valid. Even if Sender-ID were checked by each MTA, it would be unreasonable to expect spam would be refused as a result. Although there may be a learning curve, don't expect finding "open" records to prove an insurmountable discovery. > If you refuse to accept it (by giving an error at end of DATA), you > won't generate a bounce. If the MTA is a relay receiving the refusal, then this MTA _MUST_ generate a bounce. > The MTA that was sending the mail might or might not generate a > bounce, but that's his problem, not yours. If the bounce is to you, from an MTA regarded as a reputable, you receive these bounces. If this mail stream is within an administratively shared realm, then the problem may occur at your provider's relay. Either way, Sender-ID does not curtail this problem. > In fact, most of the forged mail is sent by specialized spam engines or > virus propagation engines. These engines won't generate bounces, > they'll just give up and go on to the next victim. These specialized spam engines are not likely to be rejected either. Sender-ID makes it _extremely_ easy to spoof MTA permissions! > So, deploying SenderID should result in fewer bounces, not more. Sender-ID pays no attention to the return-path. How do you arrive at there being fewer bounces? Those that attempt to ratchet up their acceptance levels for Sender-ID will actually invite more of this spoofed return-path behavior, as Sender-ID is unable to discern when the return-path is valid. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 17: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 RAA14604 for ; Tue, 24 Aug 2004 17: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 i7OLY6LL058793; Tue, 24 Aug 2004 14:34: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 i7OLY6BS058792; Tue, 24 Aug 2004 14:34:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLY69U058786 for ; Tue, 24 Aug 2004 14:34:06 -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); Tue, 24 Aug 2004 14:34:11 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 2004 14:34:10 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 14:34:10 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 14:34:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 14:34:08 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8898E3@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Legal liability for creating bounces from forged messages Thread-Index: AcSKHYBhHsZGpopwRleSWiyz15vfuAAAmtgg From: "Jim Lyon" To: "John Glube" , "Hallam-Baker, Phillip" , , "Chris Haynes" , "IETF MARID WG" X-OriginalArrivalTime: 24 Aug 2004 21:34:35.0878 (UTC) FILETIME=[26DD6060:01C48A22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OLY69U058787 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Regarding generation of bounces vs. rejecting mail at SMTP time, John Glube raises a number of issues: > * Your position presumes wide spread implementation of > Submitter, allowing for extraction of the PRD at the data > stage. No. SUBMITTER allows you to reject the message at MAIL command time. Without SUMBMITTER, you can extract the PRD during receipt of the message, and reject the message and end-of-data time. > * Until this happens, as Sender-ID is presently drafted, > the receiving MTA has to 'swallow' the message and extract > the PRA from the headers. As has been previously stated > this leads to a greater risk of false positives. Without SUBMITTER, the receiving MTA has to receive the message, but does not need to accept it. The risk of false positives is identical whether SUBMITTER is used or not. SUBMITTER merely lets the receiver do the test earlier, saving bandwidth for both sender and receiver if the message is destined for refusal. > * Sender-ID does not call for SMTP mail from checks at the > DATA stage in the absence of PRA. If you are suggesting > either amending Sender-ID or preparing a BCP document to > suggest that receivers do carry out SMTP mail from checks > at the DATA stage in the absence of PRA, I would whole > heartedly support this. I'm not sure what you mean by "the absence of PRA". If you mean "the absence of SUBMITTER", then the current docs certainly contemplate this. They even tell you what message to use when rejecting mail. (If you mean something else, I'm afraid I completely missed your point.) > (lots more words arguing that most spam is sent by zombies.) Yes, it is. But the zombies tend to run specialized spam engines, not real MTAs. And they don't generally send the mail through the zombied machine's ISP's MTA, they send it directly to the recipient. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 18:04:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15173 for ; Tue, 24 Aug 2004 18:04:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLi0Jr059575; Tue, 24 Aug 2004 14:44: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 i7OLi0wL059574; Tue, 24 Aug 2004 14:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLi0UF059568 for ; Tue, 24 Aug 2004 14:44:00 -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); Tue, 24 Aug 2004 14:44:04 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 2004 14:44:04 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 14:44:04 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 14:44:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 14:44:02 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8898F3@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Legal liability for creating bounces from forged messages Thread-Index: AcSKHZMD9j8vdM3gRSqarC+mMgJ8HAABIu6Q From: "Jim Lyon" To: "Chris Haynes" Cc: "IETF MARID WG" X-OriginalArrivalTime: 24 Aug 2004 21:44:41.0988 (UTC) FILETIME=[90226C40:01C48A23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OLi0UF059569 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Chris, You're between a rock and a hard place. If you simultaneously believe that all of the following are sinful: 1. To accept and deliver forged mail. 2. To accept forged mail and silently discard it. 3. To accept forged mail and then generate a bounce. 4. To reject forged mail because the sender might generate a bounce. then you have no alternatives left. The current drafts give you a way to avoid (1) -- that's their whole point. They leave it as a local policy decision as to which of 2, 3 or 4 you choose. They recommend (4) with a "SHOULD", but you can reasonably do either of the others. Today, many large ISPs silently discard mail that they classify as spam. I expect that those ISPs will choose (2) when implementing SenderID. Your thoughts about MAIL-FROM, HELO and EHLO don't change the above calculus at all. They merely change the details of which messages you classify as forged. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 18:05: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 SAA15325 for ; Tue, 24 Aug 2004 18:05: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 i7OLe1bm059196; Tue, 24 Aug 2004 14: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 i7OLe11V059195; Tue, 24 Aug 2004 14:40:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.well.com (smtp.well.com [206.14.209.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLe18q059189 for ; Tue, 24 Aug 2004 14:40:01 -0700 (PDT) (envelope-from cpm@well.com) X-WELL-Auth: Yes Received: from [192.168.0.9] (orthanc.avwashington.com [199.227.4.34]) by smtp.well.com (8.13.0/8.13.0) with ESMTP id i7OLdifO025239 for ; Tue, 24 Aug 2004 14:39:45 -0700 (PDT) Message-ID: <412BB55F.5060606@well.com> Date: Tue, 24 Aug 2004 17:38:39 -0400 From: Chip Mefford User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'IETF MARID List'" Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License References: In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on smtp X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallam-Baker, Phillip wrote: |>True, but if the patent is used to control the source code, |>the difference is trivial and irrelevant. | | | This is a very complex legal argument, calling it trivial shows a | distinct lack of comprehension. I think he meant that in the context of what was stated, there isn't a practical difference between the patent and the source code license, as the patent is used to control the source code. | |>>TO THE PROGRAM |> |>So what? A standard is irrelevant if there is no program |>that implements it. | | Plans are irrelevant if no house is ever built to them. But that | does not mean that a plans are the same as a house, the fact that | a plan is copyright and certain rights on the distribution are | reserved does not mean that the copy is encumbered. Nicely put. However, it also does not mean that the copy is unencumbered either, as this is not strictly stated. This is (among other things) wiggle room. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBK7Vca44x14FCa6ARAi0xAJ99bLxrIj4ncML09Ru+aXIjrPnZqACgmtGs NxZALKv/DDTT4bV8nAhr/C8= =ZE1S -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 18:16: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 SAA17865 for ; Tue, 24 Aug 2004 18:16: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 i7OLsqos062523; Tue, 24 Aug 2004 14:54:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OLsqa1062522; Tue, 24 Aug 2004 14:54:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLsq62062514 for ; Tue, 24 Aug 2004 14:54:52 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Aug 2004 14:54:56 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 2004 14:54:56 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 14:54:56 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 14:55:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Creating bounces from forged messages Date: Tue, 24 Aug 2004 14:54:54 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF889901@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Creating bounces from forged messages Thread-Index: AcSKH8Ly3Q+GOQOrRsqAxYOXD1LJ5gAA/2Pg From: "Jim Lyon" To: "Douglas Otis" Cc: , "Chris Haynes" , "IETF MARID WG" X-OriginalArrivalTime: 24 Aug 2004 21:55:37.0019 (UTC) FILETIME=[169038B0:01C48A25] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OLsq62062515 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Doug Otis writes in about bounces to forged messages, making the following points: 1. Sometimes, messages get relayed from MTA to MTA to MTA before arriving at their ultimate destination. 2. If you relay to an MTA that refuses a message, you MUST generate a bounce. 3. If you receive a bounce from what you regard as a reputable MTA, you'll deliver it. He then asks how I think SenderID will result in fewer bounces. Here's how: Most forged mail is sent by specialized spam engines (including zombie machines) directly to the internet-facing gateway machine of the recipient. Unlike most legitimate mail, it doesn't pass through an MTA in the sender's organization. When the internet-facing MTA of the recipient receives the message, it can perform SenderID checks and refuse the message, at either MAIL command time or end-of-data time. In either case, the receiver doesn't generate a bounce (because it's not his responsibility) and the spam engine doesn't generate a bounce (because there's no value to them in doing so). Even if you postulated a spam engine that generated a bounce, that bounce would generally get rejected by the same SenderID tests. That's how. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 18:24:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18903 for ; Tue, 24 Aug 2004 18:24: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 i7OM59lo064750; Tue, 24 Aug 2004 15:05: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 i7OM59KA064749; Tue, 24 Aug 2004 15:05:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OM58n0064741 for ; Tue, 24 Aug 2004 15:05:08 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Aug 2004 15:05:13 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 2004 15:05:13 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 15:05:13 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 15:05:44 -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: DEPLOY - IPR on Sender-ID not sufficiently disclosed Date: Tue, 24 Aug 2004 15:05:10 -0700 Message-ID: Thread-Topic: DEPLOY - IPR on Sender-ID not sufficiently disclosed thread-index: AcSKIUC4QVBEk8tDSECg+BajrzKJtQABO9eQ From: "Harry Katz" To: "Mark Lentczner" , "IETF MARID WG" X-OriginalArrivalTime: 24 Aug 2004 22:05:44.0756 (UTC) FILETIME=[80CD8740:01C48A26] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OM58n0064743 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tuesday, August 24, 2004 1:56 PM, Mark Lentczner wrote: > On Aug 24, 2004, at 12:46 PM, Koen Martens wrote: > > Sender-ID uses SPF syntax, Microsoft claims to have patents > pending on > > Sender-ID and PRA, therefore it is not impossible that microsoft is > > trying to patent SPF syntax. Is that so illogical? > > Yes, that doesn't follow. The IPR specifically states that > it only covers what is in the core and pra drafts. It does > not cover anything in the protocol draft, which is where the > syntax of the records and the interpretation of that syntax > are defined. If Microsoft was going to claim any IP rights > over that they would have had to file an IPR for the protocol > draft as well. They did not. > > - Mark Agreed! Thank you, Mark. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 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 SAA19140 for ; Tue, 24 Aug 2004 18:27:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OM79L3065155; Tue, 24 Aug 2004 15:07: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 i7OM79QX065154; Tue, 24 Aug 2004 15:07:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7OM785L065137 for ; Tue, 24 Aug 2004 15:07:09 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id B14A81A6C6; Wed, 25 Aug 2004 00:07:10 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 945E11A6B1; Wed, 25 Aug 2004 00:07:06 +0200 (CEST) Message-Id: Date: Wed, 25 Aug 2004 00:06:59 +0200 From: Arnt Gulbrandsen To: terry@ashtonwoodshomes.com Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Cc: Harry Katz , "Mark C. Langston" , IETF MARID List References: <016601c48a17$de735dc0$2766f30a@development.greatgulfhomes.com> In-Reply-To: <016601c48a17$de735dc0$2766f30a@development.greatgulfhomes.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: terry@ashtonwoodshomes.com writes: > Right, and then get the clarification put into the license itself so > it does not need the clarification. Or will that take several weeks > to do also? Relax. Microsoft, apart from being Microsoft, is also a big company. Things take a long time at big companies. Arnt From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 18: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 SAA20658 for ; Tue, 24 Aug 2004 18:56: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 i7OMTcf6070356; Tue, 24 Aug 2004 15:29:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OMTc0F070355; Tue, 24 Aug 2004 15:29:38 -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 i7OMTb7v070337 for ; Tue, 24 Aug 2004 15:29:37 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040824222941.XPRX19123.tomts20-srv.bellnexxia.net@ibmrkydk2ufvdd>; Tue, 24 Aug 2004 18:29:41 -0400 From: "John Glube" To: "'Jim Lyon'" , "'Hallam-Baker, Phillip'" , , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 18:29:27 -0400 Message-ID: <00ce01c48a29$d0c9b9f0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8898E3@df-fido-msg.exchange.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OMTc7v070350 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit From: Jim Lyon Sent: August 24, 2004 5:34 PM Draft marid submitter states in the Introduction on page 2: >Deriving the purported responsible domain from RFC 2821 >data has the advantage that validation can be performed >before the SMTP client has transmitted the message body. >If spoofing is detected, then the SMTP server has the >opportunity, depending upon local policy, to reject the >message before it is ever transmitted." However draft marid core states in the Negative problem statement at page 2: >Following are several alternate questions, which this >specification makes no attempt to answer: > 1. Is the host at a particular IP address authorized to >act as an SMTP client? > 2. Is an SMTP client authorized to use a particular >domain name in its SMTP EHLO command? > 3. Is an SMTP client authorized to use a particular >email address in an SMTP "MAIL FROM:" command? > 4. Was a message really authored by who it claims to be >authored by? The point being as noted by Chris Haynes in the thread "What Meng Said" where he wrote: >Meng, >Please may I ask a brutally simple question. >I think it is generally agreed that where MAIL-FROM == PRA >any decision is based on the PRA. >My question below applies only to those messages in which >the domain of the MAIL-FROM is different from the domain of >the PRA. >Where, in the collection of drafts issued on Friday, does >Sender-ID refer to the rejection of a message as a result >of evaluating the record associated with its MAIL-FROM >domain? >Chris Haynes http://www.imc.org/ietf-mxcomp/mail-archive/msg03306.html To which Meng responded: >Sender ID as currently specified doesn't do that. >If people want the MAIL FROM to play a role in Sender ID, >they should say so. If they do not say so, the working >assumption is that nobody cares. >I personally think that if the PRA lookup returns "none" or >"unknown", MAIL FROM should be checked, and if that test >returns "fail" then the message should be rejected. http://www.imc.org/ietf-mxcomp/mail-archive/msg03324.html - and my follow up message - http://www.imc.org/ietf-mxcomp/mail-archive/msg03339.html I am speaking of this issue, which in turn includes the concern raised by Nate Leon when he wrote in part: >For completeness, here is another example of the concern: >MAIL FROM:<> // don't care >RCPT TO: >DATA >Subject: update your account info Resent-From: >JoePhisher@xxxxxxxxxxxxxxxx // valid domain >authenticated by MARID ... >From: account-services@xxxxxxxxxxxx // Spoofed domain, >displayed by the MUA To: >valid-recipient@xxxxxxxxxxx // bummer for you >... Are we really going to RFC with this issue left >open? http://www.imc.org/ietf-mxcomp/mail-archive/msg03372.html Harry Katz's responses: http://www.imc.org/ietf-mxcomp/mail-archive/msg03375.html - and - http://www.imc.org/ietf-mxcomp/mail-archive/msg03416.html and my message in response: http://www.imc.org/ietf-mxcomp/mail-archive/msg03443.html Also see the following three message: My message found at: http://www.imc.org/ietf-mxcomp/mail-archive/msg03417.html - and - Daryl Odnert's response: http://www.imc.org/ietf-mxcomp/mail-archive/msg03421.html - and - My reply: http://www.imc.org/ietf-mxcomp/mail-archive/msg03458.html These messages reflect the deployment issues I am raising with marid-protocol/marid-core and which remain outstanding. Please also note the last statement from Chris Haynes in his most recent message: >And incorporating the tests & semantics developed in SPF >would result in even fewer bounces - and totally eliminate >the situations which concern me. Trusting this makes my position clearer. 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.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 19:08: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 TAA21330 for ; Tue, 24 Aug 2004 19:08: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 i7OMavEw071679; Tue, 24 Aug 2004 15:36:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OMav0l071678; Tue, 24 Aug 2004 15:36:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OMavtf071671 for ; Tue, 24 Aug 2004 15:36:57 -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 E9CEB4149B; Tue, 24 Aug 2004 15:37:02 -0700 (PDT) Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ From: Douglas Otis To: Eric Allman Cc: Stephane Bortzmeyer , Harry Katz , stdsreq@microsoft.com, IETF MARID List In-Reply-To: References: <20040824071602.GF13303@nic.fr> Content-Type: text/plain Message-Id: <1093387021.2762.101.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 24 Aug 2004 15:37:01 -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-08-24 at 13:48, Eric Allman wrote: > | Taking this into account and reading Eric Allman analysis > | (http://www.imc.org/ietf-mxcomp/mail-archive/msg03500.html), it > | seems the most common free software licence, the GPL, is > | incompatible with Microsoft licence on SenderID. > > I didn't say that. I said that _some_ people may believe this, but > there is also some significant reason to believe that they are > incorrect, including statements from both Eben Moglen and Lawrence > Rosen, both of whom are lawyers. As near as I can tell, the question > of GPL compatibility is quite ambiguous at this time. A few years back, working within a different standards body developing a standard for a storage device, there were deliberations regarding how data would be referenced. A device manufacture holding a patent for an existing scheme made a very similar offer to the group. This contractual agreement was honored until the rights to the intellectual property were transferred to a media manufacturer after production became established. Suddenly, reasonable terms were refused other media manufacturers. Media quickly tripled in price. At the time, there were better schemes that could have been used. : ( At least, this was regarding a device in competition with several other technologies, and where a breach in this promise (in spirit at least) only affected the profits of about half a dozen manufactures. Email is not divided into small independent segments of an industry however. Email is likely one of the most pivotal network and business applications that exists. I would hate to be lured by false promises of Sender-ID, into acquiescing this application to a corporation. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 19:13: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 TAA21719 for ; Tue, 24 Aug 2004 19: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 i7OMlSXv073631; Tue, 24 Aug 2004 15:47: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 i7OMlSWc073630; Tue, 24 Aug 2004 15:47:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OMlPSp073612 for ; Tue, 24 Aug 2004 15:47:27 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7OMlN77001023 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Aug 2004 18:47:26 -0400 Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages From: Mark Shewmaker To: IETF MARID WG In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8898E3@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8898E3@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1093387722.7911.11556.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 24 Aug 2004 18:48:42 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Tue, 24 Aug 2004 18:47:27 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-24 at 17:34, Jim Lyon wrote: > Regarding generation of bounces vs. rejecting mail at SMTP time, John > Glube raises a number of issues: > > * Your position presumes wide spread implementation of > > Submitter, allowing for extraction of the PRD at the data > > stage. > > No. SUBMITTER allows you to reject the message at MAIL command time. > Without SUMBMITTER, you can extract the PRD during receipt of the > message, and reject the message and end-of-data time. No: Without SUBMITTER, you still might have to bounce, (not reject) messages after end-of-data time. This can happen if one recipient has white-listed the PRA, but another recipient hasn't. If the MTA server were given a SUBMITTER parameter, it could have done per-user rejects at RCPT TO: time, and avoided the need for bounces altogether. However, if the MTA server isn't given a SUBMITTER parameter, then differences between recipient white-listings can cause the MTA to have to accept the message and then generate bounces for the non-white-listed recipients. The only potential solutions I can see are: 1. Unified SPF, so that MAIL FROM is always checks: This is only a partial solution unfortunately. It can only filter out some forged Return-Path's. 2. An SMTP extension to do per-user after-data rejects: This would be a great extension, but until almost everyone uses it we couldn't require it. 3. In the case of differing per-recipient white-lists, rejecting all recipients from the first contrary one onwards with a "too many recipients" transient error. This violates RFC 2821, as you're supposed to always be able to accept at least 100 recipients, but I think it might be the only sure-fire solution that can handle this problem, and that doesn't assume the rest of the world upgrades to newer SMTP extensions. I think choice #3 is the only viable choice. It's ugly, but it's the only thing that can really prevent this bounce-generation problem. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 19:15: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 TAA21831 for ; Tue, 24 Aug 2004 19:15:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OMm27i073707; Tue, 24 Aug 2004 15: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 i7OMm24W073706; Tue, 24 Aug 2004 15:48:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OMm2b3073698 for ; Tue, 24 Aug 2004 15:48:02 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7OMm677001062 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Aug 2004 18:48:06 -0400 Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ From: Mark Shewmaker To: IETF MARID List In-Reply-To: References: <20040824071602.GF13303@nic.fr> Content-Type: text/plain Message-Id: <1093387765.1840.11560.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 24 Aug 2004 18:49:25 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Tue, 24 Aug 2004 18:48:07 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-24 at 16:48, Eric Allman wrote: > As near as I can tell, the question > of GPL compatibility is quite ambiguous at this time. I'm sorry, but the [L]GPL incompatibility couldn't be more unambiguous: 1. Choice of law restrictions, choice of venue restrictions, and poison pills are widely understood to be incompatible with the [L]GPL. 2. A distributor of an implementation of SenderID would have no way of allowing all recipients to modify and further redistribute that implementation, which means that it simply can't be [L]GPL compatible. It's too bad the mxcomp list restricted discussion of licensing issues before yesterday's deadline. I truly believe we could have ended up with a licensing solution that everyone could have been pleased as punch about. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 19:42: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 TAA24154 for ; Tue, 24 Aug 2004 19:42: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 i7ONF0K4078624; Tue, 24 Aug 2004 16:15: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 i7ONF0oN078623; Tue, 24 Aug 2004 16:15: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 i7ONF0Ma078615 for ; Tue, 24 Aug 2004 16:15:00 -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 84CF9414C3; Tue, 24 Aug 2004 16:15:05 -0700 (PDT) Subject: RE: DEPLOY: Creating bounces from forged messages From: Douglas Otis To: Jim Lyon Cc: terry@ashtonwoodshomes.com, Chris Haynes , IETF MARID WG In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF889901@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF889901@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1093389304.2762.139.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 24 Aug 2004 16:15:04 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-24 at 14:54, Jim Lyon wrote: > Doug Otis writes in about bounces to forged messages, making the > following points: > > 1. Sometimes, messages get relayed from MTA to MTA to MTA before > arriving at their ultimate destination. > > 2. If you relay to an MTA that refuses a message, you MUST generate a > bounce. > > 3. If you receive a bounce from what you regard as a reputable MTA, > you'll deliver it. > > He then asks how I think SenderID will result in fewer bounces. Here's > how: > > Most forged mail is sent by specialized spam engines (including zombie > machines) directly to the Internet-facing gateway machine of the > recipient. Unlike most legitimate mail, it doesn't pass through an MTA > in the sender's organization. A sending MTA is able to spoof its authorization in many ways. One method would be using Sender-ID's generous "open" record used by those brave soles wanting to send mail from other points of access, while still identifying themselves to their recipients with their well-known mailbox address. Perhaps they use a type of digital signature as an assurance. If the initial MTA is a relay into this domain, it will be generating bounces when the recipient is invalid or when a virus is detected by a post acceptance process. These virus bounces often do not have null return paths nor do they require a relay for the bounce. Do these relays exist? Yes. Does Sender-ID reduce the number of such relays? No. Does Sender-ID reduce the number of such bounces? No. Does the mail from a spammer need to pass through several of their own MTAs for a bounce to be created? Absolutely not! > When the Internet-facing MTA of the recipient receives the message, it > can perform SenderID checks and refuse the message, at either MAIL > command time or end-of-data time. As I said, there are many administratively shared MTAs where not all the checks are made upon initial acceptance. This fact is relied upon as a common technique used by spammers. Once the recipient is discovered to be invalid, this message becomes bounced. Sender-ID has not helped. > In either case, the receiver doesn't generate a bounce (because it's > not his responsibility) and the spam engine doesn't generate a bounce > (because there's no value to them in doing so). You have failed to understand how SMTP is often used to relay mail. Sender-ID makes it _extremely_ easy to spoof sending MTA authorization. A single sending MTA can spoof thousands of authorizations, none of which may be using records under their administrative control. > Even if you postulated a spam engine that generated a bounce, that > bounce would generally get rejected by the same SenderID tests. I never suggested such nonsense. I suggested that when some domain decides to raise their acceptance policies beyond the norm, this will invite use of a very common spamming technique that takes advantage of mail relays as a back-door into these sites. Mail relays don't go away with Sender-ID. The harder the site attempts to use Sender-ID to refuse mail, the more bounce traffic they will see as a result. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 20:04: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 UAA25457 for ; Tue, 24 Aug 2004 20:04: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 i7ONW3gD080756; Tue, 24 Aug 2004 16:32: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 i7ONW3Xi080755; Tue, 24 Aug 2004 16:32:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ONW3nQ080748 for ; Tue, 24 Aug 2004 16:32:03 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Aug 2004 16:32:08 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 2004 16:32:08 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 16:32:08 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 16:32:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Tue, 24 Aug 2004 16:32:04 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8899A2@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Legal liability for creating bounces from forged messages Thread-Index: AcSKKgHkfbNQPsS6RU+2QzrZPvutsgAB4u8Q From: "Jim Lyon" To: "John Glube" , "Hallam-Baker, Phillip" , , "Chris Haynes" , "IETF MARID WG" X-OriginalArrivalTime: 24 Aug 2004 23:32:08.0336 (UTC) FILETIME=[92751100:01C48A32] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7ONW3nQ080749 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit John cites a whole slew of previous messages, which by the time you strip out the irrelevant stuff appear to raise the following question: Given how easy it would be for a forger to insert a Resent-From header (for example), shouldn't we have some sort of stronger check? John, I think you should raise the issue in a separate thread. Conflating this with a thread that has already visited issues like whether British law allows conviction of non-humans does not seem like a good thing. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 20:22: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 UAA26711 for ; Tue, 24 Aug 2004 20:22:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ONw2OM083650; Tue, 24 Aug 2004 16:58:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ONw2Qi083649; Tue, 24 Aug 2004 16:58:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ONw2O8083641 for ; Tue, 24 Aug 2004 16:58:02 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7ONw7bB014696; Tue, 24 Aug 2004 16:58:07 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 16:58:07 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Chip Mefford'" , "'IETF MARID List'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License Date: Tue, 24 Aug 2004 16:58:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Nicely put. However, it also does not mean that the copy is > unencumbered > either, as this is not strictly stated. This is (among other things) > wiggle room. If there is ambiguity in a contract the interpretation goes against the party who wrote it. That is why it was essential for Microsoft to draft this, they don't get the benefit of any wiggle room. As a practical matter the empirical definition of law is what a court rules. Now some complete fools get appointed to the bench and it is impossible to be sure that there will not be a ridiculous decision. But consider, what is the likelihood of an adverse decision that involves damages or an injunction prohibiting distribution against any party that is not making a claim without granting reciprocal rights? If an action was taken against any party they can bring themselves into compliance at any time. Patent disputes cost millions and there is always a risk that the court proceedings would end with the patent being declared invalid. Microsoft would not be in a position to claim loss of revenue. As a matter of longstanding IETF precedent a license with a reciprocal rights clause is the norm. This has never been objected to in the past. The idea of a reciprocal grant does not seem to me to be antithetical to the aims of the GPL, quite the opposite. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 20: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 UAA27609 for ; Tue, 24 Aug 2004 20:39:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P0IsVD085743; Tue, 24 Aug 2004 17:18: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 i7P0IsRY085742; Tue, 24 Aug 2004 17:18:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P0IrnO085735 for ; Tue, 24 Aug 2004 17:18:53 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7P0HRqN017834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 20:17:34 -0400 Subject: DEPLOY: Microsoft Patent license unworkable with GPLed MTAs From: Paul Iadonisi To: ietf-mxcomp@imc.org Content-Type: text/plain Message-Id: <1093393029.17943.90.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 24 Aug 2004 20:17:09 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Although I have been moderately active on the spf-discuss mailing list, I have only been lurking on this list, but for some time now. Nevertheless, now that Microsoft has only just now, as of last night, published its license for its IPR claims on unspecified technologies in the -core and -pra drafts, I submit my evaluation of it and my concern as MARID moves forward. Let me preface this by saying that being told to speak with my lawyer to contact Microsoft's legal department is not, in my opinion, an answer that is acceptable at this late stage. It has taken Harry Katz at least a month to go from saying that he will be working with Microsoft attorneys to get an answer to last night's posting of the updated license. Why should a non-Microsoft employee expect to get a quicker answer to get things clarified? I thought one of the co-chairs made it clear about month ago that when participating in this WG, we participate as individuals. Why should anyone on this list be directed to legal department of the employer of someone on this list if that is, in fact, the case? And on the issue of 'speaking to my lawyer', that is not something many GPL licensed software authors can afford. Even those who are small businesses. This list was promised clarification and this list is where any clarifications should take place. And no, I do not believe that has been accomplished. Next, I'm boggled by Eric Allman first saying that it isn't "completely clear" that the Defensive Suspension and non-sublicenseability clauses interact with the GPL and then going on to conclude that Sender-ID should be endorsed, anyhow. And saying that Eben Moglen found such license conditions acceptable is a stretch. (And as a side note, and an honest question, were these Office XML patents being submitted as part of an IETF standard? If not, then it is irrelevant to this discussion.) In that same quote paragraph, Mr. Moglen says 'This is not a license I would like to accept', but overall, in the area of Office XML patents, he also pointed out that it was unclear *what* patents Microsoft had. Later in that article, Mr. Moglen explains that: "Section 7 of the GPL says if you're restricted by a judgement or a license you've accepted, and they're incompatible, then you can't distribute your software under GPL. But it's not the case that this license violates Section 7." >From my reading this indicates that if I sign a license with an IPR holder for Sender-ID and it turns out that it conflicts with the GPL, then I can't make my planned enhancements the Exim MTA and distribute those changes. It would violate the GPL since I cannot confer upon each user that I've distributed my modified version of Exim to the same rights that I had when I obtained my copy of Exim: to modify it and distribute his modifications without restriction. As a email hosting provider and consulting company we were planning on enhancing Exim for this purpose. Though we have traditionally implemented sendmail, we are always looking at our options, as we prefer the GPL. We cannot legally distribute our planned modification of Exim if our customers do not have the same rights as us to distribute the source code as it would violate the GPL. Our resources are limited. If we must talk to a lawyer to determine if we are wrong and this is okay, it would likely kill the project for us. Sure, I could risk it and just implement Sender-ID without signing a license with any Sender-ID IPR holders and distribute my modified version of Exim. Then I would be in full compliance with the GPL (from my reading of Mr. Moglen's statement above), but I'd be at risk of cease-and-desist type legal action from the IPR holders. I believe this is exactly what authors of GPLed mp3 software are risking...that Thomson Multimedia will not pursue them for royalties...a risk that Red Hat, for one, is not willing to take since Thomson made some changes to its web site. Is this WG endorsing this kind of activity? (That is, of course, a rhetorical question.) I think one thing that is being misunderstood by some on this list is that, with respect to the GPL, the end user is absolutely no different than an intermediate developer. By intermediate, I mean someone who modifies and distributes his modified version of someone else's copyrighted, GPL licensed, work. I, as an end user, have the very same rights, without entering into any written contractual agreement with any third party. This patent license eliminates that right I have as an end user of a GPL licensed software package with the 'non-sublicenseable' term alone in 2.1 and 2.2 among other places. This license needs more work to become GPL compatible. The GPL is nowhere near as complex as some would like to make it out to be. And it doesn't take a lawyer to see that the non-sublicenseability, Defensive Suspension, Identification of Licenses and other sections are not compatible with the GPL. Not to pick on Eric Allman too much, but I have to comment on his opening of Sendmail, Inc.'s position as well: "Sendmail, Inc. has worked with Microsoft to help them produce a patent license that will be acceptable for ourselves, the IETF, and the open source community at large." Unfortunately, though Sendmail and Microsoft may agree that this license is acceptable to each other and possible even to the IETF, I think you will find that it is not at all acceptable to the 'open source community' at large, nor, (to be fair to the FSF) to the Free Software movement. I realize that there are many who dislike the GPL and how difficult it makes it for companies who wish continue in this patent cold-war. It is controversial to some, revolutionary to others (myself included), and *blah* to others. I am not posting to debate the relative merits of any license vs. another or any business model vs. another. That is irrelevant. What is relevant is that there are AT LEAST three different MTAs covered by the GPL that will be ghetto-ized by this licenses (those three being Exim, PowerMail, and Courier-MTA). SMTP has been implemented by GPL, BSD, proprietary and other-licensed software with no encumberances for what, two decades, or nearly so? Why should we unfairly push GPLed MTAs out of the market now? I believe we should not. Unequivocally. I think we need to have Eben Moglen or Larry Lessig look at this new modified license and comment, rather than rely on some past comment made by Eben Moglen on a *different* license concerning a technology that wasn't on a standards track (that I know of, anyhow), i.e.: unrelated. But, as we are now in last call, I have to wonder if we really have enough time for that. And that is of NO fault to anyone now posting in opposition to this license. We didn't wait until the last minute...it is Microsoft itself who waited until the last call to post its modified license. We were just waiting until the promised clarification was hand to us. There was no real way to respond until then. And given that no technologies have been declared with specificity over which Microsoft claims it *might* have IPR, I recommend that Sender-ID not be submitted at this time and instead SPF-Classic/SRS be submitted. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 20:41: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 UAA27705 for ; Tue, 24 Aug 2004 20:40: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 i7P0LnSH085968; Tue, 24 Aug 2004 17:21: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 i7P0Lnmc085967; Tue, 24 Aug 2004 17:21:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P0LnpQ085961 for ; Tue, 24 Aug 2004 17:21:49 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7P0LsVr016379; Tue, 24 Aug 2004 17:21:54 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Aug 2004 17:21:54 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mark Shewmaker'" , IETF MARID List Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Tue, 24 Aug 2004 17:21:54 -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'm sorry, but the [L]GPL incompatibility couldn't be more > unambiguous: > > 1. Choice of law restrictions, choice of venue restrictions, > and poison > pills are widely understood to be incompatible with the [L]GPL. The issue for this group is whether the license restrictions are reasonable or not. Compatibility with a specific license is not a requirement, still less compatibility with fanciful interpretations thereof. The language clause in the Patent license only affects the patent license, it does not constrain the choice of law in the license terms of any code. Asking for a professional lawyer to produce a license that does not have a language clause to govern its own interpretation is a ridiculous demand. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 20:59: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 UAA28768 for ; Tue, 24 Aug 2004 20:59: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 i7P0fKQ0087737; Tue, 24 Aug 2004 17:41: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 i7P0fKlX087736; Tue, 24 Aug 2004 17:41:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P0fJ8I087720 for ; Tue, 24 Aug 2004 17:41:19 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7P0oZ4t012674; Tue, 24 Aug 2004 20:50:35 -0400 From: To: "'Hallam-Baker, Phillip'" , "'Chip Mefford'" , "'IETF MARID List'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License Date: Tue, 24 Aug 2004 20:39:43 -0400 Message-ID: <01ad01c48a3c$052072e0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > Sent: Tuesday, August 24, 2004 7:58 PM > To: 'Chip Mefford'; 'IETF MARID List' > Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License > > > > > Nicely put. However, it also does not mean that the copy is > > unencumbered > > either, as this is not strictly stated. This is (among other things) > > wiggle room. > > If there is ambiguity in a contract the interpretation goes against > the party who wrote it. That is why it was essential for Microsoft > to draft this, they don't get the benefit of any wiggle room. Uh, is there a law that I am unaware of, especially one that applies to all countries? > > As a practical matter the empirical definition of law is what a > court rules. Now some complete fools get appointed to the bench > and it is impossible to be sure that there will not be a ridiculous > decision. Which is why the contracts need to be concise. Perhaps Microsoft needs more lawyers so they can make their license concise. But make no mistake, it is NOT sufficiently concise (even if its loosest interpretation was acceptable). > > But consider, what is the likelihood of an adverse decision that > involves damages or an injunction prohibiting distribution against > any party that is not making a claim without granting reciprocal > rights? > Are you citing a precedent? If so, please state. If not are you a lawyer? If neither, what weight does your argument hold? > If an action was taken against any party they can bring themselves > into compliance at any time. Patent disputes cost millions and there > is always a risk that the court proceedings would end with the > patent being declared invalid. Microsoft would not be in a position > to claim loss of revenue. > So if only MS stands to lose, why don't they clarify the license? > As a matter of longstanding IETF precedent a license with a reciprocal > rights clause is the norm. This has never been objected to in > the past. > The idea of a reciprocal grant does not seem to me to be antithetical > to the aims of the GPL, quite the opposite. > Granted. But the license is not concise, and that is the root of the problem. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 21:10:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29748 for ; Tue, 24 Aug 2004 21:10: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 i7P0lhgY088253; Tue, 24 Aug 2004 17:47: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 i7P0lhlj088252; Tue, 24 Aug 2004 17:47:43 -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 i7P0lgjj088246 for ; Tue, 24 Aug 2004 17:47:43 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 2154 invoked from network); 25 Aug 2004 00:49:33 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 25 Aug 2004 00:49:33 -0000 In-Reply-To: <54A0E1AE-F60F-11D8-A96D-000393A56BB6@glyphic.com> References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> <6D296A19-F605-11D8-BD7E-000A95BC6A7E@margaretolson.com> <54A0E1AE-F60F-11D8-A96D-000393A56BB6@glyphic.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <60ABD5DB-F630-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG , Jim Lyon From: Margaret Olson Subject: Re: DEPLOY: DNS Record Types Date: Tue, 24 Aug 2004 20:47:44 -0400 To: Mark Lentczner X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 4:51 PM, Mark Lentczner wrote: > > On Aug 24, 2004, at 12:40 PM, Margaret Olson wrote: > >> As the spec is written, a new reader has to study carefully and work >> this out for themselves. This is not helpful to the email community >> and it will slow down adoption. > > [ This is a little off-topic, but... ] > > If you have a tighter, clearer and more concise way of saying what is > allowed and what must be done, then I'm all ears. I'm going to resist > adding paragraphs of explanation, best practices, expository examples > and helpful hints. > > - Mark Here are my suggested changes, working from Jim Lyon's simplification. The goal is to both moving the world to the new resource record and to allow everyone to be compliant in the very short term. I dislike the idea of having a spec with which most people in fact won't be able to comply. Coupled with the significant forgery/spam reduction incentive of implementing Sender ID the current wording ultimately works against the goals of the DNS folks by making a spec violation "standard practice". 1. Publishers MUST publish using the new SPF2 record type. Change this to SHOULD 2. Publishers MAY also publish using TXT records. Leave as is 3. Consumers MUST do lookups using the new SPF2 record type. Change this to SHOULD 4. Consumers MAY also do lookups using TXT records. Leave as is 5. Consumers MAY do both lookups (3 and 4) in parallel. Leave as is 6. If consumers receive records from both lookups, they SHOULD use the SPF2 record and ignore the TXT record. Change this to MUST, since we want the world to move to the SPF2 record Margaret. From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 21:17: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 VAA00360 for ; Tue, 24 Aug 2004 21:17: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 i7P0qMue088681; Tue, 24 Aug 2004 17:52: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 i7P0qMde088680; Tue, 24 Aug 2004 17:52:22 -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 i7P0qKa7088671 for ; Tue, 24 Aug 2004 17:52:21 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: DEPLOY/IPR: Fundamental Disagreements, or Get On With It X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 24 Aug 2004 19:52:26 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> Thread-Topic: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Thread-Index: AcSKPdstE0zkx7I8SA+HgNjPOfSxzA== 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 i7P0qLa7088675 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit It's quite clear that the GNU/FSF camp in this list will go to full lengths to describe how incompatible Microsoft's IPR claims and licensing requirements are with their precious GPL. It's also clear that Microsoft is not interested in appeasing this group even though Harry, Jim and Bob have gone to extreme lengths to accommodate the not-so-extreme groups (*BSD, APL, MPL, and so forth). Once again a short term memory reveals itself. I seem to remember that the General Public License came about as a direct response to the kind of restrictions the likes of Microsoft, SCO (formerly AT&T UNIX) and their ilk are so fond of imposing on its customers. It has been said that the GPL was intentionally designed to be incompatible with any license that required acknowledgement of IPR, monetary or otherwise. That intentional design of the GPL has lead to arguments in the GNU/Linux community that many of the components that comprise of the typical Linux distribution are inherently incompatible with each other legally. The Apache Group was recently shunned by the FSF because of recent changes in the Apache license, for example. The XFree86 group before that. I remember the heated arguments over KDE vs GNOME and how Mandrake was apparently breaking the law by including KDE with a Red Hat distro. Yet all of these components can and do exist in the typical Linux distro.[1] I am not going to claim Harry and his group are saints in trying to come forward. They have an agenda they can't control. But, by the Goddess, give them some slack for trying! They're never going to appease the FSF high priests so they aren't wasting their time with them, instead focusing on the less fanatical majority of APL, MPL, BSD etc and their lesser priests. No *software* company with an eye towards positive cash flow can afford to release *current* software under the GPL.[2] And the FSF high priests won't accept anything less than seeing Sender-ID released under it. So, in the name of moving on, the FSFers can just give up on these guys and focus their efforts on SPF1, which looks like a better candidate for GPL righteousness. Let the rest of the MARID group finish their work, already. Implementers like myself will decide which to use, or maybe use both. [1] Some have argued that's the reason Linux hasn't reached the desktop in significant numbers yet. That's a discussion for a different forum, however. [2] I say "current" because successful companies have released kit under the GPL, but only long after its shelf life has expired, or if it has no bearing on their cash flow such as hardware sales. I'd like to see some examples that defy this claim, but only in private mail, please. -- 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 Aug 24 22:02: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 WAA03528 for ; Tue, 24 Aug 2004 22:02:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P1ZB7H093943; Tue, 24 Aug 2004 18:35: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 i7P1ZB6L093942; Tue, 24 Aug 2004 18:35:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P1Z9eR093927 for ; Tue, 24 Aug 2004 18:35:10 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7P1Xxrx021654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Aug 2004 21:34:00 -0400 Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It From: Paul Iadonisi To: "IETF MXCOMP (E-mail)" In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> Content-Type: text/plain Message-Id: <1093397620.17943.116.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 24 Aug 2004 21:33:41 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-24 at 20:52, Gordon Fecyk wrote: > It's quite clear that the GNU/FSF camp in this list will go to full lengths > to describe how incompatible Microsoft's IPR claims and licensing > requirements are with their precious GPL. "GNU/FSF camp" people also have business to run. > It's also clear that Microsoft is > not interested in appeasing this group even though Harry, Jim and Bob have > gone to extreme lengths to accommodate the not-so-extreme groups (*BSD, APL, > MPL, and so forth). I, at least, never criticized them for trying. I know full well that individually they do not control what Microsoft does. But they are the ones on this list, so any feedback on this license goes to them, and appropriately so. > Once again a short term memory reveals itself. I seem to remember that the > General Public License came about as a direct response to the kind of > restrictions the likes of Microsoft, SCO (formerly AT&T UNIX) and their ilk > are so fond of imposing on its customers. It has been said that the GPL was > intentionally designed to be incompatible with any license that required > acknowledgement of IPR, monetary or otherwise. Irrelevant, and at least with respect to the 'monetary' part, untrue. > That intentional design of the GPL has lead to arguments in the GNU/Linux > community that many of the components that comprise of the typical Linux > distribution are inherently incompatible with each other legally. The Apache > Group was recently shunned by the FSF because of recent changes in the Apache > license, for example. The XFree86 group before that. I remember the heated > arguments over KDE vs GNOME and how Mandrake was apparently breaking the law > by including KDE with a Red Hat distro. Yet all of these components can and > do exist in the typical Linux distro.[1] Aside from the fact that you've misrepresented every event in the preceding paragraph, how is this relevant? > I am not going to claim Harry and his group are saints in trying to come > forward. They have an agenda they can't control. But, by the Goddess, give > them some slack for trying! They're never going to appease the FSF high > priests so they aren't wasting their time with them, instead focusing on the > less fanatical majority of APL, MPL, BSD etc and their lesser priests. Giving them slack does not mean acquiescing to an unacceptable patent license. And I do hope that by 'high priests' you are not referring to me or others who have posted valid concerns regarding this license without resorting to ad hominem attacks like calling them high priests of anything. I don't deny that I'm an a GPL advocate and proud of it. That's clear from my signature. But it is not relevant except inasmuch as it effects my business and my ability to implement this standard. > No *software* company with an eye towards positive cash flow can afford to > release *current* software under the GPL.[2] And the FSF high priests won't > accept anything less than seeing Sender-ID released under it. So, in the > name of moving on, the FSFers can just give up on these guys and focus their > efforts on SPF1, which looks like a better candidate for GPL righteousness. > Let the rest of the MARID group finish their work, already. Implementers > like myself will decide which to use, or maybe use both. More vitriol and again largely irrelevant discussion about business models. No one is asking Microsoft or anyone else to release *current software* or any software under the GPL. Only that we be allowed to write or modify GPL software to support whatever standard this WG comes up with. The patent license in its current form does not permit this. Giving up is not an option in this particular case because this is a *standards* process, not a mere discussion on whether or not one business model is better than another or one license is better than another. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 22:07: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 WAA04086 for ; Tue, 24 Aug 2004 22:07: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 i7P1jnSH095024; Tue, 24 Aug 2004 18:45:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P1jnM6095023; Tue, 24 Aug 2004 18:45:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P1jmdO095015 for ; Tue, 24 Aug 2004 18:45:48 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i7P1jo3V002815 for ; Tue, 24 Aug 2004 18:45:50 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 25BC384F866; Tue, 24 Aug 2004 18:45:50 -0700 (PDT) Date: Tue, 24 Aug 2004 18:45:50 -0700 From: "Mark C. Langston" To: "IETF MXCOMP (E-mail)" Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Message-ID: <20040825014550.GN41046@bitshift.org> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> User-Agent: Mutt/1.4.1i X-Uptime: 6:32PM up 71 days, 2:38, 7 users, load averages: 0.03, 0.07, 0.07 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 07:52:26PM -0500, Gordon Fecyk wrote: > > It's quite clear that the GNU/FSF camp in this list will go to full lengths > to describe how incompatible Microsoft's IPR claims and licensing > requirements are with their precious GPL. Excuse me, but I license my software using the BSD license. I still have a problem with the IPR claims and licensing requirements as posted by Mr. Katz. I think it's quite rude (your tone notwithstanding, which I also find rather rude in this post) to simply wave your hand and attempt to dismiss these concerns. The fundamental issue here is adoption, and the people who are likely to adopt or dismiss this particular implementation are trying to say that they're leaning towards dismissing it due to the IPR claims and licensing requirements. Further, they're trying to say that they're worried about how these unspecified IPR claims in the undisclosed patent filings may impact non-Sender-ID SPF implementations. Trying to paint the entire Free and Open Source Software movement as fringe extremists and then dismissing their concerns is a straw man of the worst sort. I write software. I'm sufficiently confused and concerned about the licensing terms and encumbrance of the Microsoft claims that I cannot be comfortable implementing Sender-ID. And I should not need to consult a lawyer just to understand my liabilities should I do so. Nonetheless, proceed apace. We'll route around if needs be. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Tue Aug 24 23: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 XAA08884 for ; Tue, 24 Aug 2004 23: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 i7P36nAC003776; Tue, 24 Aug 2004 20:06:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P36nss003775; Tue, 24 Aug 2004 20:06:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from frontend1.messagingengine.com (frontend1.messagingengine.com [66.111.4.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P36mrd003762 for ; Tue, 24 Aug 2004 20:06:48 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: IyJR23IUjn9NLi5KDuwAVQ 1093403209 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend1.messagingengine.com (Postfix) with ESMTP id 66AEFC14B60; Tue, 24 Aug 2004 23:06:49 -0400 (EDT) Message-ID: <412C0210.8090503@elvey.com> Date: Tue, 24 Aug 2004 20:05:52 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: DEPLOY - IP, HELO & touch count. DOC-BUG too. References: <20B59876-F514-11D8-8FE8-000A95B3BA44@hxr.us> In-Reply-To: <20B59876-F514-11D8-8FE8-000A95B3BA44@hxr.us> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit There are some problematic issues regarding my possible Sender ID deployment that I'd like to (re-)raise. I wish I had more time to research and polish this post and participate more, but I'm leaving for nearly 2 weeks tomorrow AM. My second and third points are more or less 'me too' comments, but my first one is extremely important and underexposed. 1)A good fraction (I'd estimate 1/2) of my end users have their MTAs configured to send through several SMTP servers, using different From:'s. (I send through several, myself. About 1/4 of my users have more than one MTA.) We will have to somehow discover each of my users SMTP configurations, the Sender ID configurations for the From:'s they use, and figure out if there's a way for them to continue to use those From:'s, and walk them through configuring their MTAs to use the SMTP servers that will allow them to use those From:'s. If Sender ID had embraced Unified SPF, in particular: a mandatory HELO check, the checks on HELO would be able to tie to a reputation often enough that an end user using an SMTP server not authorized for their From: would be an occasional issue, instead of an overwhelming support issue. The SMTP servers used by my end users would have good enough reputations that the PRA check would be unnecessary, and the message would get through even if the server didn't support SUBMITTER and was used by a mobile/guest user using their usual domain. The PRA checks would not fail because they would not be run. Setting up user.[remote|mobile]-users (the example of which I'm unable to grok) won't be necessary. I have made these points before; see http://asrg.sp.am/wiki?Client_SMTP_Validation#Advocacy . This change (a mandatory HELO check) would make MARID work well with ORDERS OF MAGNITUDE less work. I was expecting to see this change in this proposal set, as it seemed to meet with little resistance, and was in Unified SPF, and getting serious support from key players. I wonder if folks are happy to make it close to mandatory for everyone to upgrade their MTAs. (In addition, Sender ID appears to require that all _MUAs_ be updated to show the PRA, for full effectiveness.) No real downside to mandatory HELO checks (using the pass/fail/continue logic of Unified SPF) has been presented to date. Phrased differently: Sender ID fails to be a solution that only requires sysadmin action; it mandates end-user reconfiguration on a massive scale, because, IIRC, it doesn't say that HELO checking should/must be done. Hence I (of elvey.com) would have to get all my domain's end users to use MSAs that I (as DNS admin of elvey.com) knew about. For fastmail.fm, my email provider, who hosts mail for thousands of domains, they would have to support this for each user of each domain!) If HELO checking is mandatory, they just send HELO fastmail.fm, and ensure that fastmail.fm has a good reputation. 2)IP. The Microsoft IP is encumbered, therefore, as others pointed out in threads like "DEPLOY: Microsoft Patent license unworkable with GPLed MTAs", I'll have trouble using, e.g. debian and Sender ID. Microsoft has belligerently refused to make the changes that it has been made clear are a problem. I say belligerently not to poke at Microsoft, but because their statement in Q7 of their Sender ID IP FAQ is belligerent. It's been said that only individuals are members of the IETF, and that is certainly true, but that in NO way implies that an individual who is paid by and managed by a company to participate in the IETF must not be considered to represent that company; no IETF policy suggests that the interests of an individual's employer are not relevant to discussion. 3)DDoS vulnerability. (~-protocol, Section 6.2) I find the spec acceptable as is in this regard, but think it could be improved. 10 evaluations of check_host() could result in >> 100 DNS queries, a significant amplification, yes? I think the DNS queries are the expensive part of the calculation, and the limit should be on the # of DNS queries. =-=-=-=--=-= Another TYPO in -protocol-02 s/than one strings./than one string./ I like the way that the wildcard and TXT RR situations have been handled. The Sender ID drafts have come a long way (I considered them hopeless when I first read 'em and almost didn't send in my suggestions!) but there's a ways to go. Out of time. Thanks for reading. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 02:15: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 CAA02317 for ; Wed, 25 Aug 2004 02:15:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P5pP7C018705; Tue, 24 Aug 2004 22:51: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 i7P5pPIL018704; Tue, 24 Aug 2004 22:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P5pOqM018697 for ; Tue, 24 Aug 2004 22:51:25 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040825055131.FSUJ18869.tomts5-srv.bellnexxia.net@ibmrkydk2ufvdd> for ; Wed, 25 Aug 2004 01:51:31 -0400 From: "John Glube" To: "'IETF MARID WG'" Subject: TECH OMISSION: Stronger checks against email forgery Date: Wed, 25 Aug 2004 01:51:16 -0400 Message-ID: <00d401c48a67$895d6380$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8899A2@df-fido-msg.exchange.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7P5pPqM018698 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit It is very easy to forge domain information in email. Two simple cases: * Forging the SMTP mail from address; and * Inserting a false received line or resent-from header. In essence this involves using someone else's domain without consent. Also, many who forge domain information also apparently send direct from an IP address to the recipient's mail server. Shouldn't we have stronger checks to prevent these types of activities? One approach is to run a mail from check at the data stage using the SPF record format and test protocol. Another is to run an ehelo or helo check using client smtp validation. Keep in mind those engaged in email forgery (which for sophisticated operators is a form of criminal fraud) will likely adopt approaches to muddy and defeat authentication, so that those engaged in fighting email forgery will need to use a range of tools, recognizing that although one data set might be corrupted, matching of data against a number of identifiers will likely generate better results. (I am basing these general comments on existing research and studies carried out by others in the criminal forensics field.) Amending the Sender-ID drafts to reflect using a number of data sets is one option. My personal recommendation is that a best current practices document be published concurrently with any authentication technologies recommended by this WG which would in essence recommend receivers run PRA checks using Sender-ID: Authenticating Email, mail from checks using the SPF record format and test protocol and ehelo/helo checks using client smtp validation. It may also be appropriate to establish a steering group to review and propose document updates on a regular basis, although there may be other ad hoc groups which could include this process within their mandate. 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.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 04:02: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 EAA22129 for ; Wed, 25 Aug 2004 04:02: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 i7P7gXtL033007; Wed, 25 Aug 2004 00:42:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P7gX25033005; Wed, 25 Aug 2004 00:42:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P7gUGu032950 for ; Wed, 25 Aug 2004 00:42:32 -0700 (PDT) (envelope-from roy@dnss.ec) Received: by mail.schlyter.se (Postfix, from userid 2038) id D7172AC8B; Wed, 25 Aug 2004 09:42:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id D5E32AC8A; Wed, 25 Aug 2004 09:42:25 +0200 (CEST) Date: Wed, 25 Aug 2004 09:42:25 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Harry Katz Cc: IETF MARID List Subject: RE: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination 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 Tue, 24 Aug 2004, Harry Katz wrote: > On Tuesday, August 24, 2004 12:36 AM, Roy Arends wrote: > > > What I'm concerned about is that licensing of technology > > developed and published through the IETF sets a precedent. > > We'll be drifting from the mudpool to the quicksand. > > There are dozens and dozens of IETF specifications that have associated > IPR claims. Please refer to http://www.ietf.org/ipr.html for a current > list. I should be more clear. I implied "This specific type of license where I need to contact company X or Y to get a license when I distribute source code that includes an IETF standard". > In fact this "precedent" has long been established and, as I understand > it, deliberately so in order to encourage organizations to contribue > their IPR to standards efforts. Thanks for the handwave, but the specific license in question does create a precedent. Roy From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 04:35:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24845 for ; Wed, 25 Aug 2004 04:35:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P89Hbu038123; Wed, 25 Aug 2004 01:09: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 i7P89H8o038122; Wed, 25 Aug 2004 01:09:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P89GS3038107 for ; Wed, 25 Aug 2004 01:09:17 -0700 (PDT) (envelope-from SRS0=Y4IXaMyF=LP=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7P89Gt2073438 for ; Wed, 25 Aug 2004 10:09:16 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408250809.I7P89FMQ073427@asarian-host.net> Date: Wed, 25 Aug 2004 08:09:16 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages X-Trace: TX2lNI4dZh3oQfWXIYc1P3ZK1v3D2iOJzEQITDxdc0g4X7cyo4rc57AG7CzsRqDCTro7xGxoi2gmzYSisrYZug== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQSxJLDFqW1BleBN9AQGCuwf+NeMVhM67p67ZB71eA8+4ynhip7oaR4Q5 28tYWqLDYXAo3O/0pjmg3wK6n7LadZBt+c3T6Y9rb0dDyGF7EjZERgd0WBWyezx6 LweFMU2vs8dyqwrWUhd5q4aM3Pvzwn235c/TBnlHVHFqXSob+81ZVm3fHccrZ5Bb UOUjpmzbnDr072y+MLANDc7Dgz4SP2oreobHqnKr/boN0X2DcB2uwJXKKHJhRq1F wOrfhEX98CLRxJMtQaEcNShHiMiGQWYLzqW62vWgu9QaV2oBRJx9SmfRai9Kh2YP 5F82BC/BWjfFUrhH4UgWqlaaUaS/jj/KJtmEZF/W4q1v0eukhq6MtQ== =Nkse Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jim Lyon wrote: > A reasonable use of SenderID is to use it at SMTP time, and to refuse > to accept forged mail. If you refuse to accept it (by giving an > error at end of DATA), you won't generate a bounce. The MTA that was > sending the mail might or might not generate a bounce, but that's his > problem, not yours. I am coming out of delurk for a moment. But could someone please explain why we are having this discussion? I mean, rejecting with a 5.x SMTP error code, based on whatever criteria, creates neither less, nor more liability, than doing so, also for whatever reasons, has done for the last few decades. There is, from the perspective of the sender at SMTP level, nothing fundamentally different between, say, being rejected based on an entry in the access database, and being rejected based on something found, or not found, in the headers. Though I will carefully avoid saying people are "wrong" (what, with me not having enough "standing" for that, and all; lol), I presume I am allowed to *agree*, right? :) So, I agree with Jim. To say anything else, IMHO, is really tantamount to defending the position that sending any 5.x code potentially sets you up for legal liability. Which brings me full-circle: it may or may not, but not more so, or less, than doing so for the last few decades has done. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 05:31: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 FAA27378 for ; Wed, 25 Aug 2004 05:31: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 i7P95agB053944; Wed, 25 Aug 2004 02:05: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 i7P95aFd053943; Wed, 25 Aug 2004 02:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P95RLB053892 for ; Wed, 25 Aug 2004 02:05:36 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id AA88F94015; Wed, 25 Aug 2004 11:05:38 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id EC74394017; Wed, 25 Aug 2004 11:05:37 +0200 (CEST) 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 i7P95bvm1492838; Wed, 25 Aug 2004 11:05:37 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id C3847102C1; Wed, 25 Aug 2004 11:05:37 +0200 (CEST) Date: Wed, 25 Aug 2004 11:05:37 +0200 From: Stephane Bortzmeyer To: George Mitchell Cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Message-ID: <20040825090537.GC26018@nic.fr> References: <20040824165210.GB13538@metro.cx> <200408242101.i7OL1llP001114@m5p.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408242101.i7OL1llP001114@m5p.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [Shifting from the legal and political issue...] On Tue, Aug 24, 2004 at 02:01:47PM -0700, George Mitchell wrote a message of 61 lines which said: > * SPF+SRS is embodied in working code. (Two widely publicized > implementations, and there are probably others.) > * SPF+SRS is deployed. > * SPF+SRS is not encumbered by any intellectual property claims. SPF is coded and deployed. SRS is much less common (IMHO the SUBMITTER extension could make SRS unnecessary). From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 05:31: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 FAA27396 for ; Wed, 25 Aug 2004 05:31: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 i7P99S7g055188; Wed, 25 Aug 2004 02:09: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 i7P99SJV055187; Wed, 25 Aug 2004 02:09:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P99R7i055175 for ; Wed, 25 Aug 2004 02:09:27 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1BztmU-0008CN-00; Wed, 25 Aug 2004 10:09:22 +0100 Message-ID: <0b7101c48a82$e95d3d80$0200000a@ringo> From: "Chris Haynes" To: "Jim Lyon" Cc: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF8898F3@df-fido-msg.exchange.corp.microsoft.com> Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages Date: Wed, 25 Aug 2004 10:07:11 +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 "Jim Lyon" opined: > > Chris, > > You're between a rock and a hard place. If you simultaneously believe > that all of the following are sinful: > > 1. To accept and deliver forged mail. > 2. To accept forged mail and silently discard it. > 3. To accept forged mail and then generate a bounce. > 4. To reject forged mail because the sender might generate a bounce. > > then you have no alternatives left. Actually I was advocating (2) - but only in the special case when the Mail-From entity has declined responsibility for the message by causing a test 'fail'. We need to have SPF_Classic+SRS or an equivalent 'on the table' so that the experts can explain to you why a (2) can be justified following a Mail-From test, but not following a PRA test. > > The current drafts give you a way to avoid (1) -- that's their whole > point. They leave it as a local policy decision as to which of 2, 3 or > 4 you choose. They recommend (4) with a "SHOULD", but you can > reasonably do either of the others. > > Today, many large ISPs silently discard mail that they classify as spam. > I expect that those ISPs will choose (2) when implementing SenderID. > Woah! Home on there! There's a new, really serious point here. You claim in (2) that the drafts give authority for MTAs to silently discard messages. I cannot find that authority in the drafts. There is an absolutely critical, overriding requirement imposed on all components of SMTP systems by RFC2821. I quote from section 2.1 ".. message transfer can occur in a single connection between the original SMTP-sender and the final SMTP-recipient, or can occur in a series of hops through intermediary systems. In either case, a formal handoff of responsibility for the message occurs: the protocol requires that a server accept responsibility for either delivering a message or properly reporting the failure to do so." This is fundamental to SMTPs' ability to provide a reliable service. Now -core-03.txt, section 5.3 says that on failure a server 'SHOULD reject the message' using a 550 method. That conforms to RFC2821. But what alternative actions are available? I had assumed that the alternative, should the advice not be heeded, would be to continue to process the message in some way - still in conformity with the RFC2821 requirement to 'deliver or report'. I hope you are wrong in your assertion in (2) that the -core draft authorises the silent discarding of messages. If the drafts do conform to RFC2821, then the technical assertions backing this entire thread, and justifying my inability to deploy Sender-ID remain unchallenged. If these drafts do permit the silent discard of messages on the basis of a PRA test failure as a 'local policy decision', as you suggest, that would be grounds for a significant TECH-ERROR submission: Sender-ID would be breaking the general requirement imposed by RFC2821. Where do the drafts authorise or advocate the silent discarding of messages? > Your thoughts about MAIL-FROM, HELO and EHLO don't change the above > calculus at all. They merely change the details of which messages you > classify as forged. > No. not 'merely'. The repudiation of a message by its envelope sender (Mail-From entity) has an entirely different significance in the context of RFC2821 than repudiation of its content by a PRA test. We need SPF_Classic+SRS, or an equivalent, on the table for this sub-debate to be continued. > -- Jim Lyon > > > Chris Haynes From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 05: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 FAA29653 for ; Wed, 25 Aug 2004 05: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 i7P9VP8Q061691; Wed, 25 Aug 2004 02:31: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 i7P9VPOn061690; Wed, 25 Aug 2004 02:31:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P9VOYQ061672 for ; Wed, 25 Aug 2004 02:31:25 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1Bzu7h-000Itz-00; Wed, 25 Aug 2004 10:31:17 +0100 Message-ID: <0b7501c48a85$f9678110$0200000a@ringo> From: "Chris Haynes" To: "Mark" Cc: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> <200408250809.I7P89FMQ073427@asarian-host.net> Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages Date: Wed, 25 Aug 2004 10:29:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "Mark" asked: > > I am coming out of delurk for a moment. But could someone please explain why > we are having this discussion? I mean, rejecting with a 5.x SMTP error code, > based on whatever criteria, creates neither less, nor more liability, than > doing so, also for whatever reasons, has done for the last few decades. > There is, from the perspective of the sender at SMTP level, nothing > fundamentally different between, say, being rejected based on an entry in > the access database, and being rejected based on something found, or not > found, in the headers. We are having this discussion because I assert that the introduction of a forgery test IS fundamentally new. In accordance with the process defined by the Chairs I am explaining _my_ inability to deploy Sender-ID. Some have attempted to show me that the technical basis for my concern is unfounded. That is a really valuable process to go through - but so far no one has convinced me that I have misunderstood the technical situation. Using Sender-ID you can achieve a state where the authority who was purported to be responsible for a message can tell you categorically "That message is a forgery." You then proceed to cause a bounce to be sent to a recipient defined in a message you _know_ to have been repudiated. "Why", the courts may well ask, "did you send a message, known to you to be forged and potentially carrying malicious content, to this innocent child?" See the early parts of the thread for the potential consequences of this totally new situation. Ignore the uninvited forays into the peculiarities of English law - they are irrelevant to this thread. The conclusions on potential legal consequences are necessarily mine and mine alone. Chris From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 06:36:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02128 for ; Wed, 25 Aug 2004 06:36: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 i7PA9g3K073341; Wed, 25 Aug 2004 03:09: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 i7PA9g3l073340; Wed, 25 Aug 2004 03:09:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PA9fEN073330 for ; Wed, 25 Aug 2004 03:09:41 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 3B22094014; Wed, 25 Aug 2004 12:09:53 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 5E23494017; Wed, 25 Aug 2004 12:09:52 +0200 (CEST) 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 i7PA9qvm1506467; Wed, 25 Aug 2004 12:09:52 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 38EE4102C1; Wed, 25 Aug 2004 12:09:52 +0200 (CEST) Date: Wed, 25 Aug 2004 12:09:52 +0200 From: Stephane Bortzmeyer To: Harry Katz , stdsreq@microsoft.com Cc: IETF MARID List Subject: Microsoft (lack of) replies (Was: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Message-ID: <20040825100952.GA31087@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 11:34:48AM -0700, Harry Katz wrote a message of 30 lines which said: > Mark, if there's a specific part of the license you'd like > clarified, I'd encourage you to send mail to stdsreq@microsoft.com. > Someone from our legal department will answer your question. This is not what I see. I have sent several questions to stdsreq@microsoft.com. I believe they were polite (anyone in MARID can check, I copied the mailing list) and that the english was not too catastrophic. I did not get a reply, neither did MARID. Now, in most cases, no reply after 24 h is not a problem. People have more important things to do than to reply to my mail. But, here, we have a decision to make in the next ten days. So, what is the reason: 1) Lack of understanding that there is a relative emergency? 2) [Suggested by Arnt Gulbrandsen] Things take a long time at big companies. But isn't Microsoft advertise itself as an "agile company"? 3) Deliberate despise? 4) The reponse will come, just wait a few more days. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 06:38:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02227 for ; Wed, 25 Aug 2004 06:38:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PACxnD074432; Wed, 25 Aug 2004 03:12: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 i7PACx94074431; Wed, 25 Aug 2004 03:12:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PACwVp074425 for ; Wed, 25 Aug 2004 03:12:58 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 7215394017; Wed, 25 Aug 2004 12:13:10 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx1.nic.fr (Postfix) with ESMTP id 9CFAE94016; Wed, 25 Aug 2004 12:13:09 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7PAD9ig637981; Wed, 25 Aug 2004 12:13:09 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id DC6A8102C1; Wed, 25 Aug 2004 12:13:08 +0200 (CEST) Date: Wed, 25 Aug 2004 12:13:08 +0200 From: Stephane Bortzmeyer To: Andrew Newton Cc: Graham Murray , ietf-mxcomp@imc.org Subject: Re: DEPLOY - IPR on Sender-ID not sufficiently disclosed Message-ID: <20040825101308.GB31087@nic.fr> References: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EA94BF2-F5F8-11D8-9196-000A95B3BA44@hxr.us> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 02:05:02PM -0400, Andrew Newton wrote a message of 12 lines which said: > >The licence terms have been disclosed, but > >insufficient (almost no) information has been given on what the > >claimed IPR covers. > > Please reread: > http://www.imc.org/ietf-mxcomp/mail-archive/msg03495.html I reread it for the third time and I still do not find: * where to get the patents we talk about (*). What do they contain, exactly? * what parts of -core are covered (assuming that all of -pra is covered)? I asked the same questions to stdsreq@microsoft.com without any result so far. Patents are available online, for instance http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,775,781.WKU.&OS=PN/6,775,781&RS=PN/6,775,781 is a patent by Microsoft which covers programs like sudo on Unix. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 06:44:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02570 for ; Wed, 25 Aug 2004 06:44:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAHHRP075305; Wed, 25 Aug 2004 03:17: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 i7PAHHq2075304; Wed, 25 Aug 2004 03:17:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAHHkf075298 for ; Wed, 25 Aug 2004 03:17:17 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 25BFB94015; Wed, 25 Aug 2004 12:17:29 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 54CDC94014; Wed, 25 Aug 2004 12:17:28 +0200 (CEST) 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 i7PAHSvm1507905; Wed, 25 Aug 2004 12:17:28 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 1CB26102C1; Wed, 25 Aug 2004 12:17:28 +0200 (CEST) Date: Wed, 25 Aug 2004 12:17:28 +0200 From: Stephane Bortzmeyer To: John Glube Cc: "'IETF MARID WG'" Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages Message-ID: <20040825101728.GC31087@nic.fr> References: <81AC085044D04B429F5FB883D94FA1AF8898E3@df-fido-msg.exchange.corp.microsoft.com> <00ce01c48a29$d0c9b9f0$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ce01c48a29$d0c9b9f0$6c62fea9@ibmrkydk2ufvdd> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 06:29:27PM -0400, John Glube wrote a message of 146 lines which said: > > 3. Is an SMTP client authorized to use a particular > >email address in an SMTP "MAIL FROM:" command? ... > >If people want the MAIL FROM to play a role in Sender ID, > >they should say so. If they do not say so, the working > >assumption is that nobody cares. ... > These messages reflect the deployment issues I am raising > with marid-protocol/marid-core and which remain outstanding. Is it unrealistic to assume that, if the current Sender-ID becomes a RFC as it is, nevertheless, some people will use SPF records (as specified in -protocol) to perform checks on the 2821 MAIL FROM and not only on the official PRA? A sort of unofficial "Unified SPF"? From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 07:00: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 HAA03981 for ; Wed, 25 Aug 2004 07: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 i7PAWbcd078408; Wed, 25 Aug 2004 03:32: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 i7PAWb4A078407; Wed, 25 Aug 2004 03:32:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAWbN4078394 for ; Wed, 25 Aug 2004 03:32:37 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 1C8A494013 for ; Wed, 25 Aug 2004 12:32:49 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 59CAC94004 for ; Wed, 25 Aug 2004 12:32:48 +0200 (CEST) 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 i7PAWmvm1510660 for ; Wed, 25 Aug 2004 12:32:48 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 42142102C1; Wed, 25 Aug 2004 12:32:48 +0200 (CEST) Date: Wed, 25 Aug 2004 12:32:48 +0200 From: Stephane Bortzmeyer To: "IETF MXCOMP (E-mail)" Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Message-ID: <20040825103248.GD31087@nic.fr> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 07:52:26PM -0500, Gordon Fecyk wrote a message of 50 lines which said: > their precious GPL. ... > the FSF high priests ... > less fanatical majority If people start using such terms in the discussion, and if the chairs do not step in like they do when people criticize Microsoft or software patents, language will soon degenerate and words like "Servant of Evil", "Valet of Microsoft", "Dishonest Monopolist" or "Greedy Filthy Capitalist" will soon start to appear. You have been warned :-) From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 07: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 HAA05202 for ; Wed, 25 Aug 2004 07:08: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 i7PAlUD5082047; Wed, 25 Aug 2004 03: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 i7PAlUIL082046; Wed, 25 Aug 2004 03:47:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAlTJt082038 for ; Wed, 25 Aug 2004 03:47:30 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 0076394013; Wed, 25 Aug 2004 12:47:42 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 2500F94004; Wed, 25 Aug 2004 12:47:41 +0200 (CEST) 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 i7PAlfvm1513068; Wed, 25 Aug 2004 12:47:41 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 07088102C1; Wed, 25 Aug 2004 12:47:41 +0200 (CEST) Date: Wed, 25 Aug 2004 12:47:41 +0200 From: Stephane Bortzmeyer To: Chris Haynes Cc: IETF MARID WG Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages Message-ID: <20040825104741.GA1605@nic.fr> References: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> <200408250809.I7P89FMQ073427@asarian-host.net> <0b7501c48a85$f9678110$0200000a@ringo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b7501c48a85$f9678110$0200000a@ringo> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 10:29:06AM +0100, Chris Haynes wrote a message of 48 lines which said: > We are having this discussion because I assert that the introduction > of a forgery test IS fundamentally new. Introduction of a *standard* forgery test is new. But people have been testing incoming SMTP clients or incoming SMTP transactions or incoming email messages for years. Often, these tests are quite ill-advised (refusing mail from machines without a PTR, for instance). But they exist and the bounces generated by these tests have never created legal problems. > "Why", the courts may well ask, "did you send a message, known to > you to be forged and potentially carrying malicious content, to this > innocent child?" You did not send it. The MTA just before you did and it was the faulty one, for having *not* performed SenderID tests. To me, this is the most important thing against your idea: you do not send the bounce, someone else does. Yes, your action (refusing the mail with 5xx) was indirectly the cause of the bounce. But (IANAL) I do not think it can be regarded as a liability. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 07:16: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 HAA05863 for ; Wed, 25 Aug 2004 07:16:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAr5qx083233; Wed, 25 Aug 2004 03:53: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 i7PAr5GZ083232; Wed, 25 Aug 2004 03:53:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAr5EL083226 for ; Wed, 25 Aug 2004 03:53:05 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 7071594013; Wed, 25 Aug 2004 12:53:17 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx1.nic.fr (Postfix) with ESMTP id 983F794004; Wed, 25 Aug 2004 12:53:16 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7PArGig620560; Wed, 25 Aug 2004 12:53:16 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 5D5E9102C1; Wed, 25 Aug 2004 12:53:16 +0200 (CEST) Date: Wed, 25 Aug 2004 12:53:16 +0200 From: Stephane Bortzmeyer To: "Hallam-Baker, Phillip" Cc: IETF MARID List Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Message-ID: <20040825105316.GA2670@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 05:21:54PM -0700, Hallam-Baker, Phillip wrote a message of 21 lines which said: > Compatibility with a specific license is not a requirement, You're right, I do not think we can find somewhere in the IETF documents such a requirment. But a licence which is incompatible with *every* free software licence, while acceptable if you follow IETF rules by the book, would be in practice ignored and never deployed, which is certainly not MARID's goal. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 08:14: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 IAA09376 for ; Wed, 25 Aug 2004 08:14: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 i7PBn15f095739; Wed, 25 Aug 2004 04:49: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 i7PBn1aE095738; Wed, 25 Aug 2004 04:49:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBmxjR095684 for ; Wed, 25 Aug 2004 04:49:00 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7PBmpsm013607 for ; Wed, 25 Aug 2004 12:48:51 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7PBmp7u013606; Wed, 25 Aug 2004 12:48:51 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages References: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> <200408250809.I7P89FMQ073427@asarian-host.net> <0b7501c48a85$f9678110$0200000a@ringo> <20040825104741.GA1605@nic.fr> From: Graham Murray Date: Wed, 25 Aug 2004 12:48:51 +0100 In-Reply-To: <20040825104741.GA1605@nic.fr> (Stephane Bortzmeyer's message of "Wed, 25 Aug 2004 12:47:41 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephane Bortzmeyer writes: > You did not send it. The MTA just before you did and it was the faulty > one, for having *not* performed SenderID tests. To me, this is the > most important thing against your idea: you do not send the bounce, > someone else does. > > Yes, your action (refusing the mail with 5xx) was indirectly the cause > of the bounce. But (IANAL) I do not think it can be regarded as a > liability. But what would be completely unacceptable would be for the SMTP transaction to accept a mail, perform (either at SMTP time or subsequently) Sender-ID (or SPF, Domainkeys, or other) checks which show the mail to be a forgery and then send a bounce (to the known forged address) for any reason. I believe that, unfortunately, some MTAs do accept all emails and only subsequently check that the recipient mailbox is valid, not over quota, that the email does not contain a virus etc, and send a bounce if these checks fail. The operators of such MTAs might find themselves with more legal liability if they generate bounces to addresses which Sender-ID etc show to be forgeries. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 08:55: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 IAA11441 for ; Wed, 25 Aug 2004 08:55: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 i7PCOtp2005117; Wed, 25 Aug 2004 05: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 i7PCOtE2005116; Wed, 25 Aug 2004 05:24:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PCOj40005067 for ; Wed, 25 Aug 2004 05:24:54 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 7251394013; Wed, 25 Aug 2004 14:24:59 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx1.nic.fr (Postfix) with ESMTP id CD5C894004; Wed, 25 Aug 2004 14:24:58 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7PCOwig586314; Wed, 25 Aug 2004 14:24:58 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id A4A14102C1; Wed, 25 Aug 2004 14:24:58 +0200 (CEST) Date: Wed, 25 Aug 2004 14:24:58 +0200 From: Stephane Bortzmeyer To: Graham Murray Cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages Message-ID: <20040825122458.GA8223@nic.fr> References: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> <200408250809.I7P89FMQ073427@asarian-host.net> <0b7501c48a85$f9678110$0200000a@ringo> <20040825104741.GA1605@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 12:48:51PM +0100, Graham Murray wrote a message of 23 lines which said: > But what would be completely unacceptable would be for the SMTP > transaction to accept a mail, perform (either at SMTP time or > subsequently) Sender-ID (or SPF, Domainkeys, or other) checks which > show the mail to be a forgery and then send a bounce (to the known > forged address) for any reason. I agree. It would be completely unacceptable. Almost every anti-virus server software in use does it, nevertheless :-) > I believe that, unfortunately, some MTAs do accept all emails and > only subsequently check that the recipient mailbox is valid, Postfix does it by default. Also, every MTA does it if you have a front-end MTA in the DMZ which accepts everything before giving it to the "real" MTA. So, these "late bounces" are a fact of life and we have to live with it. Giving the amount of bounces I already receive for mail which I've never sent (and this is before Sender-ID deployment), I have little sympathy for Chris Haynes' concerns. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 09:21: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 JAA12971 for ; Wed, 25 Aug 2004 09:21:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PCwI7N011222; Wed, 25 Aug 2004 05:58: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 i7PCwIRh011221; Wed, 25 Aug 2004 05:58:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PCwHLP011209 for ; Wed, 25 Aug 2004 05:58:17 -0700 (PDT) (envelope-from SRS0=Y4IXaMyF=LP=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7PCwGgf079733 for ; Wed, 25 Aug 2004 14:58:16 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408251258.I7PCWGRA079723@asarian-host.net> Date: Wed, 25 Aug 2004 12:58:16 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages X-Trace: x6vIA+AKYSowdAANSJtD6890T1d1lo4P/qWCM/2DfNCoKBZmKnc2XgJhUOVJqjlux++wgI+fai4U+IWEWchwtQ== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: References: <81AC085044D04B429F5FB883D94FA1AF88982F@df-fido-msg.exchange.corp.microsoft.com> <200408250809.I7P89FMQ073427@asarian-host.net> <0b7501c48a85$f9678110$0200000a@ringo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQSyM6DFqW1BleBN9AQFH7Af+JL3YtpKEj7BFfJM0Cub0KXXXb1vJojDa oXzzcpAumhECA5BXu8el8/NfelAiekAjbVDsXLIAQpfq5vjCwFoxdGxAoJGW9/Ns cmZVLg430vlb1AJH1IeQ66FFm7COGqRMFfEgfZArkQFZtYD2jRcBvmN+WLTTpQ3A ZIuZmMKQ5V3SxvbUbySGWiv5R1ah7pOgZcZWrjTevh8YpRRNNqqCzzG/pyHuO69I mWZKpOhLR+FuD3nSDgLVQT3Px2+GfKcpJW1hywve1v3ycHTC+u4OPypl+LjAKQ18 vKu3FbSx49oqEsxmtEEn3cSCC9Z8gPTf9Ai8XEGNtQP7FROeq37c0w== =7fja Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Chris Haynes wrote: >> I am coming out of delurk for a moment. But could someone please >> explain why we are having this discussion? I mean, rejecting with a >> 5.x SMTP error code, based on whatever criteria, creates neither >> less, nor more liability, than doing so, also for whatever reasons, >> has done for the last few decades. There is, from the perspective of >> the sender at SMTP level, nothing fundamentally different between, >> say, being rejected based on an entry in the access database, and >> being rejected based on something found, or not found, in the >> headers. > > In accordance with the process defined by the Chairs I am explaining > _my_ inability to deploy Sender-ID. And I respect your objections. I just have a series of my own. :) > You then proceed to cause a bounce to be sent to a recipient defined > in a message you _know_ to have been repudiated. But I do *not* cause a message to be sent. I reject a connection. As Jim astutely pointed out, if others see fit to take my rejection and create some sort of bounce, what is it to me? I am certainly not the one having sent any message; nor the one having *caused* to be sent anything. Like I said, all I do is reject a connection. > "Why", the courts may well ask, "did you send a message, known to you > to be forged and potentially carrying malicious content, to this > innocent child?" "But, Your Honor, I did *not* send a message. To up You even one, I caused the immediate and unconditional abortion of the transmission of said message, the moment I became aware of it being a forgery. Would Your Honor rather have I had accepted the message, only to find myself in Your illustrious Court, next month, for having aided and abetted in the transmission of said forgery, whilst I had been made aware of its fraudulent nature? Surely not!" When a domain owner publishes a "-all" SPF-record, and a connecting host falls within that category, then the domain owner is effectively instructing me as follows: "I have not authorized IP address such-and-such to send mail on behalf of me; please, treat the message as a forgery, and reject the connection." Have you thought about the legal ramifications of ignoring that instruction? If the entity in question is a large financial institution, for instance, and I had been explicitely told, via DNS, that a message in their name was a forgery, then I believe my safest legal bet consists of honoring the domain holder's request to reject the message; or rather, not to deliver it. Which leaves me DISCARD. There *is* a technical reason against discarding a message, however. Quite simply, it makes SUBMITTER useless. Because when you DISCARD a message, you have to wait out the entire transmission, past the DATA phase, only to pretend you accepted it, while discarding it silently. See, the problem, IMHO, is not me *causing* a bounce to be generated on the connecting host, but the connecting host sending me the forgery! Had the connecting host checked for forgeries, he would A) not have sent me the message to begin with; and B) not have bounced to a (possibly) innocent third party upon my rejection. All of which, really, has nothing to do with me. I just take *my* responsibility in rejecting the forgery. YMMV; and, obviously, it does. :) - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 09:56: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 JAA15679 for ; Wed, 25 Aug 2004 09: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 i7PDUL5c017688; Wed, 25 Aug 2004 06:30: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 i7PDULAh017687; Wed, 25 Aug 2004 06:30:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDUKgJ017681 for ; Wed, 25 Aug 2004 06:30:20 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1Bzxqt-000495-E2 for ietf-mxcomp@imc.org; Wed, 25 Aug 2004 08:30:22 -0500 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 25 Aug 2004 08:30:11 -0500 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> (Gordon Fecyk's message of "Tue, 24 Aug 2004 19:52:26 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> "Gordon Fecyk" writes: > It's quite clear that the GNU/FSF camp in this list will go to full lengths > to describe how incompatible Microsoft's IPR claims and licensing > requirements are with their precious GPL. It's also clear that Microsoft is > not interested in appeasing this group even though Harry, Jim and Bob have > gone to extreme lengths to accommodate the not-so-extreme groups (*BSD, APL, > MPL, and so forth). > > [more flamebait deleted] Wow, that is one the most hard-core anti-GPL rants I've seen in a long time, even compared with some of the trolls on slashdot. If the FSF and "GPL fanatics" were demanding that SenderID *HAD* to be GPL'ed, then you might have a point. Instead, the problem is that it Microsoft appears to be demanding that SenderID *CANNOT* be GPL'ed. As Eric Allman's analysis of the SenderID license shows, even in those cases where the SenderID license is compatible with other licenses, it is extremely burdensome. While some may claim that it isn't that bad to just get one license signed, that is really in the same league as spammers saying that it is just one email, you should just hit delete. Many OS distributions have thousands of packages, and each package could have many components that, like SenderID, require "just one license". The advertising clause of the original BSD license was widely rejected (and now withdrawn by UCB) because of the problems caused if everyone required the same thing. Microsoft has *not* "gone to extreme lengths to accommodate the not-so-extreme groups", their license is much more burdensome than many other IPR licenses for other RFCs approved by the IETF. About the only thing I agree with Gordon is that we should "Get On With It". We need to drop the PRA because of the license and move on to alternatives that protect the From: header more directly with fewer problems. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 10:09:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17074 for ; Wed, 25 Aug 2004 10:09:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDfxtR019906; Wed, 25 Aug 2004 06:41:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PDfxco019905; Wed, 25 Aug 2004 06:41:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.well.com (smtp.well.com [206.14.209.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDfxYW019899 for ; Wed, 25 Aug 2004 06:41:59 -0700 (PDT) (envelope-from cpm@well.com) X-WELL-Auth: Yes Received: from [192.168.0.9] (orthanc.avwashington.com [199.227.4.34]) by smtp.well.com (8.13.0/8.13.0) with ESMTP id i7PDfvcM010233; Wed, 25 Aug 2004 06:42:00 -0700 (PDT) Message-ID: <412C96E6.9000102@well.com> Date: Wed, 25 Aug 2004 09:40:54 -0400 From: Chip Mefford User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Shewmaker CC: IETF MARID List Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ References: <20040824071602.GF13303@nic.fr> <1093387765.1840.11560.camel@localhost.localdomain> In-Reply-To: <1093387765.1840.11560.camel@localhost.localdomain> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on smtp X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Shewmaker wrote: | On Tue, 2004-08-24 at 16:48, Eric Allman wrote: | |>As near as I can tell, the question |>of GPL compatibility is quite ambiguous at this time. | | I'm sorry, but the [L]GPL incompatibility couldn't be more unambiguous: Aaaah! Help me out here, I don't understand this empircal statement. "I'm sorry, but the [L] GPL incompatibility couldn't be more unambiguous:" Okay, "I'm sorry, but the [L] GPL /in/compatibility could /not/ be more /un/ambiguous:" So, does that mean the GPL compatibility could not be more ambiguous, or is it the opposite? Or, does that mean the GPL compatibility could be more unambiguous? I'm not splitting hairs, I really am not sure what is the point. Thanks for any enlightenment. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLJbia44x14FCa6ARAueuAJwODtN5o2W7cKX4W7RrOZGi2MalcACePi0R 8WCyp2PRwXWh71mGORE/fVA= =A+MD -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 10:35:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19741 for ; Wed, 25 Aug 2004 10:35:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PEBZTA027286; Wed, 25 Aug 2004 07:11: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 i7PEBZuf027285; Wed, 25 Aug 2004 07:11:35 -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 i7PEBYXe027267 for ; Wed, 25 Aug 2004 07:11:34 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 25 Aug 2004 10:11:34 -0400 id 00197698.412C9E16.00004C88 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "IETF MXCOMP (E-mail)" From: Andrew Newton Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Date: Wed, 25 Aug 2004 10:11:31 -0400 To: "Gordon Fecyk" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 8:52 PM, Gordon Fecyk wrote: > They're never going to appease the FSF high > priests so they aren't wasting their time with them, instead focusing > on the > less fanatical majority of APL, MPL, BSD etc and their lesser priests. Gordon, I understand that many people are frustrated by both these discussions and having to have these discussions. Nonetheless, we must act with civility toward all parties. The FSF and GPL proponents should not be given such demeaning labels. Please do not do it again. -andy From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 10:40: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 KAA20082 for ; Wed, 25 Aug 2004 10:40: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 i7PEI4Oj028586; Wed, 25 Aug 2004 07:18: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 i7PEI4Hg028585; Wed, 25 Aug 2004 07:18:04 -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 i7PEI4ik028577 for ; Wed, 25 Aug 2004 07:18:04 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040825141805.EFIA29920.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd> for ; Wed, 25 Aug 2004 10:18:05 -0400 From: "John Glube" To: "'IETF MARID WG'" Subject: RE: TECH OMISSION: Stronger checks against email forgery Date: Wed, 25 Aug 2004 10:17:48 -0400 Message-ID: <00e101c48aae$4cadaed0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <00d401c48a67$895d6380$6c62fea9@ibmrkydk2ufvdd> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7PEI4ik028579 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit This is a follow up to my earlier message on the same subject. I have re-framed the content in the specific manner requested by the WG chairs in their message with the subject line: >Working Group Last Call on Sender ID Documents This is done in the event my earlier message was not in compliance. Please read the two together. I regret any inconvenience this may cause. 1. It is generally understood that: >a huge majority of unwanted email contains headers that lie >about the origin of the mail. This is true of most spam >and substantially all of the virus email that is sent. The Sender-ID documents set describes a mechanism allowing: >receiving MTAs, MDAs and/or MUAs to recognize mail in the >above category and take appropriate action. For example, >an MTA might refuse to accept a message, an MDA might >discard a message rather than placing it into a mailbox, >and an MUA might render that message in some distinctive >fashion. In both cases, I am quoting from Sender ID: Authenticating Email. The mechanism is to extract the purported responsible address: (i) from the sender address, or re-sent sender address as supplied at the data stage; or (ii) from the header information at the transport stage and using the purported responsible domain's email policy record found in that domain's DNS file, check to see whether the sending MTA is authorized to send email for that domain. 2. Domain information may be easily forged in email headers so potentially corrupting data information. Also, many who forge domain information also apparently send direct from an IP address to the recipient's mail server. The authors of the SMTP Responsible Submitter Extension document acknowledge these problems as follows: >Verifying MTAs are strongly urged to validate the SUBMITTER >parameter against the RFC 2822 headers; otherwise, an >attacker can trivially defeat the algorithm. It is suggested that we have stronger checks to allow for more substantive testing without sole reliance on parsing the RFC 2822 headers. This can be done by also: * running a mail from check using the SPF record format and test protocol; and, * running an ehelo or helo check using client smtp validation; concurrently with the appropriate checks called for under the Sender-ID documents. The purpose of these necessary features recognizes that although one data set might be corrupted or absent, matching of data against a number of identifiers will likely generate better results. It allows receiving mail transfer agents to conduct more rigorous testing, reducing the risk of trivial attacks defeating Sender-ID at the data stage, without the need for heavy reliance on parsing header information. 3. This can be achieved through publishing a best current practices document concurrently with the Sender-ID set of documents, should this working group decide to recommend the Sender-ID documents set for approval as an RFC. This document can in essence recommend receiving MTAs run: * purported responsible domain checks when the submitter extension is available in accordance with the schemes outlined in the Sender-ID documents set; * mail from checks using the SPF record format and test protocol; and * ehelo/helo checks using client smtp validation. The result? It would: * strengthen the goal of allowing receiving MTAs to properly recognize unwanted email with headers that lie about the mail's origin, while reducing false positives. This allows for rejecting of messages with stronger confidence along with the appropriate rejection notice. The later ensures complying with the requirement imposed on all parts carrying out the simple mail transfer protocol as found in section 2.1 of RFC 2821: >.. message transfer can occur in a single connection >between the original SMTP-sender and the final >SMTP-recipient, or can occur in a series of hops through >intermediary systems. In either case, a formal handoff of >responsibility for the message occurs: the protocol >requires that a server accept responsibility for either >delivering a message or properly reporting the failure to >do so. (As an aside also see the concerns raised by Chris Haynes concerning this issue in the following message: http://www.imc.org/ietf-mxcomp/mail-archive/msg03601.html) * reduce the suggested likelihood of MDAs deciding to discard messages, or users of MUAs sorting through distinctively marked unwanted email. I also reiterate the material referenced in my message found at: http://www.imc.org/ietf-mxcomp/mail-archive/msg03582.html I add for the reader's benefit, although the original message and this follow up are found in the thread dealing with the subject DEPLOY: Legal liability for creating bounces from forged messages my concern is not with the IPR notice filed by Microsoft, the license form or the FAQ. As previously stated, although I was one of the individuals raising concerns about the IPR notice and license form as originally filed with the Caller-ID draft, the material filed and documents distributed has satisfied my personal concerns. It appears to me at least the material provided is a genuine response to the concerns of many in the open source community. I appreciate others disagree with my personal views on this point. For those who have views on the IPR and license claims, avoid my error. The preference is not to combine issues. Send messages on the IPR and license claims with DEPLOY in the subject line and keep in mind the guidance of the WG chairs. 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.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 10:43: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 KAA20281 for ; Wed, 25 Aug 2004 10:43: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 i7PEM0HE029298; Wed, 25 Aug 2004 07:22:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PEM09o029297; Wed, 25 Aug 2004 07:22:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PELxIg029283 for ; Wed, 25 Aug 2004 07:22:00 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7PELx77021251 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 25 Aug 2004 10:22:01 -0400 Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ From: Mark Shewmaker To: IETF MARID List Cc: Chip Mefford In-Reply-To: <412C96E6.9000102@well.com> References: <20040824071602.GF13303@nic.fr> <1093387765.1840.11560.camel@localhost.localdomain> <412C96E6.9000102@well.com> Content-Type: text/plain Message-Id: <1093443804.2379.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 25 Aug 2004 10:23:24 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Wed, 25 Aug 2004 10:22:01 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-25 at 09:40, Chip Mefford wrote: > Aaaah! Help me out here, I don't understand this empircal statement. > > "I'm sorry, but the [L] GPL incompatibility couldn't be more unambiguous:" To clarify any grammatical ambiguity: o I claim that the [L]GPL is incompatible. o I also claim that that the incompatibility should not be in dispute, that it's quite clearly, and unambiguously, incompatible. I should have avoided using the "couldn't be more" wording. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 13:56: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 NAA05086 for ; Wed, 25 Aug 2004 13:56:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHM3so070728; Wed, 25 Aug 2004 10:22: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 i7PHM37B070727; Wed, 25 Aug 2004 10:22:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.e-dialog.com (mail1.e-dialog.com [64.28.75.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHLsfP070689 for ; Wed, 25 Aug 2004 10:21:54 -0700 (PDT) (envelope-from jeff.macdonald@e-dialog.com) Received: from [10.0.40.189] (jm-node4.e-dialog.com [10.0.40.189]) by mail1.e-dialog.com (8.12.11/8.12.10) with ESMTP id i7PHLnAf031452; Wed, 25 Aug 2004 13:21:50 -0400 Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages From: Jeff Macdonald To: Stephane Bortzmeyer Cc: John Glube , "'IETF MARID WG'" In-Reply-To: <20040825101728.GC31087@nic.fr> References: <81AC085044D04B429F5FB883D94FA1AF8898E3@df-fido-msg.exchange.corp.microsoft.com> <00ce01c48a29$d0c9b9f0$6c62fea9@ibmrkydk2ufvdd> <20040825101728.GC31087@nic.fr> Content-Type: text/plain Organization: E-Dialog Message-Id: <1093454509.26672.54.camel@jmacdonald-work.e-dialog.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 25 Aug 2004 13:21:49 -0400 Content-Transfer-Encoding: 7bit X-Spam-Hits: -4.9 EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-25 at 06:17, Stephane Bortzmeyer wrote: > Is it unrealistic to assume that, if the current Sender-ID becomes a > RFC as it is, nevertheless, some people will use SPF records (as > specified in -protocol) to perform checks on the 2821 MAIL FROM and > not only on the official PRA? > That is my thinking exactly. Someone will create a tool that combines all these checks. > A sort of unofficial "Unified SPF"? Or a new RFC or BCP that would take all those ideas and combine it into one. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 13:56: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 NAA05106 for ; Wed, 25 Aug 2004 13:56: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 i7PHZncH073408; Wed, 25 Aug 2004 10:35: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 i7PHZnfx073406; Wed, 25 Aug 2004 10:35:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from localhost.localdomain (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHZmi6073373 for ; Wed, 25 Aug 2004 10:35:48 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (vodka [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i7PHZg09017391 for ; Wed, 25 Aug 2004 10:35:42 -0700 Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It From: Ryan Ordway To: IETF MARID WG In-Reply-To: References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1093455341.17218.12.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 25 Aug 2004 10:35:41 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-25 at 06:30, wayne wrote: > If the FSF and "GPL fanatics" were demanding that SenderID *HAD* to be > GPL'ed, then you might have a point. Instead, the problem is that it > Microsoft appears to be demanding that SenderID *CANNOT* be GPL'ed. This is the point that those either in favor of or ambivalent towards the RFSIPL are missing. People don't so much care WHAT license Microsoft conjures up, as long as it is not going to be a) burdensome to those implementing and distributing software containing their alleged IP and b) detrimental to adoption of whatever, if any, standard arises. > Microsoft has *not* "gone to extreme lengths to accommodate the > not-so-extreme groups", their license is much more burdensome than > many other IPR licenses for other RFCs approved by the IETF. And therefore, using previous standards with IPR licenses as an excuse to adopt a standard with a much more burdensome license starts us back down the slippery slope. "Go ahead, drink the kool-aid... other people have done it!" > About the only thing I agree with Gordon is that we should "Get On > With It". We need to drop the PRA because of the license and move on > to alternatives that protect the From: header more directly with fewer > problems. Perhaps a show of hands is in order to see just how much of a "minority" those who disapprove of the terms of the RFSIPL are? Consider my hand raised. Ryan -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 14:48: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 OAA08839 for ; Wed, 25 Aug 2004 14:48: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 i7PIEGDt080966; Wed, 25 Aug 2004 11:14: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 i7PIEGAl080965; Wed, 25 Aug 2004 11:14:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIEFvB080951 for ; Wed, 25 Aug 2004 11:14:15 -0700 (PDT) (envelope-from csm@redhat.com) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7PIEGS0032154 for ; Wed, 25 Aug 2004 14:14:16 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7PIEG311320 for ; Wed, 25 Aug 2004 14:14:16 -0400 Received: from [192.168.0.25] (vpn50-61.rdu.redhat.com [172.16.50.61]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i7PIEGJJ011044 for ; Wed, 25 Aug 2004 14:14:16 -0400 Message-ID: <412CD6F7.5020109@redhat.com> Date: Wed, 25 Aug 2004 14:14:15 -0400 From: Chuck Mead Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> In-Reply-To: <1093455341.17218.12.camel@vodka> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ryan Ordway wrote: | On Wed, 2004-08-25 at 06:30, wayne wrote: | |>If the FSF and "GPL fanatics" were demanding that SenderID *HAD* to be |>GPL'ed, then you might have a point. Instead, the problem is that it |>Microsoft appears to be demanding that SenderID *CANNOT* be GPL'ed. | | | This is the point that those either in favor of | or ambivalent towards the RFSIPL are missing. People don't | so much care WHAT license Microsoft conjures up, as long as it | is not going to be a) burdensome to those implementing and | distributing software containing their alleged IP and b) | detrimental to adoption of whatever, if any, standard arises. | | |>Microsoft has *not* "gone to extreme lengths to accommodate the |>not-so-extreme groups", their license is much more burdensome than |>many other IPR licenses for other RFCs approved by the IETF. | | | And therefore, using previous standards with IPR | licenses as an excuse to adopt a standard with a much more | burdensome license starts us back down the slippery slope. | "Go ahead, drink the kool-aid... other people have done it!" | | |>About the only thing I agree with Gordon is that we should "Get On |>With It". We need to drop the PRA because of the license and move on |>to alternatives that protect the From: header more directly with fewer |>problems. | | | Perhaps a show of hands is in order to see just | how much of a "minority" those who disapprove of the terms | of the RFSIPL are? Consider my hand raised. I also disapprove (and have been for a couple of months at least as the archives will show). - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLNb3Zfy0juH51WsRAoL/AJ9ARXE5j56vGv5X60Z6poanbAYdqACdFlst Qg7B9p5G6p4rg8KFPJrFJ98= =j3I3 -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 15: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 PAA10064 for ; Wed, 25 Aug 2004 15:08: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 i7PIeIl7086579; Wed, 25 Aug 2004 11: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 i7PIeInn086578; Wed, 25 Aug 2004 11:40:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from paexchange.corp.mailfrontier.com (blackcomb.mailfrontier.com [209.144.181.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIeH7e086549 for ; Wed, 25 Aug 2004 11:40:17 -0700 (PDT) (envelope-from nleon@mailfrontier.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: DEPLOY - reference implementation Date: Wed, 25 Aug 2004 11:40:15 -0700 Message-ID: Thread-Topic: DEPLOY - reference implementation Thread-Index: AcSKVBSj9oK+2tmJSNONQe04UAHskwAflWsw From: "Nate Leon" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7PIeH7e086571 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Is there a reference implementation published for Sender ID? I realize it would be a Work In Progress. It seems like it doesn't make sense for all of us to invent our own wheels. :-) Regards, Nate From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 15:14: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 PAA10589 for ; Wed, 25 Aug 2004 15:14: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 i7PIq1pj088138; Wed, 25 Aug 2004 11:52: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 i7PIq1vS088137; Wed, 25 Aug 2004 11:52:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIq0Lk088129 for ; Wed, 25 Aug 2004 11:52:01 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C02sN-0001So-00; Wed, 25 Aug 2004 11:52:03 -0700 To: "Gordon Fecyk" Cc: "IETF MXCOMP (E-mail)" Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> From: Daniel Quinlan Date: 25 Aug 2004 11:52:03 -0700 In-Reply-To: "Gordon Fecyk"'s message of "Tue, 24 Aug 2004 19:52:26 -0500" Message-ID: Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Gordon Fecyk" writes: > It's quite clear that the GNU/FSF camp in this list will go to full > lengths I have issues with the license and the open source project I am concerned about (SpamAssassin, an ASF project) is now licensed with the Apache License 2.0 which is about as business-friendly as an open source license gets. I have been working with others to communicate with Microsoft and resolve various serious issues in the license, but Microsoft hasn't yet fixed those issues. Note that the issues affect many open source projects and more licenses than the GPL are incompatible. In addition, the patent license is not exactly friendly to the open source development and redistribution model. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 15: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 PAA12954 for ; Wed, 25 Aug 2004 15:38: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 i7PJICX0092671; Wed, 25 Aug 2004 12: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 i7PJIC0U092670; Wed, 25 Aug 2004 12:18:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJIBQN092654 for ; Wed, 25 Aug 2004 12:18:12 -0700 (PDT) (envelope-from csm@redhat.com) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7PJIDS0019556 for ; Wed, 25 Aug 2004 15:18:13 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7PJID303596 for ; Wed, 25 Aug 2004 15:18:13 -0400 Received: from [192.168.0.25] (vpn50-61.rdu.redhat.com [172.16.50.61]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i7PJID07022189 for ; Wed, 25 Aug 2004 15:18:13 -0400 Message-ID: <412CE5F4.5010006@redhat.com> Date: Wed, 25 Aug 2004 15:18:12 -0400 From: Chuck Mead Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: DEPLOY - reference implementation References: In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nate Leon wrote: | Is there a reference implementation published for Sender ID? | | I realize it would be a Work In Progress. | | It seems like it doesn't make sense for all of us to invent our own | wheels. :-) So far as I am aware there is only one operational reference implementation though it's only applicable to the 2821 headers (unless someone more knowledgeable says different). See http://spf.pobox.com for more information. I have had it in production for about 6 months now with no effects save the obvious benefit of having a functional anti-forgery tool applied to my MTA. - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLOX0Zfy0juH51WsRAq2tAJwK+azfK7jeIDQo4fRW7dWkvHnWqwCfZqpB FHkOkqjeDtHbbctCF9o1xNA= =k0qW -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 15: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 PAA13448 for ; Wed, 25 Aug 2004 15: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 i7PJJaNY093012; Wed, 25 Aug 2004 12:19: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 i7PJJa1s093011; Wed, 25 Aug 2004 12:19: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 (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJJaEH093004 for ; Wed, 25 Aug 2004 12:19:36 -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, 25 Aug 2004 12:19:39 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 25 Aug 2004 12:19:38 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 Aug 2004 12:19:40 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 12:19: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: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination Date: Wed, 25 Aug 2004 12:19:18 -0700 Message-ID: Thread-Topic: DEPLOY: Microsoft's Statement about IPR Claimed in and in Combination thread-index: AcSKE9OBThUfUTrnRUKbO/QUFSb98QAwYvLg From: "Harry Katz" To: "IETF MARID WG" X-OriginalArrivalTime: 25 Aug 2004 19:19:46.0196 (UTC) FILETIME=[7B739D40:01C48AD8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7PJJaEH093005 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tuesday, August 24, 2004 11:52 AM, wayne wrote: > 2) Not all licenses are equal. For example, Cisco's patent license on > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-fenton-identified-mail-00.t xt > seems *much* more reasonable to me than MS's license for SenderID. > (In particular, requiring a signed license for source code > distributions is very burdensome.) Please read the document at the above link carefully. It is NOT a patent license, it is a statement about Cisco's IPR. In fact that's what the title says it is. In this statement, Cisco has not provided a license. Cisco has agreed to offer a license. That offer to license is conditioned on the following: 1. the technology is included in the IETF spec 2. the IETF spec is adopted as a "standard" - see highlighted portion below. Cisco has also indicated that it's license will include reciprocity and defensive terms. Cisco is of course entitled to offer a license under whatever terms and at whatever time it deems appropriate. I would just point out by way of comparison that Microsoft has made an "actual" license available with reference to the existing IETF spec irrespective of whether or not the IETF adopts it as a "standard". Many IETF specs do not actually get adopted as an IETF standard. Microsoft is not taking any position as to whether or not Cisco would make such a license available to early implementers but rather to clarify that Microsoft has taken the unusual step of doing so. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 15:46: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 PAA13473 for ; Wed, 25 Aug 2004 15:46: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 i7PJFxvI092297; Wed, 25 Aug 2004 12:15:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PJFxLU092296; Wed, 25 Aug 2004 12:15:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJFwUU092284 for ; Wed, 25 Aug 2004 12:15:59 -0700 (PDT) (envelope-from george@m5p.com) Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by mailhost.m5p.com (8.12.11/8.12.11) with ESMTP id i7PJFuci066698 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Aug 2004 12:15:57 -0700 (PDT) Received: (from defang@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7PJFFUj066692 for ; Wed, 25 Aug 2004 12:15:15 -0700 (PDT) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (MIMEDefang) with ESMTP id i7PJFFoe066691; Wed, 25 Aug 2004 12:15:15 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7PJFEA2018942; Wed, 25 Aug 2004 12:15:14 -0700 (PDT) Date: Wed, 25 Aug 2004 12:15:14 -0700 (PDT) From: George Mitchell Message-Id: <200408251915.i7PJFEA2018942@m5p.com> To: ietf-mxcomp@imc.org, ryan@nwgeeks.com Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It In-Reply-To: <1093455341.17218.12.camel@vodka> X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > About the only thing I agree with Gordon is that we should "Get On > > With It". We need to drop the PRA because of the license and move on > > to alternatives that protect the From: header more directly with fewer > > problems. > > Perhaps a show of hands is in order to see just > how much of a "minority" those who disapprove of the terms > of the RFSIPL are? Consider my hand raised. > > Ryan Consider my hand raised for dropping whatever it is that's covered by this license which refers to undisclosed patent applications. -- George Mitchell From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 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 QAA15108 for ; Wed, 25 Aug 2004 16:06: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 i7PJfe62096619; Wed, 25 Aug 2004 12:41: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 i7PJfeg4096618; Wed, 25 Aug 2004 12:41:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.well.com (smtp.well.com [206.14.209.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJfeIB096611 for ; Wed, 25 Aug 2004 12:41:40 -0700 (PDT) (envelope-from cpm@well.com) X-WELL-Auth: Yes Received: from [192.168.0.9] (orthanc.avwashington.com [199.227.4.34]) by smtp.well.com (8.13.0/8.13.0) with ESMTP id i7PJffs1001147; Wed, 25 Aug 2004 12:41:43 -0700 (PDT) Message-ID: <412CEB30.70107@well.com> Date: Wed, 25 Aug 2004 15:40:32 -0400 From: Chip Mefford User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Mead CC: IETF MARID WG Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> <412CD6F7.5020109@redhat.com> In-Reply-To: <412CD6F7.5020109@redhat.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on smtp X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Mead wrote: | | Ryan Ordway wrote: | | On Wed, 2004-08-25 at 06:30, wayne wrote: |SNIP | | Perhaps a show of hands is in order to see just | | how much of a "minority" those who disapprove of the terms | | of the RFSIPL are? Consider my hand raised. | | I also disapprove (and have been for a couple of months at least as the | archives will show). As do I, - --chipper -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLOsva44x14FCa6ARAj1eAKCXIP+ymBGS3N0WYHaqg9QSmrmo+QCfWVhg u61+wFV65YL9inT1I0gLoTg= =elzY -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 16: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 QAA17840 for ; Wed, 25 Aug 2004 16: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 i7PKCM7J001884; Wed, 25 Aug 2004 13: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 i7PKCMI1001883; Wed, 25 Aug 2004 13:12:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKCMrE001877 for ; Wed, 25 Aug 2004 13:12: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 D341A4149B for ; Wed, 25 Aug 2004 13:12:26 -0700 (PDT) Subject: DEPLOY: Misuse of Resent-From From: Douglas Otis To: MARID Content-Type: text/plain; charset=iso-8859-13 Message-Id: <1093464745.3483.101.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 25 Aug 2004 13:12:25 -0700 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Goal- Reduce Spoofing Technique: Use the RFC2822 From Mailbox Domain to reference a Mail Channel prescription to refuse non-conforming messages. Problem as a result of this technique- If this From Mailbox Domain were applied generally to reference the Mail Channel prescription, much of the mail would be refused. Sender-ID response to this issue- The Purported Responsible Address (PRA) algorithm prioritizes the headers used to reference the Mail Channel prescription as a means to reduce the number of messages refused. Many messages will still be refused even with comprehensive Mail Channel prescription records however. To enable exceptions, dangerous "open-ended" lists are allowed in the Mail Channel prescriptions. Deployment response to this issue- The use of the PRA Mailbox Domain selection invites a practice of routinely adding a Resent-From header to the mail message to override the Mail Channel prescription for problems not generally solved with the PRA Mailbox Domain selection. This header would be added to ameliorate problems with mail forwarding, or support issues with customers using their well-known return address, among others. PRA defeats the goal of the RFC2822 From being protected. Sender-ID response to this issue- Sender-ID assumes differing mail user agents will indicate which header is being examined and make this header visible to the user, provided the MUA vendor has a signed contract with Microsoft. Sender-ID also assumes selection of this displayed header will be the header checked by the receiving MTA, assuming the MTA vendor also has a signed contract with Microsoft. The complex level of parsing required may invite security issues of the display not matching the check and not easily addressed with diverse implementations. Alternative solution as illustrated in: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt Use of the EHLO domain authenticates the administrative domain accountable for policies of the sending MTA, and thus provides a more reliable and less easily spoofed identity without forcing changes on the mail system. With the PRA algorithm, an MTA could purport being within the prescribed Mail Channel of millions of Mailbox Domains, while never being specifically authorized by any such domain. Sender-ID allows exceptions using syntax like "?all" or "+all" which enables spoofing. Should use of the Resent-From header become widely used as a deployment solution, there would be little difference between the identity within the Resent-From and that of the EHLO domain. Use of the EHLO domain does ensure the same field is always checked and is also administratively related to the MTA. This identity selection can happen without stringent parsing conformance checks or signed contracts. If each MTA employs authentication operating on behalf of the recipient, these servers can add or overlay a tag in the RFC2822 From header which indicates the proximal sending MTA outside the recipient's administrative realm. This EHLO identity is the entity accountable for the delivery of the message and is actually the entity being trusted as a broker with respect to message content. This identity would then be visible to the end user and thwart spoofing more effectively than reliance on PRA, especially once deployment solutions are considered. A typical MTA already knows local Mailbox Domains or inbound Mailbox Domains relayed. If an MTA receives mail from outside these administered domains, it can strip and add the RCVD tag for their recipients. Such as- From: ´[rcvd: mx01.some.domain.com*]¡ someone The ´*¡ would indicate successful authentication. This tag would be applied or reapplied when entering from outside the administrative domain of the recipient based upon the EHLO domain information and successful authentication and confirmation of authorization. Such a practice should not require an IPR license for implementation, nor require extensive changes to existing SMTP software, nor require extensive changes in the use of mail. Reputation services will be needed to exclude most of the abuse, and the EHLO domain is an identity that can be used for this purpose, unlike the domain selected using the PRA algorithm. Refused From Protection? Was this the goal? To extend protection when there is no reputation service, institutions, commonly having their Mailbox Domain forged, may wish to request a restriction or verification as to whether the message is from their servers with respect to the RFC2822 From Mailbox Domain. This would assume the institution has control over those able to send from the prescribed Mail Channel. This is not always the case. Although refusal protection is not always possible in the general case, as illustrated by the use of the PRA algorithm, there may be institutions willing to endure these limitations for specific sub-domains. To that end, an absolute restriction would be possible by publishing a PTR list of acceptable EHLO domains for this Mailbox Domain. This would also be a means to prescribe the Mail Channel with a single DNS lookup! This list could be published without requesting a restriction and but assume the MUA will provide some type of indication of the message's status. If restricted, the institution could not expect this message to be forwarded through a mailing list without reliance on other means to verify the Mailbox Domain. This would provide an institution an exceptionally strong conformance check on the RFC2822 From Mailbox Domain Mail Channel and, in addition, by making the EHLO domain visible to the user, would greatly reduce phishing and spoofing far better than could be achieved by Sender-ID. Better recipient/sender protection. Policy enforcement facilitated. Reputation services enabled. Stronger identification with less overhead. No burden on normal use. No IPR. No scripts. No risk of DoS. No sequential DNS lookups. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 16:40: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 QAA18000 for ; Wed, 25 Aug 2004 16:40: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 i7PKKjej003640; Wed, 25 Aug 2004 13:20:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PKKjMC003639; Wed, 25 Aug 2004 13:20:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKKi6V003617 for ; Wed, 25 Aug 2004 13:20:44 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7PKKeQM011038 for ; Wed, 25 Aug 2004 21:20:40 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7PKKeQC011037; Wed, 25 Aug 2004 21:20:40 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> From: Graham Murray Date: Wed, 25 Aug 2004 21:20:40 +0100 In-Reply-To: <1093455341.17218.12.camel@vodka> (Ryan Ordway's message of "Wed, 25 Aug 2004 10:35:41 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ryan Ordway writes: > Perhaps a show of hands is in order to see just > how much of a "minority" those who disapprove of the terms > of the RFSIPL are? Consider my hand raised. My hand is raised. From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 16:52: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 QAA19470 for ; Wed, 25 Aug 2004 16: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 i7PKPAxN003963; Wed, 25 Aug 2004 13:25:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PKPA3p003962; Wed, 25 Aug 2004 13:25:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKP9YQ003946 for ; Wed, 25 Aug 2004 13:25:09 -0700 (PDT) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id i7PKP6NE087775; Wed, 25 Aug 2004 20:25:06 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.12.9-20030917/8.12.9) with ESMTP id i7PKP5lZ002674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2004 22:25:06 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i7PKP5bI002673; Wed, 25 Aug 2004 22:25:05 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Wed, 25 Aug 2004 22:25:05 +0200 From: Koen Martens To: "Hallam-Baker, Phillip" Cc: "'Mark Shewmaker'" , IETF MARID List Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Message-ID: <20040825202505.GF2397@metro.cx> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 05:21:54PM -0700, Hallam-Baker, Phillip wrote: > The issue for this group is whether the license restrictions are > reasonable or not. > > Compatibility with a specific license is not a requirement, still > less compatibility with fanciful interpretations thereof. I do agree, although the focus has been on compatibility with any number of open source licenses, this is not the main point. The point is: the license restrictions are not reasonable. Asking implementors to sign a contract with microsoft will scare implementors away. Perhaps this is the whole point of the license. The license might be perfectly reasonable for big companies. It is not for smaller ones or people who write software on their personal title. Are you just telling those (the small companies and individual developers) to shut up and accept what is being shoved down their throat? That would be a waste, and I want to repeat this. By persisting on this signed contract, microsoft scares away developers and splits the potential resources, in fact doing more against than for a better use of email worldwide. Koen Martens -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 17:29: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 RAA24215 for ; Wed, 25 Aug 2004 17:29: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 i7PL6RJ7006653; Wed, 25 Aug 2004 14:06: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 i7PL6R07006652; Wed, 25 Aug 2004 14:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PL6Q7I006634 for ; Wed, 25 Aug 2004 14:06:27 -0700 (PDT) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id i7PL6QCT089169; Wed, 25 Aug 2004 21:06:26 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.12.9-20030917/8.12.9) with ESMTP id i7PL6PlZ002953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2004 23:06:25 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i7PL6P6Y002952; Wed, 25 Aug 2004 23:06:25 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Wed, 25 Aug 2004 23:06:25 +0200 From: Koen Martens To: Ryan Ordway Cc: IETF MARID WG Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Message-ID: <20040825210625.GM2397@metro.cx> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093455341.17218.12.camel@vodka> User-Agent: Mutt/1.4.1i X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 10:35:41AM -0700, Ryan Ordway wrote: > Perhaps a show of hands is in order to see just > how much of a "minority" those who disapprove of the terms > of the RFSIPL are? Consider my hand raised. FWIW, my hand is raised. I oppose against an internet standard that requires a contract with microsoft to implement. Koen Martens -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 17:53: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 RAA27184 for ; Wed, 25 Aug 2004 17:53:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PLUTHC008201; Wed, 25 Aug 2004 14:30: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 i7PLUT4R008200; Wed, 25 Aug 2004 14:30:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PLUSi0008194 for ; Wed, 25 Aug 2004 14:30:28 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i7PLUV3V002256 for ; Wed, 25 Aug 2004 14:30:31 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id C3EBE84F867; Wed, 25 Aug 2004 14:30:31 -0700 (PDT) Date: Wed, 25 Aug 2004 14:30:31 -0700 From: "Mark C. Langston" To: IETF MARID WG Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Message-ID: <20040825213031.GT41046@bitshift.org> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> <20040825210625.GM2397@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040825210625.GM2397@metro.cx> User-Agent: Mutt/1.4.1i X-Uptime: 2:29PM up 71 days, 22:36, 7 users, load averages: 0.24, 0.10, 0.03 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 11:06:25PM +0200, Koen Martens wrote: > > On Wed, Aug 25, 2004 at 10:35:41AM -0700, Ryan Ordway wrote: > > Perhaps a show of hands is in order to see just > > how much of a "minority" those who disapprove of the terms > > of the RFSIPL are? Consider my hand raised. > > FWIW, my hand is raised. I oppose against an internet standard that requires a > contract with microsoft to implement. > Idem. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 18:26:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02132 for ; Wed, 25 Aug 2004 18:26: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 i7PM4HjS011237; Wed, 25 Aug 2004 15:04:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PM4Hhm011236; Wed, 25 Aug 2004 15:04:17 -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 i7PM4G0A011225 for ; Wed, 25 Aug 2004 15:04:17 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7PM4C57018957; Wed, 25 Aug 2004 15:04:13 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7PM49Wk026796; Wed, 25 Aug 2004 15:04:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <20040825210625.GM2397@metro.cx> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> <20040825210625.GM2397@metro.cx> Date: Wed, 25 Aug 2004 15:04:08 -0700 To: Koen Martens , Ryan Ordway From: Ted Hardie Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Cc: IETF MARID WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:06 PM +0200 8/25/04, Koen Martens wrote: >On Wed, Aug 25, 2004 at 10:35:41AM -0700, Ryan Ordway wrote: >> Perhaps a show of hands is in order to see just >> how much of a "minority" those who disapprove of the terms >> of the RFSIPL are? Consider my hand raised. > >FWIW, my hand is raised. I oppose against an internet standard that requires a >contract with microsoft to implement. > An important part of the IETF process is that we treat all of its participants as behaving in good faith. If the license terms offered cause difficulties for you, please state how the terms impact your development and deployment. (Eric's description of the sublicensing issue for Sendmail is a good example here, and I encourage you to read it as a potential model). Stating that the _holder_ of the IPR is the problem, rather than the _terms_ of the license, is very different. That is contrary to the principle that we treat all participants as behaving in good faith. Please focus on the terms, not the holder. regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 18:51: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 SAA04251 for ; Wed, 25 Aug 2004 18:51: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 i7PMQJx5012371; Wed, 25 Aug 2004 15:26: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 i7PMQJ8G012370; Wed, 25 Aug 2004 15:26:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMQIrK012363 for ; Wed, 25 Aug 2004 15:26:18 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i7PMQJ3V013273 for ; Wed, 25 Aug 2004 15:26:20 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id D628A84F867; Wed, 25 Aug 2004 15:26:19 -0700 (PDT) Date: Wed, 25 Aug 2004 15:26:19 -0700 From: "Mark C. Langston" To: IETF MARID WG Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Message-ID: <20040825222619.GA20098@bitshift.org> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> <20040825210625.GM2397@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 3:12PM up 71 days, 23:19, 8 users, load averages: 0.13, 0.13, 0.07 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 03:04:08PM -0700, Ted Hardie wrote: > > An important part of the IETF process is that we treat all of its > participants > as behaving in good faith. If the license terms offered cause difficulties > for you, please state how the terms impact your development and deployment. > (Eric's description of the sublicensing issue for Sendmail is a good example > here, and I encourage you to read it as a potential model). > > Stating that the _holder_ of the IPR is the problem, rather than the _terms_ > of the license, is very different. That is contrary to the principle that > we > treat all participants as behaving in good faith. Please focus on the > terms, > not the holder. The lack of information about the technology covered by the patent(s) is one of my primary concerns. E.g., if I choose to implement SPFv1 checks in my code and DO sign the license as required for Sender-ID, versus NOT signing the license and foregoing Sender-ID, how infringing is SPFv1? The lack of transferrability and sublicensability are also concerns. I can't in good conscience say, "go ahead with this" because I don't know what I'm agreeing to vis a vis the patent claims, as they're undisclosed, and no clarification as to the specific claims has been forthcoming. I can't in good conscience say, "go ahead with this" because it restricts the licensing and distribution of code I may choose to write. Several people have brought up RFC2338 as an example of precedence for this type of IPR claim. The other side of that coin is the HSRP/VRRP battle, and the necessity of introducing CARP because of that IPR confusion. At best, it's produced several rounds of legal posturing and three similar, competing protocols. At worst, it's fractured the solution space, limited deployment, and caused an overall chilling effect. Those aren't good outcomes when we're discussing a technology whose success depends in part on widespread adoption and deployment. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 18:57:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04859 for ; Wed, 25 Aug 2004 18:57:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMaKGD013124; Wed, 25 Aug 2004 15:36:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMaKHk013123; Wed, 25 Aug 2004 15:36:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMaHsW013113 for ; Wed, 25 Aug 2004 15:36:19 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7PMiORI009168 for ; Wed, 25 Aug 2004 15:44:24 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7PMiOSN009165 for ; Wed, 25 Aug 2004 15:44:24 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 25 Aug 2004 15:44:24 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: Re: DEPLOY/IPR: Fundamental Disagreements - licese terms are a blow to IETF process 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, 25 Aug 2004, Graham Murray wrote: > Ryan Ordway writes: > > > Perhaps a show of hands is in order to see just > > how much of a "minority" those who disapprove of the terms > > of the RFSIPL are? Consider my hand raised. > > My hand is raised. My hand is also raised. Because in my view the license terms represent a blow to opensource and a more important here blow to IETF process. The license terms are a blow to the core of the opensource movement. All other open-source license were created as a reaction to GNU when it did not quite fit circumstance for particular product when commercial interest were to a degree involved. However opensouce core represented by GNU is why Linux is so popular and its emphasis is on creating product that is free to everyone and where everyone, including commercial entities are treated the same just as a free willing contributor to the product and his/hers/its contribution does not impose any restrictions and become equal part of the total mix. The IETF to a degree represents similar ideas in the world of protocol design - everyone here is treated as a individual and his or hers contribution go towards the total and should be treated equally with everyone elses ideas no matter what company person may work for (if any at all). As individuals everyone here is giving their time and ideas freely towards the total understanding that its all goes towards creating something really good that everyone can enjoy and all such participants receive back is enjoyment that you helped everyone else on the net (and maybe your name in RFC, but although for some that is important, I hope most understand that its not the main thing). Similarly to opensource the contribution should not impose restrictions on the protocol as those giving it, including large corporations should be compelled to provide their ideas free and unrestricted to everyone else (although I'm ok with patent license terms where all that is required is acknoledgement of work of that company, that is fair thing to ask). If we continue with IETF process where company get involved and using their patent terms restrict use of the protocol to only certain persons, the process would have failed to achieve fundamental goal of creating an open standard and failed to equally account contribution of every party. This represents the end of IETF in the way it was in my view. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 19:53:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08193 for ; Wed, 25 Aug 2004 19:53:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PNS2JI021509; Wed, 25 Aug 2004 16:28:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PNS2j4021508; Wed, 25 Aug 2004 16:28:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PNS1ol021498 for ; Wed, 25 Aug 2004 16:28:01 -0700 (PDT) (envelope-from csm@redhat.com) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7PNS4S0018378 for ; Wed, 25 Aug 2004 19:28:04 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7PNS3323127 for ; Wed, 25 Aug 2004 19:28:03 -0400 Received: from [10.39.20.126] (vpn50-59.rdu.redhat.com [172.16.50.59]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i7PNS307028037 for ; Wed, 25 Aug 2004 19:28:03 -0400 Message-ID: <412D2082.6020707@redhat.com> Date: Wed, 25 Aug 2004 19:28:02 -0400 From: Chuck Mead Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> <20040825210625.GM2397@metro.cx> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ted Hardie wrote: | | At 11:06 PM +0200 8/25/04, Koen Martens wrote: | |> On Wed, Aug 25, 2004 at 10:35:41AM -0700, Ryan Ordway wrote: |> |>> Perhaps a show of hands is in order to see just |>> how much of a "minority" those who disapprove of the terms |>> of the RFSIPL are? Consider my hand raised. |> |> |> FWIW, my hand is raised. I oppose against an internet standard that |> requires a |> contract with microsoft to implement. |> | | An important part of the IETF process is that we treat all of its | participants | as behaving in good faith. If the license terms offered cause difficulties | for you, please state how the terms impact your development and deployment. | (Eric's description of the sublicensing issue for Sendmail is a good | example | here, and I encourage you to read it as a potential model). I don't doubt that the holder is acting in good faith and I don't doubt that they mean what they say. What I doubt is whether I can apply the solution being proffered in a piece of opensource software and then distribute it if I chose to do so. The license does not appear to allow that and it also appears to require steps prior to using what we're proposing as a "standard". It has been said to me in this forum that I should consult an attorney if I have questions about the licensing. All I can say to that is "fat chance" individuals within the OSS community are not going to do this. Companies might but I personally will not as I cannot afford the fee my attorney would charge me. So does that mean that I cannot or won't implement the solution we're going to offer as a standard. In all likelihood that is exactly what it means. If that's the case (and if we keep heading down this road it's likely that it will be) then what is the chance that I would implement? It's a sum approaching zero. So what good does a standard that I cannot implement do for me? None what so ever. The list of MTA's which appear to be affected by this situation is not that long (sendmail, postfix, qmail and exim for sure) but I'd bet a case of beer that there are more people using them on the net today worldwide than are using close source MTA's (and many of them won't know or care what they're using... they just want their email). If we intend to offer something as a standard we'd better take the situations of the admins that manage those MTA's into account. A bit of practical thought, if you please! What if we set a standard and nobody used it? MARID would really be doing the world a favor right? Hmmmmm....? - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLSCCZfy0juH51WsRAvN+AJ4hkCvJDh/aTEIwM9eVfxYZaQzHaACfYOZw +dv9UKIE2EkJonz0YPDYQbY= =RVH4 -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 19:55: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 TAA08363 for ; Wed, 25 Aug 2004 19:55: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 i7PNZduL022096; Wed, 25 Aug 2004 16:35: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 i7PNZdqv022095; Wed, 25 Aug 2004 16:35:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baltazar.webjorn.org (baltazar.webjorn.org [192.121.126.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PNZbZb022083 for ; Wed, 25 Aug 2004 16:35:38 -0700 (PDT) (envelope-from mattias@webjorn.org) Received: (qmail 17368 invoked from network); 25 Aug 2004 23:35:38 -0000 Received: from ns.webjorn.org (HELO ns) ([192.121.126.21]) (envelope-sender ) by baltazar.webjorn.org (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 25 Aug 2004 23:35:38 -0000 Date: Thu, 26 Aug 2004 01:35:38 +0200 (CEST) From: =?ISO-8859-1?Q?Mattias_Webj=F6rn_Eriksson?= X-X-Sender: materi@ns.webjorn.org Reply-To: mattias@webjorn.org To: ietf-mxcomp@imc.org Subject: Re: DEPLOY/IPR: Fundamental Disagreements - licese terms are a blow to IETF process In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Raised is my hand. The outcome of MARID is direct propotional to deployment, thus the current license terms is not an option. Some one previous wrote about different buisiness models. Spam (MARID's agenda is not about stopping spam, I know, just piece of the puzzle) costs billions of dollars. This costs will by far exceed the eventuall costs for the lack of IPR protection. Even for big companies. Regards Mattias W E From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 21: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 VAA13297 for ; Wed, 25 Aug 2004 21:26: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 i7Q12fHD027619; Wed, 25 Aug 2004 18: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 i7Q12fFp027618; Wed, 25 Aug 2004 18:02:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q12eMt027612 for ; Wed, 25 Aug 2004 18:02:40 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C08f7-00073M-00; Wed, 25 Aug 2004 18:02:45 -0700 To: Chuck Mead Cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> <20040825210625.GM2397@metro.cx> <412D2082.6020707@redhat.com> From: Daniel Quinlan Date: 25 Aug 2004 18:02:45 -0700 In-Reply-To: Chuck Mead's message of "Wed, 25 Aug 2004 19:28:02 -0400" Message-ID: Lines: 14 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Chuck Mead writes: > The list of MTA's which appear to be affected by this situation is not > that long (sendmail, postfix, qmail and exim for sure) but I'd bet a It's not just MTAs that will be implementing Sender-ID (or whatever), but also mail filters (SpamAssassin 3.0 will support SPFv1) and perhaps even MUAs. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 22:00:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15148 for ; Wed, 25 Aug 2004 22:00:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q1cK1E029935; Wed, 25 Aug 2004 18:38: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 i7Q1cKLc029934; Wed, 25 Aug 2004 18:38:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from priv-edtnes40.telusplanet.net (outbound05.telus.net [199.185.220.224]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q1cJAT029926 for ; Wed, 25 Aug 2004 18:38:20 -0700 (PDT) (envelope-from bdamm-ietf@dammfine.com) Received: from xoon.burnaby.f00f.net ([64.180.101.131]) by priv-edtnes40.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040826013820.ZVCJ15564.priv-edtnes40.telusplanet.net@xoon.burnaby.f00f.net> for ; Wed, 25 Aug 2004 19:38:20 -0600 Received: from stack.f00f.net (stack.burnaby.f00f.net [10.0.0.3]) by xoon.burnaby.f00f.net (Postfix) with ESMTP id 6AC2641F24 for ; Wed, 25 Aug 2004 18:38:20 -0700 (PDT) Received: by stack.f00f.net (Postfix, from userid 1004) id BE728105D0; Wed, 25 Aug 2004 18:49:43 -0700 (PDT) Date: Wed, 25 Aug 2004 18:49:43 -0700 From: Benjamin Damm To: IETF MARID WG Subject: Re: [marid] Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Message-ID: <20040826014943.GA13522@stack.vc.shawcable.net> Mail-Followup-To: IETF MARID WG References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093455341.17218.12.camel@vodka> X-Uptime: 16:37:33 up 168 days, 17:11, 16 users, load average: 0.11, 0.27, 0.28 User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 10:35:41AM -0700, Ryan Ordway wrote: > Perhaps a show of hands is in order to see just > how much of a "minority" those who disapprove of the terms > of the RFSIPL are? Consider my hand raised. > I've been lurking for more than a month; now is the time to speak up. The terms of the RFSIPL will restrict Sender-ID development. My hand is raised. -Benjamin From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 22:09: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 WAA15708 for ; Wed, 25 Aug 2004 22: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 i7Q1n1tW030927; Wed, 25 Aug 2004 18:49: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 i7Q1n1DL030926; Wed, 25 Aug 2004 18:49:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q1n09Z030916 for ; Wed, 25 Aug 2004 18:49:00 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1C09Nn-00067F-QO for ietf-mxcomp@imc.org; Wed, 25 Aug 2004 20:49:04 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Wed, 25 Aug 2004 20:48:45 -0500 In-Reply-To: (Harry Katz's message of "Mon, 23 Aug 2004 19:01:00 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7Q1n09Z030921 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In "Harry Katz" writes: > For the convenience of the working group, attached is the full text of > the FAQ. > > If you have any further questions about the license, I encourage you to > consult with your own attorney and/or email your question to > stdsreq@microsoft.com. Someone from our legal department will answer > your questions. Ok, I'm afraid I'm confused by all this and I would like some help in clarifying the situation around qmail. In the Microsoft SenderID FAQ, it states: Q7: Is Microsofts license compatible with Sendmail, Postfix and Qmail? A7: While each open source software license may differ, we believe you can distribute your implementation under many open source software licenses, so long as you include the attribution stipulated in sec. 2.2 of Microsofts Royalty-Free Sender ID Patent License Agreement. You should check with your own legal counsel if you have questions about a particular open source software license. Microsoft has not been made aware of any specific incompatibilities between any of the licenses used to distribute Sendmail, Postfix, or Qmail with Microsofts royalty-free patent license. Now, at the IETF-60 meeting, it was pointed out that qmail has a quirky license. (Many/most people do not consider qmail to be Open Source Software because of its license.) Basically, only the original author can modify qmail, all other changes must be distributed separately and applied as patches. As the original author hasn't updated qmail for years, almost all qmail users take the original source and apply one or more sets of "patches" in order to create an MTA (mail server) which they can use. At the IETF-60, it was pointed out that the SenderID license would mean that all users of qmail would need to obtain a license from Microsoft. Qmail, it should be pointed out, is one of the popular MTAs on the Internet. Some claim it ranks #2 behind sendmail, but it clearly is one of the top 5. So, the question is: Would a qmail patch author qualify as a "licensed implementation" and thus someone who takes qmail and creates a derivative work of it by apply the patch qualify as an "end user"? If not, wouldn't this mean that users of qmail that want to support SenderID (which we hope will be all of them) need to get a license from Microsoft? Section 2.1 says how you can distribute to "End Users" in object code form, but a patch isn't object code. Section 2.2 says how you can distribute to "End Users" a "Licensed Implementation" in source code form. So the question is: can a patch be a "Licensed Implementation?" Section 1.2 gives the definition of a "Licensed Implementation", which, in the second of the two (ii) clauses, requires you to have branded trademark. Do any patches have trademarks? Section 1.5 gives the definition of a "End User", it talks about receiving a "product". Section 1.3 gives the definition of a "Licensed Product", but I don't think a patch is a product. Now the whole problem with patches is that they are derivative works of the original because they contain lines of source code for "context". When you apply a patch and compile it, you are creating a derivative work of both the original and the patch. Often times, the resulting patch needs to be tweaked because of other patches that have also been applied. It isn't at all clear to me that a patch can be a "Licensed Product" and thus allowing the person applying the patch to the qmail source to be covered by the "End User" aspects of the SenderID license. Even if a patch could be a product, aren't you creating a new product when you apply the patch? -wayne From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 23:28:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18842 for ; Wed, 25 Aug 2004 23:28: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 i7Q20bQk032836; Wed, 25 Aug 2004 19:00: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 i7Q20bHF032833; Wed, 25 Aug 2004 19:00:37 -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 i7Q20XMd032810 for ; Wed, 25 Aug 2004 19:00:33 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1C09VH-0006km-Cx for ietf-mxcomp@imc.org; Wed, 25 Aug 2004 21:00:39 -0500 To: "IETF MARID WG" Subject: Can there be an early decision on the SenderID license? From: wayne Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 25 Aug 2004 20:56:29 -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 X-SA-Exim-Scanned: No (on backbone.midwestcs.com); SA Timed out after 240 secs Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Right now, we are supposed to be reviewing all of the documents. However, as demonstrated in the "DEPLOY/IPR: Fundamental Disagreements, or Get On With It" thread, there doesn't seem to be a rough consensus that the SenderID license is acceptable. (Actually, there appears to be a rough consensus that it isn't acceptable.) Unlike other corrections/suggestions that we are making, the SenderID license can not be changed. Therefore, if it is unacceptable, this will prevent the marid-core and marid-pra I-Ds from advancing. If these two I-Ds can't advance, it would be a waste of time to review them for other problems. Actually, it would also be a waste of time for the marid-submitter I-D to advance because it requires the PRA. Now, I don't expect the co-chairs to rule today or tomorrow. There needs to be more time for people to make up their minds and express their views on the SenderID license. Heck, while I have raised certain objections to it, I still am not reading to say whether it is acceptable to me or not. (I'm hoping to hear from people like the FSF and IBM lawyers who were working with MS earlier.) However, it seems to me to be a wise use of this working groups time to decide the license issue early, and then move on from there. Thoughts? -wayne From owner-ietf-mxcomp@mail.imc.org Wed Aug 25 23: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 XAA18879 for ; Wed, 25 Aug 2004 23: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 i7Q1xVuZ032620; Wed, 25 Aug 2004 18: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 i7Q1xVjD032619; Wed, 25 Aug 2004 18:59:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q1xUje032613 for ; Wed, 25 Aug 2004 18:59:30 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-100-884.area3.spcsdns.net ([68.245.136.141]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C09Y4-0003nT-BT for ietf-mxcomp@imc.org; Wed, 25 Aug 2004 21:59:39 -0400 Message-ID: <412D43C6.5060507@solidmatrix.com> Date: Wed, 25 Aug 2004 21:58:30 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "IETF MXCOMP (E-mail)" Subject: DEPLOY: IPR License and Custom Software Development Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > From: Ted Hardie ... > An important part of the IETF process is that we treat all of its participants > as behaving in good faith. If the license terms offered cause difficulties > for you, please state how the terms impact your development and deployment. > (Eric's description of the sublicensing issue for Sendmail is a good example > here, and I encourage you to read it as a potential model). I have been lurking but in response to this message, I would like to submit my opinion as to why this specific license might cause problems in deployment. My company develops software for managing small service businesses including management of internal company email, and internal/external email gateways. Our deployment concerns are outlined below. This message is intended as input into the Final Call process. 1. License can be revoked Our first concern is that we do not want to sign a license with a third party which will affect our main product and systems, especially if such license is revocable. Specifically, we do not want to end up ripping Sender-ID code out of our software or a modified open source package running our systems if the licensor decides that we are in breach (as per section 3), and having to pay if we don't rip it out. While it is possible that anyone can sue us for patent infrignment, the fact that we have identified ourselves via a signed agreement makes this much easier. We are also concern about the fact that the license terms can be changed. We do not want to be forced to pay for the use of Sender-ID code a year from now or face the expensive work of ripping code out. 2. Legal Counsel is Expensive. Being a small business we do not have the monetary resources to afford appropriate legal counsel to interpret the license, how it applied to our software, and to any open source software we may use or develop. The same situation applies to many open source authors who cannot afford legal counsel or the expense of a lawsuit. At the same time we do not wish to blindly sign a piece of paper which we do not know the impact of. Recommending contacting the licensor's legal department as suggested is not an option either. First of all, being that they have the licensor's best interests in mind, their legal advice may not be reliable. Second, in my personal experience Microsoft's legal department is very slow to answer. I am still waiting for answer to a related IPR issue, which I first emailed the legal department in early March. Six months for answer when there are deadlines, is not good enough. 3. Discouragement of Open Source Software. The whole point of open source software is ability to freely modify code. In this specific instance, the piece of code that implements Sender-ID, would require a new signed license from the licensor if it is changed. This discourages the use of open source software, for both our company and our customers. 4. Sub-licensing. We occasionally work with customers and partners to create customized software. The fact that this license is not sub-licensable, creates a greater burden on our customers and ourselves, and discourages our customers from seeking our consulting services. 5. Privacy. The license explicetely states the privacy of the licensee is not to be expected and that licensee's information maybe published on a website. We, our customers, and our partners, do not wish to have our information published in such matter. Additionally, we are also afraid that this information may be available to other parties that may seek to sue the licensor for infrigment, and have such list readily available to add to their lawsuit. Even if this list is not public, it is still obtainable under a subpoena. 6. Suggested Changes. I would highly recommend taking out the requirement to sign a separate license for each implementor which seems to be the main problem. Substituting a EULA-like agreement might be better. Otherwise, I would recommend against approving this standard with this license until these concerns are resolved, since all of the issues listed above will discourage parties from implementing and testing this standard. Sincerely, Yakov Shafranovich From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 00:09:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21268 for ; Thu, 26 Aug 2004 00:09:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q3kJ8J040551; Wed, 25 Aug 2004 20:46:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q3kJip040550; Wed, 25 Aug 2004 20:46:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q3kJgB040544 for ; Wed, 25 Aug 2004 20:46:19 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7Q3kQIV003413 for ; Wed, 25 Aug 2004 20:46:26 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Aug 2004 20:46:26 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Wed, 25 Aug 2004 20:46:24 -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: > Now, at the IETF-60 meeting, it was pointed out that qmail has a > quirky license. (Many/most people do not consider qmail to be Open > Source Software because of its license.) Basically, only the > original author can modify qmail, all other changes must be > distributed separately and applied as patches. As the original author > hasn't updated qmail for years, almost all qmail users take the > original source and apply one or more sets of "patches" in order to > create an MTA (mail server) which they can use. > Would a qmail patch author qualify as a "licensed implementation" and > thus someone who takes qmail and creates a derivative work of it by > apply the patch qualify as an "end user"? > If not, wouldn't this mean that users of qmail that want to support > SenderID (which we hope will be all of them) need to get a license > from Microsoft? Or an alternative MTA :-) > Section 1.2 gives the definition of a "Licensed Implementation", > which, in the second of the two (ii) clauses, requires you to have > branded trademark. Do any patches have trademarks? Apache began as a set of patches to the NCSA web server so it would appear to be the case. There are several cases where a software product has been created as a configuration of another system, why not distribute the configuration in patch form? If I had to patch Qmail the way I would do it is as follows: 1) First write a patch that allows the server to load in sharable object libraries as part of the startup procedure. 2) Write a second patch that causes the sharable object libraries to be called during the appropriate processing stages (c.f. the schemes used to load plugins into Netscape servers, IIS etc.) 3) Write the Sender-ID plug in as a separate stand alone sharable object library that is initialized and called from QMAIL. 4) Get a Sender-ID license for the plug in separately from the patches required to make it work. Incidentally, I would do it that way regardless of the license restrictions. If the code is written in the right way you can shed and reinstall libraries without having to shut down mail processing. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 00:10: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 AAA21293 for ; Thu, 26 Aug 2004 00:10: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 i7Q3iCJF040418; Wed, 25 Aug 2004 20:44: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 i7Q3iClg040417; Wed, 25 Aug 2004 20:44:12 -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 i7Q3iCTD040409 for ; Wed, 25 Aug 2004 20:44:12 -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 i7Q3iG7T004326 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 25 Aug 2004 20:44:16 -0700 Date: Wed, 25 Aug 2004 20:44:16 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: ietf-mxcomp@imc.org Subject: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) 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: With regards to the Sender ID record being published as a TXT record for the FQDN hostname (in a TXT record for domain.com), real world usage is already showing that this dataspace is becoming populated with spfv1 records deployed by many sites in order to increase deliverability to certain very large ISPs and others. By publishing spfv2/pra records in the same dataspace (domain.com), we are effectively halving the usable UDP packet size for responses, since a TXT query for domain.com will try to return *all* TXT records for domain.com in one record. Real world deployment experience is that most network firewall operators do not allow DNS queries over TCP except to trusted secondaries. The indicated wishes of large ISPs is that they do not want to have to fall back to a TCP connection anyways for verifying incoming mail because it will cause too much overhead. My concern was mollified by people pointing out that "even AOL's SPF record can fit in 160 bytes, so they can almost squeeze three parallel records in to the same TXT UDP response packet." In the past couple of weeks I have talked to a few *major* .com sites (financial, media, consumer) whose real-world outbound architecture is waaaaaaaay more complex than AOLs. In particular, with the number of global sites they run, the number of third party delivery services they contract with, and their general focus being on running their business instead of their email, many of these large companies are going to have trouble fitting a single SPF-like record in a UDP-sized query, let alone fitting it in half that size. My concern for Sender ID is that since SPF has already claimed the FQDN TXT dataspace for itself (and since SPF is seeing parallel adoption regardless of where Sender ID goes), trying to stuff a second Sender ID record in the same data space will be problematic for some, and if we ever try to evolve this to a third version then it will *never* fit. The solution I would suggest is to put spfv2/pra records in a sub-domain such as _marid.company.com. While it would be nice to recommend that people begin allowing TCP DNS queries, it is unlikely that the highest volume sites would ever want to implement such. This is a concern that has been voiced to me by several major sites that are exactly the same set of sites we use as examples for where we need to stop phishing from. They are most likely going to publish *both* spfv1 and spfv2/pra records, and their initial investigation of their email architectures has indicated that those records are going to be pushing this real-world 240-byte limit (a 480 byte effective UDP packet split in two) -Rand From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 00:18:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21531 for ; Thu, 26 Aug 2004 00:18:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q3uDbN040983; Wed, 25 Aug 2004 20:56:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q3uD16040982; Wed, 25 Aug 2004 20:56:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q3uDb1040975 for ; Wed, 25 Aug 2004 20:56:13 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7Q3uKt5003825 for ; Wed, 25 Aug 2004 20:56:20 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Aug 2004 20:56:19 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: Can there be an early decision on the SenderID license? Date: Wed, 25 Aug 2004 20:56:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Right now, we are supposed to be reviewing all of the documents. > However, as demonstrated in the "DEPLOY/IPR: Fundamental > Disagreements, or Get On With It" thread, there doesn't seem to be a > rough consensus that the SenderID license is acceptable. (Actually, > there appears to be a rough consensus that it isn't acceptable.) I have yet to see a statement that makes a valid legal argument that the license terms prohibit open source distribution. The license terms are at least as open as the terms which the IETF has accepted in the past. This is a quasi-judicial proceeding, we have to proceed on the basis of established facts. About the only fact I see a consensus on is that none of us are lawyers. Larry Lessig is a lawyer, lets give him a call and hit his folk up for some pro bono. First I would suggest that those wanting to make the argument that the license terms are not acceptable put them in a form that is more coherent than that advanced so far. In particular paying close attention to the fact that what is wanted is a license to redistribute software without let or hinderance. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 00: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 AAA21552 for ; Thu, 26 Aug 2004 00: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 i7Q3x2E4041095; Wed, 25 Aug 2004 20:59: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 i7Q3x2E1041094; Wed, 25 Aug 2004 20:59:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.emkhost.com (h-68-165-182-61.lsanca54.covad.net [68.165.182.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q3x1V6041087 for ; Wed, 25 Aug 2004 20:59:01 -0700 (PDT) (envelope-from waitman@emkdesign.com) Received: from [192.168.0.102] (h-68-165-182-62.lsanca54.covad.net [68.165.182.62]) (authenticated bits=0) by mail.emkhost.com (8.13.0/8.13.0) with ESMTP id i7Q3ukD3003140 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 25 Aug 2004 20:56:46 -0700 (PDT) Message-ID: <412D5FFB.4030200@emkdesign.com> Date: Wed, 25 Aug 2004 20:58:51 -0700 From: Waitman C Gobble II Reply-To: waitman@emkdesign.com Organization: EMK Design User-Agent: Mozilla Thunderbird 0.6 (X11/20040613) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Can there be an early decision on the SenderID license? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EMK-Design-MailScanner-Information: Please contact the ISP for more information X-EMK-Design-MailScanner: Found to be clean X-MailScanner-From: waitman@emkdesign.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > >However, it seems to me to be a wise use of this working groups time >to decide the license issue early, and then move on from there. > > >Thoughts? > > Hello I didn't have strong feelings about the license either way until I read the comment someone made about the issues regarding shipping Sender-ID stuff with operating systems such as various linux and bsd distros. It would seem likely that anything that provides an SMTP related service could be kept out of the distro. Of course, I understand that the end user could enter into a license agreement and get the software, or perhaps it could be distributed with the requirement that you had to license it before using it. Just sounds like bad karma to me. Do you want to download qmail or something but have to go get a license from MS to run it? But thinking about it from a different point of view - It sounds like to use _any_ SMTP server you would essentially have to get a license from MS. (Presuming that Sender ID is mainstream) Waitman Gobble From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 01:22: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 BAA23828 for ; Thu, 26 Aug 2004 01:22: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 i7Q4p11K043816; Wed, 25 Aug 2004 21:51: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 i7Q4p1Ak043815; Wed, 25 Aug 2004 21:51:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q4owsT043777 for ; Wed, 25 Aug 2004 21:50:58 -0700 (PDT) (envelope-from george@m5p.com) Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by mailhost.m5p.com (8.12.11/8.12.11) with ESMTP id i7Q4oxtk074739 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Aug 2004 21:51:00 -0700 (PDT) Received: (from defang@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7Q4ljPt074728 for ; Wed, 25 Aug 2004 21:47:45 -0700 (PDT) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (MIMEDefang) with ESMTP id i7Q4lj1W074727; Wed, 25 Aug 2004 21:47:45 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7Q4liTW025283; Wed, 25 Aug 2004 21:47:44 -0700 (PDT) Date: Wed, 25 Aug 2004 21:47:44 -0700 (PDT) From: George Mitchell Message-Id: <200408260447.i7Q4liTW025283@m5p.com> To: ietf-mxcomp@imc.org, pbaker@verisign.com Subject: RE: Can there be an early decision on the SenderID license? In-Reply-To: X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I have yet to see a statement that makes a valid legal argument > that the license terms prohibit open source distribution. > > The license terms are at least as open as the terms which the > IETF has accepted in the past. > > This is a quasi-judicial proceeding, we have to proceed on the > basis of established facts. About the only fact I see a consensus > on is that none of us are lawyers. I believe this is an erroneous restatement of the problems we are currently facing: 1. Exactly what is covered by this license? I assumed that, on August 23, we would know the answer to this question. Sure, we got a look at the license, but it raised more questions than it answered. 2. Assume for the moment that the license does not prohibit open source distribution -- at least, not in so many words. Does it still encumber open source distribution to such an extent as to make it infeasible? 3. Although the license claims to be royalty-free, what is the licensee giving up which has value other than monetary? Is this really a quasi-judicial proceeding? I think it's a bunch of people trying to solve a technical problem without getting stymied by intractable non-technical considerations. Quite a few people have raised their hands in objection to this license so far. At least some of them believe the current problem, forgery of sender domain names, can be abated without recourse to whatever technology it is that is being licensed. Might this position in fact be the current rough consensus of the group? -- George Mitchell From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 04:10:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14889 for ; Thu, 26 Aug 2004 04:10:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q7htBM080093; Thu, 26 Aug 2004 00:43: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 i7Q7htkJ080092; Thu, 26 Aug 2004 00:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q7hsM1080084 for ; Thu, 26 Aug 2004 00:43:54 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040826074353.PTKI15743.tomts22-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 26 Aug 2004 03:43:53 -0400 From: "John Glube" To: "'Rand Wacker'" , Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Thu, 26 Aug 2004 03:43:32 -0400 Message-ID: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7Q7hsM1080087 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Rand, From your discussions with managers of large email infrastructures, who are seeing a problem with packet size; along with the big ISPs who are not interested in using TCP to receive email because of cost, does it make more sense not to change the version string? Let me phrase the question this way. My understanding from listening to the audio of the face to face Marid in early August, one of the major rationales for a version string change was implementation. It was felt folks who implemented SPF were early adopters. By changing the version string, this would freeze SPF and folks would move ahead with Sender-ID. What you are telling us is the direct opposite. Some of the Big ISPs are using SPF to detect email forgery at the pre data stage, while telling folks, do you want less content filtering? Publish an SPF record. (Of course this achieves the desired objective of sender authentication, thwarting spoofing and other steps taken to hide identity, by getting everyone out in the open.) With the premise of enhanced email delivery, along with protecting against domain spoofing, SPF is gaining implementation momentum among domain owners. This leads one to the conclusion the solution is instead of creating a sub domain for Sender-ID records, rather it is not to change the version string. Why? It seems the theory behind the justification for the change does not reflect reality. Thoughts? Comments? John P.S. Another question. Since the Big ISPs do not want to use TCP to check authentication for email delivery, does this mean from a practical perspective, the Big ISPs would prefer to create a mirror data base of authentication records within their own networks and when a domain owner makes a change, the domain owner's DNS server could propagate the change through out the mirrored sites? Please excuse my naiveté if I have asked a dumb question. John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Rand Wacker Sent: August 25, 2004 11:44 PM To: ietf-mxcomp@imc.org Subject: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) With regards to the Sender ID record being published as a TXT record for the FQDN hostname (in a TXT record for domain.com), real world usage is already showing that this dataspace is becoming populated with spfv1 records deployed by many sites in order to increase deliverability to certain very large ISPs and others. By publishing spfv2/pra records in the same dataspace (domain.com), we are effectively halving the usable UDP packet size for responses, since a TXT query for domain.com will try to return *all* TXT records for domain.com in one record. Real world deployment experience is that most network firewall operators do not allow DNS queries over TCP except to trusted secondaries. The indicated wishes of large ISPs is that they do not want to have to fall back to a TCP connection anyways for verifying incoming mail because it will cause too much overhead. My concern was mollified by people pointing out that "even AOL's SPF record can fit in 160 bytes, so they can almost squeeze three parallel records in to the same TXT UDP response packet." In the past couple of weeks I have talked to a few *major* .com sites (financial, media, consumer) whose real-world outbound architecture is waaaaaaaay more complex than AOLs. In particular, with the number of global sites they run, the number of third party delivery services they contract with, and their general focus being on running their business instead of their email, many of these large companies are going to have trouble fitting a single SPF-like record in a UDP-sized query, let alone fitting it in half that size. My concern for Sender ID is that since SPF has already claimed the FQDN TXT dataspace for itself (and since SPF is seeing parallel adoption regardless of where Sender ID goes), trying to stuff a second Sender ID record in the same data space will be problematic for some, and if we ever try to evolve this to a third version then it will *never* fit. The solution I would suggest is to put spfv2/pra records in a sub-domain such as _marid.company.com. While it would be nice to recommend that people begin allowing TCP DNS queries, it is unlikely that the highest volume sites would ever want to implement such. This is a concern that has been voiced to me by several major sites that are exactly the same set of sites we use as examples for where we need to stop phishing from. They are most likely going to publish *both* spfv1 and spfv2/pra records, and their initial investigation of their email architectures has indicated that those records are going to be pushing this real-world 240-byte limit (a 480 byte effective UDP packet split in two) -Rand --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 04: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 EAA15147 for ; Thu, 26 Aug 2004 04: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 i7Q8LxGr089680; Thu, 26 Aug 2004 01:21: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 i7Q8LxYH089679; Thu, 26 Aug 2004 01:21: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 (mail.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q8LxtS089666 for ; Thu, 26 Aug 2004 01:21:59 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 04:26:33 -0400 Received: from ([65.10.104.150]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2810986468; Thu, 26 Aug 2004 04:26:31 -0400 Message-ID: <005301c48b45$6bcc6c60$6401a8c0@hdev1> From: "Hector Santos" To: "Eric Allman" , References: <4B43B270D7B343DB56E55E0B@knecht.sendmail.org> Subject: Re: DEPLOY: Santronics position on Sender Id Date: Thu, 26 Aug 2004 04:19:32 -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 Eric, First, where is the patent? No patent has been issued. Second, I have serious issues for the merits of the patentability of the weak concepts involved. Any good prudent lawyer could fight this patent with ease. Third, there is little to no benefit, in fact produces more issues than it resolves. So considering 1, 2 and 3, I have a problem with given credence to a weak idea. Forth, if it was patented, it is quite conceivable that a "judge" can deem this PUBLIC DOMAIN just for the fact that it can have world wide implications. It has happen before. Case in point: HAYES and AT Command set. Fifth, Not all products are OPEN SOURCE! So in short, in no way would we subject the future of our mail product lines based on Microsoft "patents." We have never done it and we will never will. We have a very successful anti-spam system. Why would be want to alter this now? The only reason we were here in the first place was to help make SPF the standard. Not get into idiotic IPR issues. As far as I am concern, this is has been a big waste of time in my book. All this process has done is raise the bar for a continuation of exploration for better ways. I would be among the first to work with a technology that was sound, even if it was one that was going to impose serious redevelopment cost which this will most definitely will do for those who support it. However, we will no longer subject ourselves to this moronic IPR issue that quite frankly is technologically flawed. It doesn't even address CANSPAM nor the full address. So why bother? Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Eric Allman" To: Sent: Monday, August 23, 2004 10:39 PM Subject: DEPLOY: Sendmail position on Sender Id > > Sendmail, Inc. has worked with Microsoft to help them produce a > patent license that will be acceptable for ourselves, the IETF, and > the open source community at large. This message summarizes our > position. The following discussion refers to the Royalty Free Sender > ID Patent License (RFSIPL), dated 23 August. Harry has already > posted it to the list, although it will take a few days to appear on > the Microsoft web site. > > The executive summary is that we believe that the Sender ID > technology is promising, and will hopefully be adopted. We believe > that although not ideal, the RFSIPL and associated IP disclosures > satisfy the IPR requirements of the IETF and are compatible with most > major open source licenses. It would be extremely disappointing if > this potentially useful technology to combat fraud and spam failed > for reasons unrelated to its technological merits. > > The revisions in the RFSIPL have clarified several important issues. > Notably, it is now explicit that recipients of a Sender ID > implementation who do not intend to redistribute the code do not need > to get a patent license to use such an implementation. However, the > license is not without restrictions. > > Sublicenseability > > Our key concern is that anyone redistributing open source code with > Sender ID technology would need to execute a license with Microsoft > to remain within the letter of the current license. Sections 2.1 and > 2.2 provide patent license grants for object and source code > respectively; in both cases they are non-sublicenseable. This > restriction means that anyone distributing or redistributing Licensed > Implementations (that is, Sender ID) should contact Microsoft for a > patent license. This process is reasonably painless, requiring only > that the licensee fax the signed license (available at > ) to Microsoft. None > the less, any time a license is involved friction is added to the > process. > > Defensive Suspension > > A somewhat lesser concern is specific to the GPL: it has been claimed > that section 6 of the GPL (version 2) prohibits invalidation of a > license on the basis of a patent infringement claim as required by > section 2.4 ("Defensive Suspension") of the RFSIPL. We believe this > to be a reasonable term, common in many open source licenses (e.g., > the Mozilla Public License, the IBM Common Public License, the Apache > License). It is notable that many programs with similar license > terms are already packaged in GPLed distributions, so the > incompatibility claim is clearly not universally believed. > > Reciprocal Patent License > > Section 2.3 of the RFSIPL extends the patent license grant to apply > to the licensee as well as the licensor. In other words, if the > licensee also has a patent on IP necessary to implement Sender ID, > then they in turn grant the rights to that patent under the same > terms (including royalty-free and non-sublicenseability) to all other > licensees. This ensures that any additional IP required from other > suppliers will also be available royalty-free. We believe this to be > a net positive term for the interests of the community. However, it > may be expected that some organizations will want to review their own > patent portfolio prior to signing, which adds additional friction. > > License Compatibility > > Viewed from the license compatibility perspective, our legal counsel > has opined that the RFSIPL is consistent with the Sendmail Open > Source License, and we believe it is also compatible with the BSD > license, since neither of them refer to patents at all (nor does the > Python license or the Artistic License, to name a few additional > examples). Some other Open Source licenses explicitly state that it > is the recipient's duty to acquire any necessary IP rights needed to > run the software (e.g., the IBM Common Public License). In all such > cases we think it is probably safe to presume compatibility from a > "letter of the law" perspective, if not the "intent" perspective. > > The major exception to this may be the GPL, both as regards Defensive > Suspension as noted above, and as regards the non-sublicenseability > clause. Even this isn't completely clear; Eben Moglen (FSF Counsel) > has published an example of at least one case (the Office 2003 XML > Schema) where he found such conditions acceptable from the GPL legal > perspective, albeit not within the original intent > (http://www.theregister.co.uk/2003/11/18/fsf_eases_microsoft_schema_patent/) . > In particular, the article says: > > "I don't think the alarm is justified," the FSF's pro bono > counsel Eben Moglen told us last night. "This is not a > license that I would like to accept; Microsoft is saying we > might have some patents. But it's not a problem if Microsoft > is making it available to everyone to make use and sell. > > The Sendmail Perspective > > The non-sublicenseability element does present certain practical > problems for Sendmail. On the open source side, the sendmail MTA is > routinely bundled into other larger systems, notably open source > operating system releases such as Linux and BSD distributions as well > as commercial closed-source systems such as Solaris and AIX. Bundlers > would need to execute their own copy of the RFSIPL. Those systems > are in turn sometimes incorporated into other products, which would > seemingly require another layer of patent licenses, and so on down > the tree. As a practical matter, this makes the decision to include > sendmail with Sender ID into their release more problematic. This is > obviously not desirable from our point of view. > > On the commercial side, we have end user customers who install and > use our product and channel partners who rebrand and/or redistribute > our product. Although the RFSIPL does not require us to demand a > license from any of our customers, our customers do demand IP > disclosure as part of sales contracts. End-user customers are fine, > since the RFSIPL permits them to use Sender Id without executing a > license. But all of our channel partners would have to sign the > RFSIPL to be within the terms of the license. They will want to have > their own lawyers review the license, just as we have. This is not > going to sit well with our partners, who expect us to take care of > IPR issues when we bundle a technology into our product. This > requires additional effort on the part of both ourselves and our > partners and thus lengthens our sales cycle for these important > customers. > > While these are pragmatic rather than legal reasons, our likely > decision at Sendmail will be to distribute our Sender ID > implementation as a separate package that is not required to run the > sendmail MTA under a distinct (possibly modified) Sendmail Open > Source license. Open source users will have the option of > downloading and installing the Sender ID package should they want the > additional functionality. Bundlers will be able to choose whether > they want to include the Sender ID technology or not, but will still > be able to use the base sendmail MTA without additional IPR issues. > > Considerations for MARID > > In regards to the MARID Working Group of the IETF, we believe that > the IPR disclosure requirements of the IETF (RFC3668) are consistent > with the RFSIPL, and hence we do not see any by-the-book impediment > to proceeding forward using this license. In fact, Microsoft has > gone beyond the strict requirements of RFC3668, which do not require > royalty-free licenses, nor even any explicit disclosure of licensing > terms at all (section 6.5). However, we understand that email is one > of the most fundamental protocols on the Internet, and there may be > reluctance to rely on any encumbered intellectual property, even with > the promise of royalty-free licenses to all users. > > It is worth noting that IP encumbrances for popular standards are not > a new problem. For example, the W3C Patent Policy does not require > patent licenses to be sublicenseable. In his new book "Open Source > Licensing, Software Freedom and Intellectual Property Law", Larry > Rosen states (pp 309-310): > > Not every requirement of the W3C Royalty-Free license policy > is friendly to open source, however. For example, because > such licenses are "non-assignable" and "non-sublicenseable" > each licensee theoretically must obtain a license directly > from the patent owner. In practice hardly anybody does and > because the W3C member commitments to each other, nobody > needs to fear that the royalty free patent license wouldn't > be available to anyone who actually wanted one. > > He does however say that such patent licenses need to be royalty-free > (pp 306-307), as is the RFSIPL. > > Recommendation > > Although the RFSIPL is not ideal, we believe that it satisfies the > requirements of the IETF and is compatible with a broad range of Open > Source licenses. Sender ID seems to be a technologically appealing > option in the IP address based authentication space. There is great > urgency in the marketplace right now to combat fraud, phishing, and > spam. As a result of these considerations, we recommend that MARID > proceed with Sender ID. > > From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 04:46:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15311 for ; Thu, 26 Aug 2004 04:46:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8O1tg090188; Thu, 26 Aug 2004 01:24:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q8O1mS090187; Thu, 26 Aug 2004 01:24:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8O05n090164 for ; Thu, 26 Aug 2004 01:24:01 -0700 (PDT) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id i7Q8NtYZ012414; Thu, 26 Aug 2004 08:23:55 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.12.9-20030917/8.12.9) with ESMTP id i7Q8NtmP002654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2004 10:23:55 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i7Q8NsRu002653; Thu, 26 Aug 2004 10:23:54 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Thu, 26 Aug 2004 10:23:54 +0200 From: Koen Martens To: Ted Hardie Cc: Ryan Ordway , IETF MARID WG Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Message-ID: <20040826082354.GB2545@metro.cx> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> <20040825210625.GM2397@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 X-Helo-Milter: checked X-Helo-Reject: No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7Q8O15n090181 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, Aug 25, 2004 at 03:04:08PM -0700, Ted Hardie wrote: > An important part of the IETF process is that we treat all of its > participants > as behaving in good faith. If the license terms offered cause difficulties > for you, please state how the terms impact your development and deployment. > (Eric's description of the sublicensing issue for Sendmail is a good example > here, and I encourage you to read it as a potential model). > > Stating that the _holder_ of the IPR is the problem, rather than the _terms_ > of the license, is very different. That is contrary to the principle that > we > treat all participants as behaving in good faith. Please focus on the > terms, > not the holder. Ok, let me rephrase that: FWIW, my hand is raised. I oppose against an internet standard that requires a contract with a multinational company to implement, specifically a contract of which the legal consequences to my operations are unclear and can only be safely ascertained by hiring a lawyer. 'Good faith' is a highly subjective term, I can't assume anything about this contract without consulting a lawyer. When I'm being told 'go contact your attorney' I can not assume good faith. Good faith doesn't need lawyers or law suits. The fact that this license does (note that it mentions 'sue' a couple of times), violates (to me at least) the definition of 'good faith'. Koen Martens -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 04:59: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 EAA16284 for ; Thu, 26 Aug 2004 04:59:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8dZbA094737; Thu, 26 Aug 2004 01:39:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q8dZqO094736; Thu, 26 Aug 2004 01:39:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8dYrU094725 for ; Thu, 26 Aug 2004 01:39:34 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id B052826C092; Thu, 26 Aug 2004 10:39:55 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 085FC26C091; Thu, 26 Aug 2004 10:39:55 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7Q8du93857054; Thu, 26 Aug 2004 10:39:56 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 3DCF6FACE; Thu, 26 Aug 2004 10:39:56 +0200 (CEST) Date: Thu, 26 Aug 2004 10:39:56 +0200 From: Stephane Bortzmeyer To: Ted Hardie Cc: Koen Martens , IETF MARID WG Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Message-ID: <20040826083956.GA24470@nic.fr> References: <700EEF5641B7E247AC1C9B82C05D125D0553EA@srv1.pan-am.ca> <1093455341.17218.12.camel@vodka> <20040825210625.GM2397@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 03:04:08PM -0700, Ted Hardie wrote a message of 23 lines which said: > Stating that the _holder_ of the IPR is the problem, rather than the > _terms_ of the license, is very different. I believe that it is what Koen Martens meaned. I take the liberty to rephrase its sentence as: I oppose against an internet standard that requires a contract with XXX to implement. (Where XXX is any company.) And I agree with the above sentence. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 05: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 EAA15164 for ; Thu, 26 Aug 2004 04:41:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8IFkm088450; Thu, 26 Aug 2004 01:18: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 i7Q8IFIH088449; Thu, 26 Aug 2004 01:18:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8IEeX088376 for ; Thu, 26 Aug 2004 01:18:14 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 20B3326C088; Thu, 26 Aug 2004 10:18:27 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id C052226C08D; Thu, 26 Aug 2004 10:18:16 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7Q8II93822990; Thu, 26 Aug 2004 10:18:18 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 1123AFACE; Thu, 26 Aug 2004 10:18:18 +0200 (CEST) Date: Thu, 26 Aug 2004 10:18:18 +0200 From: Stephane Bortzmeyer To: Nate Leon Cc: IETF MARID WG Subject: Re: DEPLOY - reference implementation Message-ID: <20040826081818.GA22007@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 11:40:15AM -0700, Nate Leon wrote a message of 10 lines which said: > Is there a reference implementation published for Sender ID? You can say that every SPF implementation (there are many, see http://spf.pobox.com/downloads.html) is an implementation of Sender-ID's -protocol. For -pra, the implementation seems trivial (so trivial that nobody should be able to patent the idea). From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 05:33:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17260 for ; Thu, 26 Aug 2004 05:33: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 i7Q99RZo002516; Thu, 26 Aug 2004 02:09: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 i7Q99RMj002515; Thu, 26 Aug 2004 02:09:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q99QCM002500 for ; Thu, 26 Aug 2004 02:09:27 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 8445726C086; Thu, 26 Aug 2004 11:09:48 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id BDA4526C087; Thu, 26 Aug 2004 11:09:47 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7Q99n93866546; Thu, 26 Aug 2004 11:09:49 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 1D7DCFACE; Thu, 26 Aug 2004 11:09:49 +0200 (CEST) Date: Thu, 26 Aug 2004 11:09:49 +0200 From: Stephane Bortzmeyer To: "Hallam-Baker, Phillip" Cc: "'IETF MARID WG'" Subject: Re: Can there be an early decision on the SenderID license? Message-ID: <20040826090949.GA26188@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 08:56:17PM -0700, Hallam-Baker, Phillip wrote a message of 27 lines which said: > I have yet to see a statement that makes a valid legal argument that > the license terms prohibit open source distribution. Strictly speaking, the Microsoft licence does not *prohibit* free software distribution. But it *seriously limits* its usefulness because people who want to exercice their rights by modifying the source code and redistributing it will need a licence. > The license terms are at least as open as the terms which the IETF > has accepted in the past. Then the IETF was wrong. Period. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 05:48: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 FAA17325 for ; Thu, 26 Aug 2004 05:48: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 i7Q9SGrt006941; Thu, 26 Aug 2004 02:28:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q9SGUw006940; Thu, 26 Aug 2004 02:28:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q9SFNt006924 for ; Thu, 26 Aug 2004 02:28:15 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 5C9DB26C078 for ; Thu, 26 Aug 2004 11:28:37 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 7EB0E26C071 for ; Thu, 26 Aug 2004 11:28:36 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7Q9Sc93871623 for ; Thu, 26 Aug 2004 11:28:38 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id EF986FACE; Thu, 26 Aug 2004 11:28:37 +0200 (CEST) Date: Thu, 26 Aug 2004 11:28:37 +0200 From: Stephane Bortzmeyer To: ietf-mxcomp@imc.org Subject: DEPLOY: why I don't want Sender-ID as it is (IPR claims) Message-ID: <20040826092837.GA27272@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I do not want Sender-ID to proceed as it is, giving the IPR claims on it. The licence suggested here is unacceptable because: * in practice, it limits free software implementations (because they would be no longer really free, since the user will not be able to modify and redistribute the software without a licence, and he will not have a licence if it uses the software for something else than Sender-ID). Section 2.2. * it gives a company an undeserved acknowledgment that they developed Sender-ID (in "recitals"). In addition to this, I agree with the following analysis and opinions: * Yakov Shafranovich "IPR License and Custom Software Development" http://www.imc.org/ietf-mxcomp/mail-archive/msg03639.html * Paul Iadonisi "Microsoft Patent license unworkable with GPLed MTAs" http://www.imc.org/ietf-mxcomp/mail-archive/msg03589.html * Mark Shewmaker "Re: Microsoft Royalty Free Sender ID Patent License" http://www.imc.org/ietf-mxcomp/mail-archive/msg03514.html Do note that I'm convinced that the patents (which are not available for reviewing, another issue) are futile and obvious and are invalidated by prior-art. But I have no time or money to start a legal action in a remote country. I believe that there is unfortunately only one choice: dropping -pra. Which means, in practice, going back to SPF-classic and starting to work on SPF-unified. Do note that I succeeded, following Ted Hardie's advice, in making my reasoning company-independent :-) But I cannot fail to note that there is no demonstrated will, from a certain company, to improve the licence since they don't even reply to emails sent to their official address. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 05:53:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17758 for ; Thu, 26 Aug 2004 05:53:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q9XSqK008436; Thu, 26 Aug 2004 02:33:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q9XSMv008434; Thu, 26 Aug 2004 02:33:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q9XR3g008416 for ; Thu, 26 Aug 2004 02:33:27 -0700 (PDT) (envelope-from SRS0=wCa/I6YQ=LQ=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7Q9XRKd016039 for ; Thu, 26 Aug 2004 11:33:27 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408260933.I7Q9XQ28016029@asarian-host.net> Date: Thu, 26 Aug 2004 09:33:27 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: Can there be an early decision on the SenderID license? X-Trace: 3VF15HIQTdq+Se4aPylULd4LgGVCLpmYUPZyHsjUNWuSNMbig9WPK9/ZHpwwV843x++wgI+fai4U+IWEWchwtQ== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQS2uZzFqW1BleBN9AQELkAgAjN+zjR+/evQiR/ZewTig22I3ceoK2pAi n+gMmOzfM79mIHSSmlmN4kcW2sV0Mnb55ovqKYYpJz6ZmqJAN7APCZkfaPYgfNGN 3TxYp2IwV6PjHGVro9ntPAuLMj+sarLTN+4hdxKnZjTKnywRGZF1YSnI1Ob1UY4V 2n2QuG46aGJq8rnh0eL1YNA67ErC9uxyhoEr8vqON4jxHoMVIz+rzTjq7KoK05Vv ppv/I25iz2Sdk4wZ5uWRdrUfqfSi2++RfBRClrPNvPhfcTfVRZL1A3aN1aNAyP+s vgbz4AYi5TvAFpecwkCnglcBZQmgr+A3lMhbCXxC7Ymz8AAU8ui1NA== =PP2k Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > I have yet to see a statement that makes a valid legal argument > that the license terms prohibit open source distribution. My worry (and, as seen through my non-legalese eyes, apparently shared by many), is not that the Sender-ID license is open, but that it is *too* open. :) Too open-ended, that is; leaving all sorts of vague, open-ended clauses in which Microsoft reserves the right to tighten the noose in the future. There is also a legitimate concern that Microsoft will usurp the use of SPF. Yes, I know, nowhere in the license does it explicitly say that they will; but there is no specific exclusion either, is there? No line that says, "The use of SPF is expressly not covered by this license." They sort of keep it in the middle. And since Sender-ID plans to use SPF checks too, there is no exact telling whether, at a later date, Microsoft will not suddenly decide that SPF is theirs too, as part of Sender-ID. > This is a quasi-judicial proceeding, we have to proceed on the > basis of established facts. And we have to proceed on the basis of examining what facts the licence allows Microsoft to establish in the future. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 06:16: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 GAA18831 for ; Thu, 26 Aug 2004 06:16: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 i7Q9t8kE013767; Thu, 26 Aug 2004 02:55: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 i7Q9t8Hg013766; Thu, 26 Aug 2004 02:55:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q9t74W013755 for ; Thu, 26 Aug 2004 02:55:07 -0700 (PDT) (envelope-from SRS0=wCa/I6YQ=LQ=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7Q9t7U4016684 for ; Thu, 26 Aug 2004 11:55:07 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408260955.I7Q9T76R016673@asarian-host.net> Date: Thu, 26 Aug 2004 09:55:07 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY - reference implementation X-Trace: Bxwot77K7g37dg2d2f1wG1g5L1LmI+7vEJts1HCDJo4sTS5Yb2LyZLW/jIA9EVoim6KbEwac9ZFSzAfn4FnUEQ== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <20040826081818.GA22007@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQS2zezFqW1BleBN9AQHYYgf/Tg8K8LGcSwasxzlGNGLDF0+O20zJ/fLj stj3pGAJwxUtTwGgNvTvWkWG863pXp8a3DBx6wmDmYURjKKmK8JdWnyhqFWvccf5 XRPF0BlC1tLHHWu+jE5ZqaYGXrYOEQUPU3EYThUVVSRn/QUvIDh7NVoWkLATLQzR 6J6XIrB5iAQrl1+dXZll3qm60nkdQ4/qMnjeS0hF78pPdclDJoXWyAHjmCTSEzJU MS1NFJAWj3nBCDFvITSB/Fnr1yWFhOC6dPRoch2exmREAzEG9bhpjrwYAsmuDpe+ msVUMS2PeO71+nigCC97XE/WTZlu56dUkI+J/Orc9WWTNFajpAncsQ== =WTu9 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: >> Is there a reference implementation published for Sender ID? > > You can say that every SPF implementation (there are many, see > http://spf.pobox.com/downloads.html) is an implementation of > Sender-ID's -protocol. Yep, Microsoft would love that, wouldn' they? The reality, however, is that Sender-ID is an implementation of SPF! See? Any license which allows one company to usurp/claim as their own the open-source work of others, should be massively boycotted. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 06:46:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20274 for ; Thu, 26 Aug 2004 06:46:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QAMd8m020240; Thu, 26 Aug 2004 03: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 i7QAMdO9020239; Thu, 26 Aug 2004 03:22:39 -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 i7QAMd2p020224 for ; Thu, 26 Aug 2004 03:22:39 -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 34A81414D2 for ; Thu, 26 Aug 2004 03:22:38 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Thu, 26 Aug 2004 03:22:38 -0700 (PDT) Message-ID: <1160.64.142.13.68.1093515758.squirrel@harry.mail-abuse.org> Date: Thu, 26 Aug 2004 03:22:38 -0700 (PDT) Subject: DEPLOY: PRA Identity Untrustworthy 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 Goal- Validate identities as a basis for reputation checks. Sender-ID identities are assumed from RFC2822 message content selected by way of the PRA algorithm, and confirmed with an anonymous MTA remote client address being within the prescribed Mail Channel. Problem: Many domains share common MTA servers. Some of this sharing may occur as a result of transparent interception of SMTP traffic, as example. This technique and other practices that relay mail is not well addressed within the Sender-ID draft. Sender-ID tends to consider validation being end-to-end, but mail is often relayed and this aspect of mail is not properly accommodated. This interception technique is an example of a relay practice that is highly effective at preventing abusive mail, but depends upon low transactional overhead to handle high volumes. An interception server often does little more than log SMTP errors for review. Network providers using this method can detect abnormal levels of refused mail evidenced in the logs to quickly isolate abusers. Sender-ID requires public DNS records to prescribe the Mail Channel. A shared MTA may not be apparent unless compared with other domains, so the recipient should assume all Mailbox Domains may share an outbound MTA. Miscreants can discover these shared MTA servers by comparing public records. Should the Mailbox Domain also publish "open-ended" records for the prescribed Mail Channel, this too will be apparent to miscreants. Any message delivered to the shared MTA initially outside the prescribed Mail Channel, will then appear as being within the Mail Channel as the message is relayed. The same problem of "validation promotion" can happen when the shared MTA fails to perform Mail Channel checks against each PRA Mailbox Domain. There is nothing within Sender-ID to notify a recipient the Mail Channel has failed to perform needed checks, or that the Mail Channel is being shared in the case of an "open-ended" record. If a miscreant decided to market sexual aids falsifying such a Mailbox Domain, this identity could be seen as fully validated while not prevented by the published Mail Channel records. Just as a lapse in Mail Channel checks may occur within an outbound relay, the same problem may also occur within an inbound relay. In both cases, a presumption of a Mail Channel check allows undetected spoofing. Should a reputation service also presume Mail Channel checks were made or that the Mail Channel is not being shared, then innocent entities, through no action of theirs, may find their mail blocked or filtered. If the reputation service persists in efforts to stop abuse based upon false assumptions of the reliability of Sender-ID identities, such will likely require legal resolution. Sender-ID fails to recognize the message broker, and not the message, is the verifiable entity that can be safely held accountable. Reputation services must consider the MTA, the message broker, as being the entity to be validated and held accountable. Sender-ID has created a false impression Mailbox identification is trustworthy. This places every entity identified using the PRA algorithm at risk of being blacklisted or filtered, as the recipient does have expectations the PRA algorithm is trustworthy. Even if Mail Channel prescription checking was initially attempted by the provider, the potential for a DoS attack, with the required high overhead, places this check vulnerable to being removed as a means to preserve vital mail services. The PRA algorithm offers no means to verify the integrity of the Mail Channel checks. The PRA algorithm also offers no means to discover MTAs being shared with other domains. The PRA Mailbox Domain can be spoofed within the realm of the recipient, as well within the realm of the sender, but there is no means with PRA identities to locate which MTA is at fault. If the PRA domain publishes an "open" list, by appending "?all" as example, and there are shared MTAs on the outbound path, the PRA identity offers no means to differentiate between a message originating within the prescribed Mail Channel from those outside the prescribed Mail Channel, if submitted to a shared MTA, even if the prescribed Mail Channel checks are made at the shared MTA. The use of the PRA to assess reputations would be hazardous, as the PRA identity is untrustworthy. An alternative illustrated in: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt Rather than relying upon the PRA RFC2822 Mailbox Domain validated by anonymous client addresses, an authenticated EHLO domain if validated offers an accountable identity, as it identifies the message broker. This can be accomplished without adding a single additional DNS lookup, but rather by supplanting an address record lookup. http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-01.txt From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 07:34:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22969 for ; Thu, 26 Aug 2004 07: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 i7QBCYG2030896; Thu, 26 Aug 2004 04:12: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 i7QBCYF1030895; Thu, 26 Aug 2004 04:12:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QBCPpm030867 for ; Thu, 26 Aug 2004 04:12:34 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 8E0D826C07C; Thu, 26 Aug 2004 13:12:48 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 9F9CC26C071; Thu, 26 Aug 2004 13:12:47 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7QBCn93893775; Thu, 26 Aug 2004 13:12:49 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 35CFBFACE; Thu, 26 Aug 2004 13:12:49 +0200 (CEST) Date: Thu, 26 Aug 2004 13:12:49 +0200 From: Stephane Bortzmeyer To: Chuck Mead Cc: IETF MARID WG Subject: Re: DEPLOY - reference implementation Message-ID: <20040826111249.GA5702@nic.fr> References: <412CE5F4.5010006@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <412CE5F4.5010006@redhat.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 25, 2004 at 03:18:12PM -0400, Chuck Mead wrote a message of 34 lines which said: > So far as I am aware there is only one operational reference > implementation though it's only applicable to the 2821 headers (unless > someone more knowledgeable says different). Basically, Sender-ID is "get the PRA", then "get the PRD", send "apply SPF to the PRD". The last step is complicated but there are many free software SPF implementations. The first step is very simple, I attached my own implementation. Bug reports are welcome to show me where I've misread -pra. --TB36FDmn/VVEgNH/ Content-Type: application/x-python Content-Disposition: attachment; filename="PRA.py" Content-Transfer-Encoding: quoted-printable #!/usr/bin/python=0A=0A"""=0A=0AAIM: Implements the PRA (Purported Responsi= ble Address) algorithm=0Adescribed in Internet-Draft draft-ietf-marid-par-0= 0.txt.=0A=0AUSE: from the command line "python PRA.py < message" or from an= other Python=0Aprogram, see the __main__ as an example.=0A=0AREQUIRES: Pyth= on >=3D 2.2=0A=0ALICENCE: trivial work, not patentable, not licenceable.=0A= =0AWARNING: Microsoft claims a patent on the PRA algorithm. The author=0Adi= d not requested a licence.=0A=0AAUTHOR: Stephane Bortzmeyer =0A=0ABUGS: I did not find any :-) But bug reports are welcome.=0A=0A= VERSION: $Id$=0A=0A"""=0A=0Aimport email=0Aimport sys=0Aimport string=0A=0A= def get_first_of(header_name, msg):=0A """ Get the first NON-EMPTY heade= r of this name """=0A headers =3D msg.items()=0A rank =3D 1=0A for= header in headers:=0A if string.lower(header_name) =3D=3D string.lo= wer(header[0]) and \=0A header[1]:=0A return (rank, he= ader[1])=0A rank =3D rank + 1=0A return (0, None)=0A=0Adef get_fi= rst_after(target_rank, header_name, msg):=0A """ Get the first NON-EMPTY= header of this name which starts after=0A target_rank """=0A headers= =3D msg.items()=0A rank =3D 1=0A for header in headers:=0A if= rank < target_rank:=0A rank =3D rank + 1=0A continue= =0A if string.lower(header_name) =3D=3D string.lower(header[0]) and = \=0A header[1]:=0A return (rank, header[1])=0A = rank =3D rank + 1=0A return (0, None)=0A=0Adef address_in(value):=0A = """ Extracts the email address from the value """=0A if not value:=0A = raise Exception("Empty value, no address found")=0A (name, address)= =3D email.Utils.parseaddr(value)=0A if not address:=0A raise Exc= eption("Not a valid email address %s" % value)=0A # TODO: test that we h= ave a syntax user@fqdn.something?=0A return address=0A=0Adef check_only_= one(header_name, msg):=0A """ Check that there is only one header by thi= s name """=0A headers =3D msg.items()=0A seen =3D False=0A for hea= der in headers:=0A if (string.lower(header_name) =3D=3D string.lower= (header[0])) and \=0A header[1]:=0A if seen:=0A = raise Exception("Multiple %s headers" % header_name)=0A se= en =3D True=0A=0Adef get_pra(msg):=0A """ Principal routine: gets the PR= A """=0A headers =3D msg.items()=0A # The isolated numbers refer to s= teps in the specification (see section 2)=0A # 1=0A (rank_sender, res= ent_sender) =3D get_first_of("Resent-Sender", msg)=0A if resent_sender i= s not None:=0A (rank_from, resent_from) =3D get_first_of("Resent-Fro= m", msg)=0A if resent_from is not None:=0A (rank_received= , received) =3D get_first_after(rank_from, "Received", msg)=0A (= rank_path, return_path) =3D get_first_after(rank_from,=0A = "Return-Path", msg)=0A if n= ot ((received is not None and rank_received < rank_sender and =0A = rank_received > rank_from) or \=0A (return_path is no= t None and rank_path < rank_sender and=0A rank_path > rank_= =66rom)):=0A return address_in(resent_sender)=0A # 2=0A = (rank_from, resent_from) =3D get_first_of("Resent-From", msg)=0A if re= sent_from is not None:=0A return address_in(resent_from)=0A # 3= =0A check_only_one("Sender", msg)=0A (rank_sender, sender) =3D get_fi= rst_of("Sender", msg)=0A if sender is not None:=0A return address= _in(sender)=0A # 4=0A check_only_one("From", msg)=0A (rank_sender,= from_v) =3D get_first_of("From", msg)=0A if from_v is not None:=0A = return address_in(from_v)=0A =0Aif __name__ =3D=3D '__main__':=0A m= sg =3D email.message_from_file(sys.stdin)=0A print get_pra(msg)=0A=0A=0A= =0A =0A --TB36FDmn/VVEgNH/-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 08: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 IAA25594 for ; Thu, 26 Aug 2004 08: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 i7QC3ngG041686; Thu, 26 Aug 2004 05:03:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QC3nmZ041685; Thu, 26 Aug 2004 05:03:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QC3lTR041676 for ; Thu, 26 Aug 2004 05:03:48 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7QCD3ho030908; Thu, 26 Aug 2004 08:13:03 -0400 From: To: "'Chuck Mead'" , Subject: RE: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Date: Thu, 26 Aug 2004 08:02:07 -0400 Message-ID: <004301c48b64$83476060$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <412D2082.6020707@redhat.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I represent a large company, and despite construction budgets in excess of 100's of millions, consulting lawyers fees would cripple my IT budget that could be allocated to fighting spam. Therefore, raised is my hand, lets drop whatever component of sender ID requires the license. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Chuck Mead > Sent: Wednesday, August 25, 2004 7:28 PM > To: ietf-mxcomp@imc.org > Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ted Hardie wrote: > | > | At 11:06 PM +0200 8/25/04, Koen Martens wrote: > | > |> On Wed, Aug 25, 2004 at 10:35:41AM -0700, Ryan Ordway wrote: > |> > |>> Perhaps a show of hands is in order to see just > |>> how much of a "minority" those who disapprove of the terms > |>> of the RFSIPL are? Consider my hand raised. > |> > |> > |> FWIW, my hand is raised. I oppose against an internet standard that > |> requires a > |> contract with microsoft to implement. > |> > | > | An important part of the IETF process is that we treat all of its > | participants > | as behaving in good faith. If the license terms offered cause > difficulties > | for you, please state how the terms impact your development and > deployment. > | (Eric's description of the sublicensing issue for Sendmail is a good > | example > | here, and I encourage you to read it as a potential model). > > I don't doubt that the holder is acting in good faith and I > don't doubt > that they mean what they say. What I doubt is whether I can apply the > solution being proffered in a piece of opensource software and then > distribute it if I chose to do so. The license does not > appear to allow > that and it also appears to require steps prior to using what we're > proposing as a "standard". > > It has been said to me in this forum that I should consult an attorney > if I have questions about the licensing. All I can say to that is "fat > chance" individuals within the OSS community are not going to do this. > Companies might but I personally will not as I cannot afford > the fee my > attorney would charge me. So does that mean that I cannot or won't > implement the solution we're going to offer as a standard. In all > likelihood that is exactly what it means. If that's the case > (and if we > keep heading down this road it's likely that it will be) then what is > the chance that I would implement? It's a sum approaching zero. > > So what good does a standard that I cannot implement do for me? None > what so ever. The list of MTA's which appear to be affected by this > situation is not that long (sendmail, postfix, qmail and exim > for sure) > but I'd bet a case of beer that there are more people using > them on the > net today worldwide than are using close source MTA's (and > many of them > won't know or care what they're using... they just want their > email). If > we intend to offer something as a standard we'd better take the > situations of the admins that manage those MTA's into > account. A bit of > practical thought, if you please! > > What if we set a standard and nobody used it? MARID would really be > doing the world a favor right? > > Hmmmmm....? > > - -- > Chuck Mead > Instructor II (and resident Postfix bigot), GLS > Disclaimer: "It's Thursday and my name is Locutus of B0rk!" > Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFBLSCCZfy0juH51WsRAvN+AJ4hkCvJDh/aTEIwM9eVfxYZaQzHaACfYOZw > +dv9UKIE2EkJonz0YPDYQbY= > =RVH4 > -----END PGP SIGNATURE----- > From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 08:34: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 IAA26494 for ; Thu, 26 Aug 2004 08:34: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 i7QCCwva043976; Thu, 26 Aug 2004 05:12: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 i7QCCwQB043975; Thu, 26 Aug 2004 05:12:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QCCw28043937 for ; Thu, 26 Aug 2004 05:12:58 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2004 05:18:07 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7QCCpnV024960; Thu, 26 Aug 2004 05:12:51 -0700 (PDT) Received: from fenton-w2k01.cisco.com (sjc-vpn2-216.cisco.com [10.21.112.216]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7QCFEkZ015287; Thu, 26 Aug 2004 05:15:18 -0700 Message-Id: <4.3.2.7.2.20040826050415.045ae9f8@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Aug 2004 05:12:48 -0700 To: Rand Wacker , ietf-mxcomp@imc.org From: Jim Fenton Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: 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:"1093522518.713374"; x:"432000"; a:"rsa-sha1"; b:"0:1282"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"wldQj18yOsAKr8G0JFFx6SzxuwK8q9A4yvLvH5MGzzVjgvsIwfBxsboByug2Y" "+0CRFR3IPMmgZn3MKMdwMgpxIV+e1C/7S70DUqvx+tcxrzAuPTAfNTp0TtqKB" "+yw97EE+meuxaXak5hbpgl3U7HPRIGKkW1HGrAo4FK9DfI0/0="; c:"Date: Thu, 26 Aug 2004 05:12:48 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I\n" " believe)" 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 08:44 PM 8/25/2004 -0700, Rand Wacker wrote: >My concern for Sender ID is that since SPF has already claimed the FQDN >TXT dataspace for itself (and since SPF is seeing parallel adoption >regardless of where Sender ID goes), trying to stuff a second Sender ID >record in the same data space will be problematic for some, and if we >ever try to evolve this to a third version then it will *never* fit. I share this concern, but... >The solution I would suggest is to put spfv2/pra records in a sub-domain >such as _marid.company.com. While it would be nice to recommend that >people begin allowing TCP DNS queries, it is unlikely that the highest >volume sites would ever want to implement such. I think it was brought up earlier that using a prefix like _marid would break the use of wildcards (can't do _marid.*.example.com). But it wasn't clear (to me, at least) whether wildcards would work in this application, even without the prefix. Wildcard support would be very nice to have, to provide symmetry with wildcard MX records for incoming mail. Can anyone clear up whether adding the prefix breaks wildcards, or were they already broken? Of course, a new record type would be preferable, but there are real-world deployment issues there. -Jim From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 08:40: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 IAA26947 for ; Thu, 26 Aug 2004 08:40: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 i7QCIFmt045125; Thu, 26 Aug 2004 05:18: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 i7QCIFLD045124; Thu, 26 Aug 2004 05:18:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QCI8HB045094 for ; Thu, 26 Aug 2004 05:18:08 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7QCRNho031342; Thu, 26 Aug 2004 08:27:23 -0400 From: To: "'Ted Hardie'" , "'Koen Martens'" , "'Ryan Ordway'" Cc: "'IETF MARID WG'" Subject: RE: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Date: Thu, 26 Aug 2004 08:16:27 -0400 Message-ID: <004401c48b66$83cb99a0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I support many divisions across North America, most with their own mail servers. We have a non-standard or not "off the shelf" MTA deployment. As such, deploying sender id license would require much effort that is unacceptable, even if I could convince the powers that be we don't have to consult a lawyer before signing. Further, the very nature of the license appears I may have to disclose the nature of my "non standard" mta deployment in order to integrate sender id. This is unacceptable. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Ted Hardie > Sent: Wednesday, August 25, 2004 6:04 PM > To: Koen Martens; Ryan Ordway > Cc: IETF MARID WG > Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It > > > > At 11:06 PM +0200 8/25/04, Koen Martens wrote: > >On Wed, Aug 25, 2004 at 10:35:41AM -0700, Ryan Ordway wrote: > >> Perhaps a show of hands is in order to see just > >> how much of a "minority" those who disapprove of the terms > >> of the RFSIPL are? Consider my hand raised. > > > >FWIW, my hand is raised. I oppose against an internet > standard that requires a > >contract with microsoft to implement. > > > > An important part of the IETF process is that we treat all of > its participants > as behaving in good faith. If the license terms offered > cause difficulties > for you, please state how the terms impact your development > and deployment. > (Eric's description of the sublicensing issue for Sendmail is > a good example > here, and I encourage you to read it as a potential model). > > Stating that the _holder_ of the IPR is the problem, rather > than the _terms_ > of the license, is very different. That is contrary to the > principle that we > treat all participants as behaving in good faith. Please > focus on the terms, > not the holder. > regards, > Ted Hardie > From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 08:47: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 IAA27356 for ; Thu, 26 Aug 2004 08:47: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 i7QCRbWi047185; Thu, 26 Aug 2004 05:27: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 i7QCRbJC047184; Thu, 26 Aug 2004 05:27:37 -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 i7QCRalu047172 for ; Thu, 26 Aug 2004 05:27:37 -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 1C0JLp-0001IX-4L for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 07:27:38 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Thu, 26 Aug 2004 07:26:55 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 25 Aug 2004 20:46:24 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: >> If not, wouldn't this mean that users of qmail that want to support >> SenderID (which we hope will be all of them) need to get a license >> from Microsoft? > > Or an alternative MTA :-) I'm not sure that is really a joking matter. We aren't supposed to talk about "hidden agendas", but since you raised the issue, I'll ask directly: Is your goal in supporting the SenderID license to get people to use "an alternative MTA", say the one that Harry and Jim work on? > If I had to patch Qmail the way I would do it is as follows: > > [ideas snipped] Your scheme does not match the design of qmail. What you are suggesting is a major rewrite of the qmail MTA. One of the reasons for using the PRA is the claim that it would be easier to support than SPF-classic and SRS. However, there have long been patches for qmail to do SPF-classic and SRS, but now you are claiming that the way to do PRA is to do a major rewrite of one of the most popular MTAs on the Internet. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 09: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 JAA29145 for ; Thu, 26 Aug 2004 09:25: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 i7QCtBnn053727; Thu, 26 Aug 2004 05:55:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QCtBvn053726; Thu, 26 Aug 2004 05:55:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QCtAml053713 for ; Thu, 26 Aug 2004 05:55:10 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1C0JmQ-0003eY-Ra for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 07:55:12 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Thu, 26 Aug 2004 07:54:56 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 25 Aug 2004 20:56:17 -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: acceptable licenses (Was: Can there be an early decision on the SenderID license?) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: First off, I raised the subject of having an early decision on the SenderID license in order to make more effective use of this working group's time. If the SenderID license is decided to be acceptable, then we can cut off the debate/discussion of it and save a lot of mailing list bandwidth. If the SenderID license is decided to not be acceptable, then we can stop evaluating the marid-core, marid-pra and marid-submitter I-Ds. Instead of addressing this issue, PHB has tried to reframe the discussion. In "Hallam-Baker, Phillip" writes: >> Right now, we are supposed to be reviewing all of the documents. >> However, as demonstrated in the "DEPLOY/IPR: Fundamental >> Disagreements, or Get On With It" thread, there doesn't seem to be a >> rough consensus that the SenderID license is acceptable. (Actually, >> there appears to be a rough consensus that it isn't acceptable.) > > I have yet to see a statement that makes a valid legal argument > that the license terms prohibit open source distribution. That is completely irrelevant. As Eric Allman pointed out, many of the aspects of the SenderID create friction, and that is all that is enough to question whether the SenderID license is worth it. > The license terms are at least as open as the terms which the > IETF has accepted in the past. The IETF has accepted RFCs in the past that have been horribly designed and written. The fact that the IETF has made mistakes in the past is hardly a good reason to ignore the current situation. > Larry Lessig is a lawyer, lets give him a call and hit his folk > up for some pro bono. Please feel free to contact Larry. On Monday, I started making contact with Eben Moglen (the FSF lawyer) for his input on whether the SenderID license is compatible with the GPL. I chose Eben for a couple of reasons. First off, he was involved with earlier discussions with MS over this issue and therefore should be up to speed on the subject. Secondly, Eric Allman has used quotes form Eben in order to claim that the current SenderID license is acceptable. > First I would suggest that those wanting to make the argument that > the license terms are not acceptable put them in a form that is > more coherent than that advanced so far. In particular paying close > attention to the fact that what is wanted is a license to redistribute > software without let or hinderance. No, this is backwards. The IETF requires rough consensus in order to advance things. People who think that the SenderID license is acceptable need to show that there is a rough consensus that it is OK. This working group does not need to accept the SenderID license because is no worse than the worst license that the IETF has accepted in the past. Rather, we need to look at what RFC3668 says: | 8. Evaluating alternative technologies in IETF working groups | | In general, IETF working groups prefer technologies with no known IPR | claims or, for technologies with claims against them, an offer of | royalty-free licensing. But IETF working groups have the discretion | to adopt technology with a commitment of fair and non-discriminatory | terms, or even with no licensing commitment, if they feel that this | technology is superior enough to alternatives with fewer IPR claims | or free licensing to outweigh the potential cost of the licenses. People who are trying to reach a rough consensus that the SenderID license is acceptable need to show that the burden placed on software (both MTAs and things like spam filters) that are already widely deployed is justified. That the PRA "is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses." So far, no one has come close to showing that the PRA is superior enough to outweigh the costs. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 09:44: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 JAA00300 for ; Thu, 26 Aug 2004 09:44: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 i7QDINxd058995; Thu, 26 Aug 2004 06:18: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 i7QDINaf058994; Thu, 26 Aug 2004 06:18:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDINEk058988 for ; Thu, 26 Aug 2004 06:18:23 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7QDIMs8023665 for ; Thu, 26 Aug 2004 06:18:22 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 06:18:22 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: ietf-mxcomp@imc.org, "Hallam-Baker, Phillip" Subject: RE: Can there be an early decision on the SenderID license? Date: Thu, 26 Aug 2004 06:18:21 -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: > Is this really a quasi-judicial proceeding? I think it's a bunch > of people trying to solve a technical problem without getting > stymied by intractable non-technical considerations. Once you set yourself up as a standards body there are a whole rack of anti-trust issues that you start being caught up in. The whole reason that the IESG etc. were invented was to provide the appearence of process and protect WG chairs and the institution from legal claims. The IETF did at one point establish itself as an ISO contributing organization. In theory IETF standards could become ISO standards, this has never happened but it was done to put the IETF on the same footing as the ANSI/OSI stack. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10:02:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01291 for ; Thu, 26 Aug 2004 10:02:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDcvMJ065485; Thu, 26 Aug 2004 06: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 i7QDcv2r065484; Thu, 26 Aug 2004 06:38:57 -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 i7QDcuCv065455 for ; Thu, 26 Aug 2004 06:38:56 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 15906 invoked from network); 26 Aug 2004 13:40:39 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 26 Aug 2004 13:40:39 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit From: Margaret Olson Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 09:38:52 -0400 To: "IETF MARID WG" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2004, at 8:26 AM, wayne wrote: > > In > > "Hallam-Baker, Phillip" writes: > >>> If not, wouldn't this mean that users of qmail that want to support >>> SenderID (which we hope will be all of them) need to get a license >>> from Microsoft? >> >> Or an alternative MTA :-) > > Is your goal in supporting the SenderID license to get people to use > "an alternative MTA", say the one that Harry and Jim work on? Wayne and others. I largely agree with Phill, but let me try to present the issue a slightly different way. I use several MTA implementations, both commercial and open source. I've concluded that the current license will allow me to continue to have a good selection of open source and commercial choices with Sender ID implementations. Open source is open source - Sender ID is sufficiently valuable that I'm convinced that viable Sender ID variants will emerge, even if they are not distributed in quite the same way that the code is today. Both Eric Allman and Phill have discussed ways to approach this problem. I am speaking as someone who intends to implement receive side Sender ID as soon as possible. So while the license is less than ideal, it's sufficient. It is also fundamentally defensive, and anyone with significant assets contemplating donating IPR has to concern themselves with the defensive legal issues. The fundamental goal is to make sure you can use your own IPR after you have donated it, which is otherwise not assured. I would not like to see contributions to the IETF limited to individuals and corporations who are not successful enough to have this kind of legal concern. For one thing, it would rule out all organizations with significant R&D budgets. Followed to it's logical conclusion, this approach to license requirements give us problems even with open source donations, since some of the open source licenses are mutually incompatible. I have also had the impression that some folks on the list are expecting Microsoft to give them what amounts to legal advice. A lawyer representing me, being paid by me, can't give you legal advice about how to deal with me - there is a conflict of interest. So where Microsoft does provide clarifications or suggestions it will be caveated it left and right with "consult your own lawyer" just to make sure you are not confused about whose interests are being represented. This is how the legal system works; it's not some sort of Microsoft conspiracy to make everyone waste money on legal advice. In the spirit of frugality, I applaud Wayne's contacting of Eben Moglen. It's always a good idea to avoid paying a lawyer (or anyone else, for that matter) to come up to speed on a particular subject. Margaret. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10:02: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 KAA01317 for ; Thu, 26 Aug 2004 10:02: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 i7QDe9tV065968; Thu, 26 Aug 2004 06:40:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QDe9Sb065967; Thu, 26 Aug 2004 06:40:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from icicle.pobox.com (icicle.pobox.com [207.8.226.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDe8J6065957 for ; Thu, 26 Aug 2004 06:40:08 -0700 (PDT) (envelope-from SRS0=fzKj=LQ=dumbo.pobox.com=mengwong@bounce2.pobox.com) Received: from emerald.pobox.com (emerald.pobox.com [207.8.226.12]) by icicle.pobox.com (Postfix) with ESMTP id 42E5B11A638; Thu, 26 Aug 2004 09:40:11 -0400 (EDT) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id EF6F0132D1A; Thu, 26 Aug 2004 09:39:37 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 93BAB87C; Thu, 26 Aug 2004 09:40:09 -0400 (EDT) Date: Thu, 26 Aug 2004 09:40:09 -0400 From: Meng Weng Wong To: Rand Wacker Cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Message-ID: <20040826134009.GA3684@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 Wed, Aug 25, 2004 at 08:44:16PM -0700, Rand Wacker wrote: | | This is a concern that has been voiced to me by several major sites that | are exactly the same set of sites we use as examples for where we need to | stop phishing from. They are most likely going to publish *both* spfv1 | and spfv2/pra records, and their initial investigation of their email | architectures has indicated that those records are going to be pushing | this real-world 240-byte limit (a 480 byte effective UDP packet split in | two) | The divergence between v=spf1 and spf2.0/pra records was motivated by the desire to accommodate those domains whose sets of permitted IPs differed according to context. Example.com might wish to permit one set of MTAs to use its name in mail-from, and another set of MTAs to use its domain in the PRA. My initial response to this requirement was to say, "example.com should just take the union of both those sets and publish that." I believe that some people have spoken up and said that a union solution was unappealing. As things stand, the current draft means most people would do: example.com TXT "v=spf1 blah blah blah" example.com TXT "spf2.0/pra blah blah blah" I believe that the vast majority of all domains will have exactly the same "blah blah blah". Rand's objection appears to share this belief. Therefore, I suggest that we introduce the %{e} scope macro to accommodate the very small fraction of domains who need to distinguish the scopes, and allow everyone else to leave things alone. At the Microsoft event earlier this month, we spent some time discussing this issue. The audience represented the ESP community, who I believe are the folks who would most want to assert the distinction between scopes. The audience felt that changing the prefix would be fine, but doing a scope macro would also be fine. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10:06: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 KAA01720 for ; Thu, 26 Aug 2004 10:06: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 i7QDgJqk066523; Thu, 26 Aug 2004 06:42:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QDgJsd066522; Thu, 26 Aug 2004 06:42:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDgINB066513 for ; Thu, 26 Aug 2004 06:42:18 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7QDeVqv003335; Thu, 26 Aug 2004 06:40:31 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 06:40:31 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jim Fenton'" , Rand Wacker , ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve) Date: Thu, 26 Aug 2004 06:40:31 -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 solution I would suggest is to put spfv2/pra records in > a sub-domain > >such as _marid.company.com. While it would be nice to recommend that > >people begin allowing TCP DNS queries, it is unlikely that > the highest > >volume sites would ever want to implement such. > > I think it was brought up earlier that using a prefix like > _marid would break the use of wildcards (can't do > _marid.*.example.com). But it wasn't clear (to me, at least) > whether wildcards would work in this application, even > without the prefix. Wildcard support would be very nice to > have, to provide symmetry with wildcard MX records for > incoming mail. Can anyone clear up whether adding the prefix > breaks wildcards, or were they already broken? The situation with the prefix is as follows: 1) Standard (i.e. AXFR communicatable wildcards) do not work for ANY Sender-ID use case. A wildcard only produces a match if there is no data whatsoever in a node. This means that this type of wildcard cannot be used to make any assertions about machines that have a domain name entry. 2) Synthetic wildcards work fine, but are not supported in the AXFR interchange format. 3) Prefixing does not prevent the use of wildcards, but if a wildcard is used the advantage of using a prefix is lost. I.E. *.example.com will match _spf1.example.com and _spf2.example.com 4) Some tools do not support prefix use - this is not a major concern since I would expect sender-id to be promoted mainly through purpose driven tools not through grovelling TXT entries. My opinion is that we should move to a prefix if we introduce a new version identifier. Otherwise we should not. There is a value to using a prefix but it is not by itself sufficient to make a change worthwhile. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10:22: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 KAA03713 for ; Thu, 26 Aug 2004 10:22: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 i7QE04sF072211; Thu, 26 Aug 2004 07:00: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 i7QE040J072210; Thu, 26 Aug 2004 07:00:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE02O5072197 for ; Thu, 26 Aug 2004 07:00:03 -0700 (PDT) (envelope-from SRS0=wCa/I6YQ=LQ=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7QE02ed006269 for ; Thu, 26 Aug 2004 16:00:02 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408261400.I7QE01HM006259@asarian-host.net> Date: Thu, 26 Aug 2004 14:00:02 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY - reference implementation X-Trace: N2RfEMcdLVr7Cuy0wdV9tKXqn75J9ce+TM1l3h5/LhApEDyL+aGLXBZuTdm7Y0n2syWdUKl8uGPwOOii7xehxw== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <412CE5F4.5010006@redhat.com> <20040826111249.GA5702@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03D9_01C48B85.BCA6DD60" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQS3s4jFqW1BleBN9AQGRKAf+IdV6kNH0lBhRxk40nVzo8frILtC+Yl+J ESOLq2H8+8No782tarKslhz1DbJ8xRYDik7iDKCTfOKfsF7loojrCylA4UugW0fH bFQP/fMl2URZ56tFd4BFqn1qg3RZ3sMyPU+mjFBw83bTNPq2JPjCgXawJ3RV6L1Z 0oNikcBzcvBaurIfvnyCXu7LRgNPVYRK0RhbowZBEhtFLImUhxA0e8mrNbQhiS7L yMDAipL3BhRj0ckn5QtSMteNUMVt7uhyJfx3KFisYInT5epumzz+huaTh8QAWtYT P7g4IBtLQ/xyWe8xLdSbZifObakjfA5rlfcNgvtomKUyQSKy2sFxGA== =GHZA 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_03D9_01C48B85.BCA6DD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > Basically, Sender-ID is "get the PRA", then "get the PRD", send "apply > SPF to the PRD". > > The last step is complicated but there are many free software SPF > implementations. > > The first step is very simple, I attached my own implementation. Bug > reports are welcome to show me where I've misread -pra. Just for the heck of it, here is my Perl implementation of PRA. :) - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx ------=_NextPart_000_03D9_01C48B85.BCA6DD60 Content-Type: application/octet-stream; name="pra.pl" Content-Disposition: attachment; filename="pra.pl" Content-Transfer-Encoding: quoted-printable #!/usr/local/bin/perl -w=0A= #=0A= # AIM: Implements the PRA (Purported Responsible Address) algorithm=0A= # described in Internet-Draft draft-ietf-marid-par-00.txt.=0A= #=0A= # USE: ./pra.pl =0A= #=0A= # Requires: Perl.=0A= # mailTools-1.64=0A= #=0A= # LICENCE: trivial work, not patentable, not licenceable.=0A= #=0A= # WARNING: Microsoft claims a patent on the PRA algorithm.=0A= # The author did not requested a licence.=0A= #=0A= # AURHOR: Mark Kramer =0A= =0A= use Mail::Address;=0A= use strict;=0A= =0A= my $header_file =3D $ARGV[0] or die "Usage: $0 ";=0A= my $header;=0A= =0A= if (open (HEADERS, $header_file)) {=0A= $header .=3D $_ while ();=0A= close (HEADERS);=0A= } else {=0A= die "Cannot open $header_file!\n";=0A= }=0A= =0A= # Stream-line continuation lines:=0A= =0A= $header =3D~ s/\n\s+/\t/mg;=0A= =0A= # Remove (key, value) pairs from header where 'value' does not exist:=0A= =0A= $header =3D~ s/^[^:]*:\s*\n//mg;=0A= =0A= # Process the split-up-per-line $header in reverse order,=0A= # so that the last key set for $headers(key} is actually=0A= # the first (non-empty!) occurance thereof!=0A= =0A= my %headers =3D map { split (/: */, $_, 2) } reverse split (/\n/, lc = ($header));=0A= my $pra =3D $headers{'resent-sender'} || $headers{'resent-from'} || = $headers{'sender'} || $headers{'from'} || undef;=0A= =0A= # The next foreach loop looks a bit weird; but=0A= # Mail::Address -> parse expects an array, not a=0A= # scalar context.=0A= =0A= if ($pra) {=0A= foreach (Mail::Address -> parse ($pra)) {=0A= print "PRA: " . $_ -> address . "\n";=0A= last;=0A= }=0A= }=0A= =0A= exit 0; ------=_NextPart_000_03D9_01C48B85.BCA6DD60-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10: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 KAA03822 for ; Thu, 26 Aug 2004 10:24: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 i7QDsiig070407; Thu, 26 Aug 2004 06:54: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 i7QDsioK070406; Thu, 26 Aug 2004 06:54:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDshkZ070396 for ; Thu, 26 Aug 2004 06:54:43 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-103-225.area3.spcsdns.net ([68.245.145.169]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0Ki9-00073P-Gt for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 09:54:42 -0400 Message-ID: <412DEB94.1030607@solidmatrix.com> Date: Thu, 26 Aug 2004 09:54:28 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: acceptable licenses (Was: Can there be an early decision on the SenderID license?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: >>Larry Lessig is a lawyer, lets give him a call and hit his folk >>up for some pro bono. > > > Please feel free to contact Larry. On Monday, I started making > contact with Eben Moglen (the FSF lawyer) for his input on whether the > SenderID license is compatible with the GPL. I chose Eben for a > couple of reasons. First off, he was involved with earlier > discussions with MS over this issue and therefore should be up to > speed on the subject. Secondly, Eric Allman has used quotes form Eben > in order to claim that the current SenderID license is acceptable. > I had conversations with Larry Rosen of OSI and someone from the FSF in the past few days. In their opinion this license is not compatible with the GPL and most other open source licenses. And yes - they are lawyers. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10:30: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 KAA04179 for ; Thu, 26 Aug 2004 10:30: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 i7QE6qYE074398; Thu, 26 Aug 2004 07:06: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 i7QE6qOP074397; Thu, 26 Aug 2004 07:06:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE6p1q074385 for ; Thu, 26 Aug 2004 07:06:51 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7QE6rfI027980 for ; Thu, 26 Aug 2004 07:06:53 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 07:06:53 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: acceptable licenses (Was: Can there be an early decision on t he SenderID license?) Date: Thu, 26 Aug 2004 07:06: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: > Instead of addressing this issue, PHB has tried to reframe the > discussion. Framing the discussion is a perogative of the co-chairs. You ar not a co-chair, therefore I have an equal right to frame the discussion. In the debating societies I am a member of you hold the debate before the vote. The motion from the floor is that the question be put. I oppose putting the question because we have merely heard opinion thus far, not argument. > > In > .vrsn.com> "Hallam-Baker, Phillip" writes: > > I have yet to see a statement that makes a valid legal argument > > that the license terms prohibit open source distribution. > > That is completely irrelevant. As Eric Allman pointed out, many of > the aspects of the SenderID create friction, and that is all that is > enough to question whether the SenderID license is worth it. My concern is that I believe that it is very likely that one or more patent trolls made applications after the publication of SPF. This has happened several times in the past, the applications are made by people who have no connection to the invention and are in effect perjured, but this has never been prosecuted. The perjured patent is then used to extort money from a company that uses the technology before it goes IPO. What was ASKED of Microsoft was to produce a license that made it possible to create and distribute open source code. Now that this has happened I beleive that the ground has been shifted. I do not see this issue being approached from the make it work point of view. > > The license terms are at least as open as the terms which the > > IETF has accepted in the past. > > The IETF has accepted RFCs in the past that have been horribly > designed and written. The fact that the IETF has made mistakes in the > past is hardly a good reason to ignore the current situation. The IETF IPR policy has received extensive examination at every level of the organization. If this group is going to overturn it then it has to provide a better argument than not wanting to be bothered. > > Larry Lessig is a lawyer, lets give him a call and hit his folk > > up for some pro bono. > > Please feel free to contact Larry. On Monday, I started making > contact with Eben Moglen (the FSF lawyer) for his input on whether the > SenderID license is compatible with the GPL. I chose Eben for a > couple of reasons. First off, he was involved with earlier > discussions with MS over this issue and therefore should be up to > speed on the subject. Secondly, Eric Allman has used quotes form Eben > in order to claim that the current SenderID license is acceptable. I have no problem with the license terms, so I'll leave those who have to call lawyers. > > First I would suggest that those wanting to make the argument that > > the license terms are not acceptable put them in a form that is > > more coherent than that advanced so far. In particular paying close > > attention to the fact that what is wanted is a license to > redistribute > > software without let or hinderance. > > No, this is backwards. The IETF requires rough consensus in order to > advance things. People who think that the SenderID license is > acceptable need to show that there is a rough consensus that it is > OK. Rough concensus is on the basis of facts, not opinions. > This working group does not need to accept the SenderID license > because is no worse than the worst license that the IETF has accepted > in the past. Rather, we need to look at what RFC3668 says: > > | 8. Evaluating alternative technologies in IETF working groups > | > | In general, IETF working groups prefer technologies > with no known IPR > | claims or, for technologies with claims against them, > an offer of > | royalty-free licensing. Looks to me like the second clause in the statement requires updating since royalty free is a necessary, not a sufficient condition. royalty free, reasonable and non-discriminatory is the generally understood criteria. The license offered by Microsoft clearly meets the preferred criteria. The 'or' conjunctive does not denote a preference. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10:32: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 KAA04331 for ; Thu, 26 Aug 2004 10:32: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 i7QE9uP2075278; Thu, 26 Aug 2004 07:09:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QE9uur075277; Thu, 26 Aug 2004 07:09:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE9tW9075266 for ; Thu, 26 Aug 2004 07:09:56 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 10:09:57 -0400 Message-ID: <412DEF35.7090908@hepcoe.com> Date: Thu, 26 Aug 2004 10:09:57 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Aug 2004 14:09:57.0982 (UTC) FILETIME=[5E6CFFE0:01C48B76] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hello everyone. I have been watching this thread for a while and just decided to voice my opinion. My reasons for recommending the rejection of the IPR encumbered algorithm(s) are not due to my own interpretation of the license nor my feelings about the IPR holder but rather how the license will hurt the standard in the real world: 1. The IPR license will slow development This license is not clear nor unambiguous. If it were, you would not need to seek an attorney's advice on it. I think this much we can all agree upon, including Mr. Katz himself. This means that if I'm a developer who wishes to include Sender-ID in my open source product even if my attorney tells me that doing so is allowed under the license, and Lessig and Moglen themselves publish opinions saying that doing so is allowable, it does me no good if the IPR holder disagrees and sues me. It would be me and my attorney against a multi billion dollar company with a platoon of IP lawyers and an ambiguous license in question. Even if I am in the right, trying to fight such a suit in a different country on the other side of the continent would bankrupt me within weeks. Why would any open source developer take this risk? 2. The IPR license will slow adoption I think it is safe to say that at least half (and probably more) MTAs in use are open source. Certainly most ISPs that I know of use open source MTAs. I think it is also safe to say that a majority of people who deploy open source MTAs are probably at least somewhat suspicious of the motives and business tactics of your typical multi billion dollar software companies. It is therefore likely that many of them will be slower to adopt Sender-ID if it is encumbered by this license (even if they do not themselves need to personally get a license from the holder) than otherwise. Speaking personally as an MTA admin for a medium sized company, I will not adopt Sender-ID if it is encumbered by this license. It may be argued that MTA admins will be forced by their management to adopt it eventually, but it will definitely slow down the process. Obviously these are just my opinions. IANAL, etc. However, I don't think it would be easy to argue that the IPR license in any way benefits the standard nor can it be easily argued that the license will definitely do no harm to it. I think the chairs need to decide whether the potential harm is less problematic than replacing the encumbered algorithms. Kevin Peuhkurinen Network Security Analyst HEPCOE Credit Union Ltd. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10:45:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06580 for ; Thu, 26 Aug 2004 10:45:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEJceD078154; Thu, 26 Aug 2004 07:19: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 i7QEJcri078153; Thu, 26 Aug 2004 07:19:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEJbgj078135 for ; Thu, 26 Aug 2004 07:19:37 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 26 Aug 2004 10:19:31 -0400 id 002F4032.412DF173.0000510B From: David Blacka Organization: VeriSign, Inc. To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Thu, 26 Aug 2004 10:19:04 -0400 User-Agent: KMail/1.6.2 References: <4.3.2.7.2.20040826050415.045ae9f8@mira-sjc5-1.cisco.com> In-Reply-To: <4.3.2.7.2.20040826050415.045ae9f8@mira-sjc5-1.cisco.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408261019.04224.davidb@verisignlabs.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday 26 August 2004 8:12 am, Jim Fenton wrote: > Can anyone > clear up whether adding the prefix breaks wildcards, or were they already > broken? Since I don't know what you mean by "broken", I can't comment to whether or not wildcards are "already broken". BUT, if you publish: *.example.com. IN TXT "v=spf1 ..." *.example.com. IN TXT"spf2.0/pra ..." Then, if a query for "host.example.com IN TXT" would match the wildcard, the a query for "_marid.host.example.com IN TXT" would ALSO match the wildcard. So, the problem isn't that wildcards and marid records don't work, it is just that when using wildcards, the _marid prefix no longer gets you *just* the spf2.0/pra record. I.e. the current status quo. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10:57:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07971 for ; Thu, 26 Aug 2004 10:57: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 i7QEXEYv082235; Thu, 26 Aug 2004 07:33: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 i7QEXEWp082234; Thu, 26 Aug 2004 07:33:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEXEBM082224 for ; Thu, 26 Aug 2004 07:33:14 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 83D6726C084; Thu, 26 Aug 2004 16:33:40 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id BF7DF26C078; Thu, 26 Aug 2004 16:33:39 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7QEXf93933929; Thu, 26 Aug 2004 16:33:41 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 3145CFACE; Thu, 26 Aug 2004 16:33:41 +0200 (CEST) Date: Thu, 26 Aug 2004 16:33:41 +0200 From: Stephane Bortzmeyer To: Mark Cc: IETF MARID WG Subject: Re: DEPLOY - reference implementation Message-ID: <20040826143341.GA19939@nic.fr> References: <412CE5F4.5010006@redhat.com> <20040826111249.GA5702@nic.fr> <200408261400.I7QE01HM006259@asarian-host.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408261400.I7QE01HM006259@asarian-host.net> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 26, 2004 at 02:00:02PM +0000, Mark wrote a message of 96 lines which said: > > The first step is very simple, I attached my own implementation. Bug > > reports are welcome to show me where I've misread -pra. > > Just for the heck of it, here is my Perl implementation of PRA. :) Does anyone have a good corpus of "bordeline" mails to test the two implementations? (Although the algorithm is very simple, so we should not expect discrepancies.) From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 10:57:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07995 for ; Thu, 26 Aug 2004 10:57:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEWeFr082090; Thu, 26 Aug 2004 07:32: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 i7QEWeiZ082089; Thu, 26 Aug 2004 07:32:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEWdi0082077 for ; Thu, 26 Aug 2004 07:32:39 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-103-225.area3.spcsdns.net ([68.245.145.169]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0LIs-0000sy-O1; Thu, 26 Aug 2004 10:32:40 -0400 Message-ID: <412DF478.7030502@solidmatrix.com> Date: Thu, 26 Aug 2004 10:32:24 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Margaret Olson CC: IETF MARID WG Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ References: <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> In-Reply-To: <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Margaret Olson wrote: > On Aug 26, 2004, at 8:26 AM, wayne wrote: >> In >> > > "Hallam-Baker, Phillip" writes: >> >>>> If not, wouldn't this mean that users of qmail that want to support >>>> SenderID (which we hope will be all of them) need to get a license >>>> from Microsoft? >>> >>> Or an alternative MTA :-) >> >> Is your goal in supporting the SenderID license to get people to use >> "an alternative MTA", say the one that Harry and Jim work on? > > Wayne and others. > I largely agree with Phill, but let me try to present the issue a > slightly different way. I use several MTA implementations, both > commercial and open source. I've concluded that the current license > will allow me to continue to have a good selection of open source and > commercial choices with Sender ID implementations. Open source is open > source - Sender ID is sufficiently valuable that I'm convinced that > viable Sender ID variants will emerge, even if they are not distributed > in quite the same way that the code is today. Both Eric Allman and > Phill have discussed ways to approach this problem. I am speaking as > someone who intends to implement receive side Sender ID as soon as > possible. > The problem is not limited to open source or commercial. The main issue at hand is whether this specific license would be detrimental to deployment at large of this standard (in my personal opinion, the main place where this issue will come to play out is not the main open source and commercial email applications, but rather within ISPs and small companies that want to implement this in-house). The question we should be asking is whether this specific license will be detrimental to deployment of Sender-ID at large. While you argue that alternatives will emerge, others including potential implementors have made points as to why this license may scare away potential implementors. The problem is that we really don't know until the standard is approved which makes it kind of a catch-22. ... > I have also had the impression that some folks on the list are > expecting Microsoft to give them what amounts to legal advice. A lawyer > representing me, being paid by me, can't give you legal advice about > how to deal with me - there is a conflict of interest. So where > Microsoft does provide clarifications or suggestions it will be > caveated it left and right with "consult your own lawyer" just to make > sure you are not confused about whose interests are being represented. > This is how the legal system works; it's not some sort of Microsoft > conspiracy to make everyone waste money on legal advice. > > In the spirit of frugality, I applaud Wayne's contacting of Eben > Moglen. It's always a good idea to avoid paying a lawyer (or anyone > else, for that matter) to come up to speed on a particular subject. > In the context of the original question that is posted - how will this affect deployment, the lawyer issue is rather important. If a signficant number of potential implementors will not want to implement Sender-ID because they are unsure about what they are signing and cannot afford a lawyer, it will be detrimental to the overall success of the standard. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:15:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09495 for ; Thu, 26 Aug 2004 11:15: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 i7QEkNuV085498; Thu, 26 Aug 2004 07:46: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 i7QEkNBr085497; Thu, 26 Aug 2004 07:46:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-d20.mx.aol.com (imo-d20.mx.aol.com [205.188.139.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEkMRq085467 for ; Thu, 26 Aug 2004 07:46:23 -0700 (PDT) (envelope-from cdhutzler@aol.com) Received: from cdhutzler@aol.com by imo-d20.mx.aol.com (mail_out_v37_r3.4.) id 7.66.44d5ad2d (15887) for ; Thu, 26 Aug 2004 10:46:10 -0400 (EDT) Received: from [10.0.24.213] ([10.0.24.213]) by air-id08.mx.aol.com (v101.19) with ESMTP id MAILINID82-3e0f412df7b1267; Thu, 26 Aug 2004 10:46:10 -0400 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 26 Aug 2004 10:46:08 -0400 Subject: AOL's stance on SenderID and IPR issues From: Carl Hutzler To: IETF-MXCOMP Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AOL-IP: 10.0.24.213 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Someone on the list asked me to post AOL's thoughts on the IPR/SenderID thread... Our internal patent lawyer has reviewed the license agreement and said that he found no IP issues and we are free to pursue a license to use it in our infrastructure. The only issues I have seen on the lists likely do not apply to AOL: A) Sendmail redistrubutes/sells software - AOL does not sell MTAs other than perhaps netscape iplanet. But I am not closely related to that team. B) Some have complained about the nuisance of applying for a license for every "small organization" and potential costs of that. Folks really want a GPL. While I understand this, AOL is not in this category and likely would not see licensing this technology as an undue burden. That's the scoop from AOL land :-) -Carl -- Carl Hutzler Director, AntiSpam Operations America Online Mail Operations cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:19: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 LAA10126 for ; Thu, 26 Aug 2004 11:19: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 i7QEnfvM086344; Thu, 26 Aug 2004 07:49: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 i7QEnf1h086343; Thu, 26 Aug 2004 07:49:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEnerR086334 for ; Thu, 26 Aug 2004 07:49:40 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7QEnhu5002864 for ; Thu, 26 Aug 2004 07:49:43 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 07:49:43 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 07:49:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Or an alternative MTA :-) > > I'm not sure that is really a joking matter. We aren't supposed to > talk about "hidden agendas", but since you raised the issue, I'll ask > directly: > > Is your goal in supporting the SenderID license to get people to use > "an alternative MTA", say the one that Harry and Jim work on? QMail is not being maintained. The license terms make it impossible for it to be maintained. There are better mailers out there with true open source licenses. These do not create issues in the standards development area. I would advise anyone using QMail to move to a supported product. Whether that support is commercial or voluntary does not matter to me, I don't sell mail servers. I don't think that a standards group should be constrained by the license terms of an unsupported product that has not been maintained for years and is unlikely to be maintained in the future. > > If I had to patch Qmail the way I would do it is as follows: > > > > [ideas snipped] > > Your scheme does not match the design of qmail. What you are > suggesting is a major rewrite of the qmail MTA. Actually not, it is many years since I looked at QMail, but this is the type of modification I used to do in a day or so. Making a call out to a sharred library is no different in principle than making a call out to an object library. Take a look at the following: http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-libraries.ht ml#shared_dlsym #include /* defines dlopen(), etc. */ . . void* lib_handle; /* handle of the opened library */ lib_handle = dlopen("/full/path/to/library", RTLD_LAZY); if (!lib_handle) { fprintf(stderr, "Error during dlopen(): %s\n", dlerror()); exit(1); } /* first define a function pointer variable to hold the function's address */ struct local_file* (*readfile)(const char* file_path); /* then define a pointer to a possible error string */ const char* error_msg; /* finally, define a pointer to the returned file */ struct local_file* a_file; /* now locate the 'readfile' function in the library */ readfile = dlsym(lib_handle, "readfile"); /* check that no error occured */ error_msg = dlerror(); if (error_msg) { fprintf(stderr, "Error locating 'readfile' - %s\n", error_msg); exit(1); } /* finally, call the function, with a given file path */ a_file = (*readfile)("hello.txt"); dlclose(lib_handle); Phill From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:37: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 LAA12085 for ; Thu, 26 Aug 2004 11:37:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFArmr092632; Thu, 26 Aug 2004 08:10: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 i7QFAr10092615; Thu, 26 Aug 2004 08:10:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFAogK092579 for ; Thu, 26 Aug 2004 08:10:50 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7QFAqZ7012927; Thu, 26 Aug 2004 08:10:53 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 08:10:52 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'David Blacka'" , ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve) Date: Thu, 26 Aug 2004 08:10:50 -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 Thursday 26 August 2004 8:12 am, Jim Fenton wrote: > > Can anyone > > clear up whether adding the prefix breaks wildcards, or > were they already > > broken? > > Since I don't know what you mean by "broken", I can't comment > to whether or > not wildcards are "already broken". BUT, if you publish: > > *.example.com. IN TXT "v=spf1 ..." > *.example.com. IN TXT"spf2.0/pra ..." > > Then, if a query for "host.example.com IN TXT" would match > the wildcard, the a > query for "_marid.host.example.com IN TXT" would ALSO match > the wildcard. > > So, the problem isn't that wildcards and marid records don't > work, it is just > that when using wildcards, the _marid prefix no longer gets > you *just* the > spf2.0/pra record. I.e. the current status quo. While David is right, there is also the corollary that *.example.com will only match nodes that do not exist at all. So there are two issues, do wildcards work as expected, is the wildcard useful at all. The matching behavior means that the wildcard is not useful for the use cases given. i.e. if we have a.example.com *.example.com. IN TXT "v=spf1 ..." Will match _marid.b.example.com, b.example.com but not a.example.com regardless of whether a has TXT records or not. So you can't use a wildcard to give a default SPF record for DNS names of hosts that exist. Only the hosts that don't exist will match. I don't know what happens for _marid.a.example.com, I think it should not match but one of the DNS people can say for sure. IF _marid.a.example.com did match the wildcard then it would be a way to make the wildcards useful. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:37: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 LAA12103 for ; Thu, 26 Aug 2004 11:37:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFFBT0094537; Thu, 26 Aug 2004 08: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 i7QFFBjc094536; Thu, 26 Aug 2004 08:15:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFFA4H094529 for ; Thu, 26 Aug 2004 08:15:10 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7QFNHYF019719; Thu, 26 Aug 2004 08:23:17 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7QFNHb3019715; Thu, 26 Aug 2004 08:23:17 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 Aug 2004 08:23:17 -0700 (PDT) From: "william(at)elan.net" To: Meng Weng Wong cc: Rand Wacker , Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <20040826134009.GA3684@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 Thu, 26 Aug 2004, Meng Weng Wong wrote: > On Wed, Aug 25, 2004 at 08:44:16PM -0700, Rand Wacker wrote: > | > | This is a concern that has been voiced to me by several major sites that > | are exactly the same set of sites we use as examples for where we need to > | stop phishing from. They are most likely going to publish *both* spfv1 > | and spfv2/pra records, and their initial investigation of their email > | architectures has indicated that those records are going to be pushing > | this real-world 240-byte limit (a 480 byte effective UDP packet split in > | two) > > The divergence between v=spf1 and spf2.0/pra records was > motivated by the desire to accommodate those domains whose > sets of permitted IPs differed according to context. This was unfortunete decision from IETF meeting largely done to distinguish MARID records from existing SPF base. It was felt by some that existing records are published for mail-from and may not apply for MARID PRA and by doing new version of SPF it can be insured that all records used are those that wanted to published MARID records. I have to say that I share opinion that records might be different for different identities, but I did not think there was enough reason to force duplication as per current proposal. I had to think about it when this was talked during MARID meeting (before ideas of scoping modifier that me and others proposed were rejected) and I did not immediatly object. However the way I see it now is that although this does introduce scoping it did in a way that will not allow for two scope records to have shared data parts which will cause large amount of dupliction and increase of dns records. I note specifically that records do not even allow for different scopes to even refer to the same shared portion of dns record (though for example include) which could potentially provide a solution in case of large SPF record size. Overeall I think the way the scoping was introduced with SPF2.0/PRA carries larger negative then positive value. Both scope macro and new prefix have their own advantage and disadvantages and I do not like either alternative. With prefix you gain ability to be certain that record published is indeed for MARID PRA (as spf1 records are entered directly in TXT for domain) as is with SPF2.0/PRA but in case of shared records, it requires separate lookup which I suppose would be done with "include". This can be avoided by using wildcards but in that case the same record applies for all subdomains and this may not have been the original intent. At the same time when you do want to use wildcards, you can no longer proper publish scope, which is actually a bigger concern. With scoping macro, it easily solves the problem for SPF1 & MARID PRA records having same data but at the same time main objection of new version of SPF2.0/PRA was to distinguish when publisher intended to use PRA or not and in case of completely same data, you may never know. At the same time if data is not the same, this will ALWAYS require 2nd dns lookup which is even worth, so I think spf macro is worst choice. I do have an alternative idea though (and its not anything knew that was not already mentioned before). This involves introducing new operator that specifies scope (i.e. "scope=PRA") and requirying that to be present if record is to be considered valid for MARID PRA. If somebody needs to specify portion of SPF record that is not covered by PRA but should be understood by old SPF1 complient client, then such record would go before "scope=PRA", the shared portion would have to be proceeded by "scope=PRA,MFROM". In rare cases when you have record that should be covered only by PRA but should not be ignored by SPF1 client, I propose that "scope=MFROM ?all" (or ~all or -all, etc) be placed followed by "scope=PRA" and rest of the record for PRA and repeat of the ending ?all. To give an example: example.com. IN TXT "v=spf1 scope=MFROM +ip4:192.0.0.1 scope=PRA,MFROM +ipf:192.0.0.2 scope=MFROM ~all scope=PRA +ip4:192.0.0.3 -all" In above current (SPF1 only clients that don't know about PRA and scoping) would see above as only: "v=spf1 +ip4=192.0.0.1 +ip4:192.0.0.2 ~all" where as new scope aware clients will see this same way for old SPF1 scope of enevelope "mail from" but will see this as "+ip4:192.0.0.2 +ip4:192.0.0.3 -all" for PRA. Now what I actually proposed before is short versions for operator names (in order to have shorter dns records) where each scope is represented by one letter so instead of long "scope=PRA,MFROM" we can have "sc=pm" or possibly "sc=p,m". I would appreciate if these ideas and this form of scoping identifier are reconsidered especially if decide to go with anything like unified SPF instead of (or in addition to) current MARID PRA proposal. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:37: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 LAA12151 for ; Thu, 26 Aug 2004 11:37: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 i7QFDmu8094011; Thu, 26 Aug 2004 08:13:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFDm0w094010; Thu, 26 Aug 2004 08:13:48 -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 i7QFDmE7094000 for ; Thu, 26 Aug 2004 08:13:48 -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, 26 Aug 2004 11:13:48 -0400 id 001976BC.412DFE2C.000065E9 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <868C8B09-F772-11D8-9196-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: acceptable licenses (Was: Can there be an early decision on the SenderID license?) Date: Thu, 26 Aug 2004 11:13:46 -0400 To: "IETF MARID WG" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2004, at 8:54 AM, wayne wrote: > Instead of addressing this issue, PHB has tried to reframe the > discussion. If you are admonishing Phil, your energy is misplaced. It is not your place to decide the schedules of this working group nor how consensus is arrived at in this working group. -andy From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:38: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 LAA12211 for ; Thu, 26 Aug 2004 11: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 i7QFBUcw093143; Thu, 26 Aug 2004 08:11: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 i7QFBUtW093142; Thu, 26 Aug 2004 08:11:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFBTJm093124 for ; Thu, 26 Aug 2004 08:11:29 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-103-225.area3.spcsdns.net ([68.245.145.169]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0LuT-0002wt-O1 for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 11:11:30 -0400 Message-ID: <412DFD96.104@solidmatrix.com> Date: Thu, 26 Aug 2004 11:11:18 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "IETF MXCOMP (E-mail)" Subject: DEPLOY: IPR/GPL Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The following two messages are from Eben Moglen of FSF and Larry Rosen of OSI. I have received permission from both of them to forward these messages to the list. And yes, they are both lawyers. (In my personal opinion, in light of the fact that the licensing situation is tricky, I would add that the deployment of this standard is likely to be hindered until this issue is resolved.) > -------- Original Message -------- > Subject: Re: Microsoft, Sender-ID and GPL > Date: Thu, 26 Aug 2004 10:57:28 -0400 > From: Eben Moglen > > The license posted by Microsoft is not compatible with GPL and is not > a free software compatible license. There are several problems, of > which the most severe is the requirement that anyone who wants to > redistribute a covered implementation must execute a license with > Microsoft. If you cannot give people code that they can redistribute > without permission, you are not giving them free software. This > would be the conclusion under all the meta-definitions of freedom: > the OSD, the FSD, and the Debian FSG. > > Eben ----- > -------- Original Message -------- > Subject: RE: Microsoft, Sender-ID and GPL > Date: Tue, 24 Aug 2004 19:38:37 -0700 > From: Lawrence Rosen > Organization: Rosenlaw & Einschlag > > This Microsoft license is *not* compatible with open source. > > /Larry Rosen There is also a quote in this news story (http://www.eweek.com/article2/0,1759,1639556,00.asp) from Larry Rosen: > Lawrence Rosen, a partner in the law firm Rosenlaw & Einschlag and > author of "Open Source Licensing: Software Freedom and Intellectual > Property Law," said he has "explained to Microsoft that their license > is expressly incompatible with the warranty of provenance in the > Academic Free License and the Open Software License." > > Specifically, he said, "the 'nontransferable, non-sublicenseable' > language in their reciprocal patent license imposes an impossible > administrative burden on the open-source development community and, > in essence, creates additional downstream patent licenses that will > be incompatible with the AFL/OSL and similar open-source licenses, > and with the open-source development process." > > Rosen added that some issues go beyond just open-source concerns. > "The requirement that 'If you would like a license from Microsoft > (e.g., rebrand, redistribute), you need to contact Microsoft > directly' gives Microsoft information about its competitors' plans > that it has no reason to know." > > In addition, he said, "No open-source license—and all of them allow > rebranding and distribution—can be conditioned on informing Microsoft > of anything at all. Other proposed licenses have been rejected by OSI > [Open Source Initiative] and FSF [Free Software Foundation] because > they required licensees to notify the licensor of their intentions." From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:44: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 LAA12764 for ; Thu, 26 Aug 2004 11:44: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 i7QFOM54097554; Thu, 26 Aug 2004 08:24:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFOMin097553; Thu, 26 Aug 2004 08:24: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 i7QFOLQ1097545 for ; Thu, 26 Aug 2004 08:24:21 -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 i7QFOKLC025016 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Aug 2004 08:24:21 -0700 Date: Thu, 26 Aug 2004 08:24:20 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Meng Weng Wong cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <20040826134009.GA3684@dumbo.pobox.com> Message-ID: References: <20040826134009.GA3684@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 Aug 2004, Meng Weng Wong wrote: > I believe that some people have spoken up and said that a > union solution was unappealing. I feel this way too. MAIL FROM and the PRA are fundamentally different and the records need a way to distinguish them. > I believe that the vast majority of all domains will have > exactly the same "blah blah blah". From the exact same conference of outsourced senders you were at my belief is that the "blah blah blah" would be very different for those senders. Many large commercial sites are beginning to indicate they will have a different blah blah blah. > Therefore, I suggest that we introduce the %{e} scope macro > to accommodate the very small fraction of domains who need > to distinguish the scopes, and allow everyone else to leave > things alone. I would like to refresh my memory on this. Do you have a pointer to a thread where this was discussed? -Rand From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11: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 LAA12843 for ; Thu, 26 Aug 2004 11:44:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFL2Xa096289; Thu, 26 Aug 2004 08: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 i7QFL23T096288; Thu, 26 Aug 2004 08:21:02 -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 i7QFL1No096280 for ; Thu, 26 Aug 2004 08:21:01 -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 i7QFJ8Qi023942 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Aug 2004 08:19:08 -0700 Date: Thu, 26 Aug 2004 08:19:08 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Jim Fenton cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <4.3.2.7.2.20040826050415.045ae9f8@mira-sjc5-1.cisco.com> Message-ID: References: <4.3.2.7.2.20040826050415.045ae9f8@mira-sjc5-1.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 Aug 2004, Jim Fenton wrote: > Of course, a new record type would be preferable, but there are > real-world deployment issues there. It is a good point of encouragement. -Rand From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:50: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 LAA13361 for ; Thu, 26 Aug 2004 11:50: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 i7QFPx8B098049; Thu, 26 Aug 2004 08:25: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 i7QFPx0S098048; Thu, 26 Aug 2004 08:25:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFPv32098002 for ; Thu, 26 Aug 2004 08:25:58 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:24:35 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:50:12 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:52:38 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:47:41 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEXEYv082235; Thu, 26 Aug 2004 07:33: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 i7QEXEWp082234; Thu, 26 Aug 2004 07:33:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEXEBM082224 for ; Thu, 26 Aug 2004 07:33:14 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 83D6726C084; Thu, 26 Aug 2004 16:33:40 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id BF7DF26C078; Thu, 26 Aug 2004 16:33:39 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i7QEXf93933929; Thu, 26 Aug 2004 16:33:41 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 3145CFACE; Thu, 26 Aug 2004 16:33:41 +0200 (CEST) Date: Thu, 26 Aug 2004 16:33:41 +0200 From: Stephane Bortzmeyer To: Mark Cc: IETF MARID WG Subject: Re: DEPLOY - reference implementation Message-ID: <20040826143341.GA19939@nic.fr> References: <412CE5F4.5010006@redhat.com> <20040826111249.GA5702@nic.fr> <200408261400.I7QE01HM006259@asarian-host.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408261400.I7QE01HM006259@asarian-host.net> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx2.nic.fr List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 14:47:42.0141 (UTC) FILETIME=[A3F83ED0:01C48B7B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 26, 2004 at 02:00:02PM +0000, Mark wrote a message of 96 lines which said: > > The first step is very simple, I attached my own implementation. Bug > > reports are welcome to show me where I've misread -pra. > > Just for the heck of it, here is my Perl implementation of PRA. :) Does anyone have a good corpus of "bordeline" mails to test the two implementations? (Although the algorithm is very simple, so we should not expect discrepancies.) From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:52: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 LAA13478 for ; Thu, 26 Aug 2004 11:52: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 i7QFS2hu098708; Thu, 26 Aug 2004 08:28:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFS1aG098707; Thu, 26 Aug 2004 08:28:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QFS09E098679 for ; Thu, 26 Aug 2004 08:28:01 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 62A711A6BC; Thu, 26 Aug 2004 17:28:00 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 27D171A69D for ; Thu, 26 Aug 2004 17:27:58 +0200 (CEST) Message-Id: <3hnLJt+qzxTulVQGEybPVw.md5@prosecco.oryx.com> Date: Thu, 26 Aug 2004 17:27:49 +0200 From: Arnt Gulbrandsen To: IETF MARID WG Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Granted, qmail isn't maintained. (And if you want to comment negatively on its quality, I shall offer not one word of disagreement.) But isn't that all beside the point? Surely exactly the same IP/licensing problems would still apply if djb were to release a new version tomorrow. Arnt From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:54: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 LAA13577 for ; Thu, 26 Aug 2004 11:54: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 i7QFYibs001026; Thu, 26 Aug 2004 08:34: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 i7QFYisH001025; Thu, 26 Aug 2004 08:34:44 -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 i7QFYhha001016 for ; Thu, 26 Aug 2004 08:34:43 -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 i7QFYih7027183 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Aug 2004 08:34:44 -0700 Date: Thu, 26 Aug 2004 08:34:44 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Carl Hutzler cc: IETF-MXCOMP Subject: Re: AOL's stance on SenderID and IPR issues 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: Thanks for the post Carl. One thing to clarify: > Our internal patent lawyer has reviewed the license agreement and said that > he found no IP issues and we are free to pursue a license to use it in our > infrastructure. Eric Allman's analysis states: "... the RFSIPL permits [end-user customers] to use Sender Id without executing a license." It would probably be good to clear up (as there has been some confusion on the list) that sites which are just publishing Sender ID records or installing commercial or open source Sender ID software *would not* need to get a patent license for the IPR (they would of course need to get a license for the copyrighted code they are installing) Your comment implies that AOL might need to execute a license in order to implement (ie, write) Sender ID code for your infrastructure. The question of if "in-house" development needs a license is an interesting one, but I wanted to make sure that this is in truth different from sites "implementing" *other people's software* in their environment. -Rand From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:55:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13641 for ; Thu, 26 Aug 2004 11:55:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFQqH7098309; Thu, 26 Aug 2004 08:26: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 i7QFQqDT098308; Thu, 26 Aug 2004 08:26:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFQo7u098279 for ; Thu, 26 Aug 2004 08:26:51 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:24:34 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:21:20 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:23:45 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:22:33 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE6qYE074398; Thu, 26 Aug 2004 07:06: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 i7QE6qOP074397; Thu, 26 Aug 2004 07:06:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE6p1q074385 for ; Thu, 26 Aug 2004 07:06:51 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7QE6rfI027980 for ; Thu, 26 Aug 2004 07:06:53 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 07:06:53 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: acceptable licenses (Was: Can there be an early decision on t he SenderID license?) Date: Thu, 26 Aug 2004 07:06:51 -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: 26 Aug 2004 14:22:33.0692 (UTC) FILETIME=[20DD31C0:01C48B78] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Instead of addressing this issue, PHB has tried to reframe the > discussion. Framing the discussion is a perogative of the co-chairs. You ar not a co-chair, therefore I have an equal right to frame the discussion. In the debating societies I am a member of you hold the debate before the vote. The motion from the floor is that the question be put. I oppose putting the question because we have merely heard opinion thus far, not argument. > > In > .vrsn.com> "Hallam-Baker, Phillip" writes: > > I have yet to see a statement that makes a valid legal argument > > that the license terms prohibit open source distribution. > > That is completely irrelevant. As Eric Allman pointed out, many of > the aspects of the SenderID create friction, and that is all that is > enough to question whether the SenderID license is worth it. My concern is that I believe that it is very likely that one or more patent trolls made applications after the publication of SPF. This has happened several times in the past, the applications are made by people who have no connection to the invention and are in effect perjured, but this has never been prosecuted. The perjured patent is then used to extort money from a company that uses the technology before it goes IPO. What was ASKED of Microsoft was to produce a license that made it possible to create and distribute open source code. Now that this has happened I beleive that the ground has been shifted. I do not see this issue being approached from the make it work point of view. > > The license terms are at least as open as the terms which the > > IETF has accepted in the past. > > The IETF has accepted RFCs in the past that have been horribly > designed and written. The fact that the IETF has made mistakes in the > past is hardly a good reason to ignore the current situation. The IETF IPR policy has received extensive examination at every level of the organization. If this group is going to overturn it then it has to provide a better argument than not wanting to be bothered. > > Larry Lessig is a lawyer, lets give him a call and hit his folk > > up for some pro bono. > > Please feel free to contact Larry. On Monday, I started making > contact with Eben Moglen (the FSF lawyer) for his input on whether the > SenderID license is compatible with the GPL. I chose Eben for a > couple of reasons. First off, he was involved with earlier > discussions with MS over this issue and therefore should be up to > speed on the subject. Secondly, Eric Allman has used quotes form Eben > in order to claim that the current SenderID license is acceptable. I have no problem with the license terms, so I'll leave those who have to call lawyers. > > First I would suggest that those wanting to make the argument that > > the license terms are not acceptable put them in a form that is > > more coherent than that advanced so far. In particular paying close > > attention to the fact that what is wanted is a license to > redistribute > > software without let or hinderance. > > No, this is backwards. The IETF requires rough consensus in order to > advance things. People who think that the SenderID license is > acceptable need to show that there is a rough consensus that it is > OK. Rough concensus is on the basis of facts, not opinions. > This working group does not need to accept the SenderID license > because is no worse than the worst license that the IETF has accepted > in the past. Rather, we need to look at what RFC3668 says: > > | 8. Evaluating alternative technologies in IETF working groups > | > | In general, IETF working groups prefer technologies > with no known IPR > | claims or, for technologies with claims against them, > an offer of > | royalty-free licensing. Looks to me like the second clause in the statement requires updating since royalty free is a necessary, not a sufficient condition. royalty free, reasonable and non-discriminatory is the generally understood criteria. The license offered by Microsoft clearly meets the preferred criteria. The 'or' conjunctive does not denote a preference. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11: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 LAA13703 for ; Thu, 26 Aug 2004 11: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 i7QFVlkv099964; Thu, 26 Aug 2004 08:31: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 i7QFVlTS099962; Thu, 26 Aug 2004 08:31:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFVgDu099902 for ; Thu, 26 Aug 2004 08:31:44 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:23:56 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:12:58 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:15:23 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:14:10 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDsiig070407; Thu, 26 Aug 2004 06:54: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 i7QDsioK070406; Thu, 26 Aug 2004 06:54:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDshkZ070396 for ; Thu, 26 Aug 2004 06:54:43 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-103-225.area3.spcsdns.net ([68.245.145.169]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0Ki9-00073P-Gt for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 09:54:42 -0400 Message-ID: <412DEB94.1030607@solidmatrix.com> Date: Thu, 26 Aug 2004 09:54:28 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: acceptable licenses (Was: Can there be an early decision on the SenderID license?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 14:14:10.0719 (UTC) FILETIME=[F5119AF0:01C48B76] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: >>Larry Lessig is a lawyer, lets give him a call and hit his folk >>up for some pro bono. > > > Please feel free to contact Larry. On Monday, I started making > contact with Eben Moglen (the FSF lawyer) for his input on whether the > SenderID license is compatible with the GPL. I chose Eben for a > couple of reasons. First off, he was involved with earlier > discussions with MS over this issue and therefore should be up to > speed on the subject. Secondly, Eric Allman has used quotes form Eben > in order to claim that the current SenderID license is acceptable. > I had conversations with Larry Rosen of OSI and someone from the FSF in the past few days. In their opinion this license is not compatible with the GPL and most other open source licenses. And yes - they are lawyers. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 11:58:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13758 for ; Thu, 26 Aug 2004 11:58:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFZK8G001248; Thu, 26 Aug 2004 08:35: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 i7QFZKGp001247; Thu, 26 Aug 2004 08:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFZFTM001192 for ; Thu, 26 Aug 2004 08:35:17 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:23:51 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:35:46 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:37:46 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:36:34 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEJceD078154; Thu, 26 Aug 2004 07:19: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 i7QEJcri078153; Thu, 26 Aug 2004 07:19:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEJbgj078135 for ; Thu, 26 Aug 2004 07:19:37 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 26 Aug 2004 10:19:31 -0400 id 002F4032.412DF173.0000510B From: David Blacka Organization: VeriSign, Inc. To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Thu, 26 Aug 2004 10:19:04 -0400 User-Agent: KMail/1.6.2 References: <4.3.2.7.2.20040826050415.045ae9f8@mira-sjc5-1.cisco.com> In-Reply-To: <4.3.2.7.2.20040826050415.045ae9f8@mira-sjc5-1.cisco.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408261019.04224.davidb@verisignlabs.com> List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 14:36:34.0882 (UTC) FILETIME=[16409A20:01C48B7A] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday 26 August 2004 8:12 am, Jim Fenton wrote: > Can anyone > clear up whether adding the prefix breaks wildcards, or were they already > broken? Since I don't know what you mean by "broken", I can't comment to whether or not wildcards are "already broken". BUT, if you publish: *.example.com. IN TXT "v=spf1 ..." *.example.com. IN TXT"spf2.0/pra ..." Then, if a query for "host.example.com IN TXT" would match the wildcard, the a query for "_marid.host.example.com IN TXT" would ALSO match the wildcard. So, the problem isn't that wildcards and marid records don't work, it is just that when using wildcards, the _marid prefix no longer gets you *just* the spf2.0/pra record. I.e. the current status quo. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 12:07: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 MAA14472 for ; Thu, 26 Aug 2004 12:07: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 i7QFh5Wr003271; Thu, 26 Aug 2004 08:43: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 i7QFh5L9003270; Thu, 26 Aug 2004 08:43:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFh2ai003252 for ; Thu, 26 Aug 2004 08:43:03 -0700 (PDT) (envelope-from admin@asarian-host.net) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:23:44 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:12:10 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:14:17 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:13:12 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE04sF072211; Thu, 26 Aug 2004 07:00: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 i7QE040J072210; Thu, 26 Aug 2004 07:00:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE02O5072197 for ; Thu, 26 Aug 2004 07:00:03 -0700 (PDT) (envelope-from SRS0=wCa/I6YQ=LQ=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7QE02ed006269 for ; Thu, 26 Aug 2004 16:00:02 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408261400.I7QE01HM006259@asarian-host.net> Date: Thu, 26 Aug 2004 14:00:02 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY - reference implementation X-Trace: N2RfEMcdLVr7Cuy0wdV9tKXqn75J9ce+TM1l3h5/LhApEDyL+aGLXBZuTdm7Y0n2syWdUKl8uGPwOOii7xehxw== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <412CE5F4.5010006@redhat.com> <20040826111249.GA5702@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03D9_01C48B85.BCA6DD60" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQS3s4jFqW1BleBN9AQGRKAf+IdV6kNH0lBhRxk40nVzo8frILtC+Yl+J ESOLq2H8+8No782tarKslhz1DbJ8xRYDik7iDKCTfOKfsF7loojrCylA4UugW0fH bFQP/fMl2URZ56tFd4BFqn1qg3RZ3sMyPU+mjFBw83bTNPq2JPjCgXawJ3RV6L1Z 0oNikcBzcvBaurIfvnyCXu7LRgNPVYRK0RhbowZBEhtFLImUhxA0e8mrNbQhiS7L yMDAipL3BhRj0ckn5QtSMteNUMVt7uhyJfx3KFisYInT5epumzz+huaTh8QAWtYT P7g4IBtLQ/xyWe8xLdSbZifObakjfA5rlfcNgvtomKUyQSKy2sFxGA== =GHZA List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 14:13:12.0345 (UTC) FILETIME=[D2467090:01C48B76] 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_03D9_01C48B85.BCA6DD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > Basically, Sender-ID is "get the PRA", then "get the PRD", send "apply > SPF to the PRD". > > The last step is complicated but there are many free software SPF > implementations. > > The first step is very simple, I attached my own implementation. Bug > reports are welcome to show me where I've misread -pra. Just for the heck of it, here is my Perl implementation of PRA. :) - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx ------=_NextPart_000_03D9_01C48B85.BCA6DD60 Content-Type: application/octet-stream; name="pra.pl" Content-Disposition: attachment; filename="pra.pl" Content-Transfer-Encoding: quoted-printable #!/usr/local/bin/perl -w=0A= #=0A= # AIM: Implements the PRA (Purported Responsible Address) algorithm=0A= # described in Internet-Draft draft-ietf-marid-par-00.txt.=0A= #=0A= # USE: ./pra.pl =0A= #=0A= # Requires: Perl.=0A= # mailTools-1.64=0A= #=0A= # LICENCE: trivial work, not patentable, not licenceable.=0A= #=0A= # WARNING: Microsoft claims a patent on the PRA algorithm.=0A= # The author did not requested a licence.=0A= #=0A= # AURHOR: Mark Kramer =0A= =0A= use Mail::Address;=0A= use strict;=0A= =0A= my $header_file =3D $ARGV[0] or die "Usage: $0 ";=0A= my $header;=0A= =0A= if (open (HEADERS, $header_file)) {=0A= $header .=3D $_ while ();=0A= close (HEADERS);=0A= } else {=0A= die "Cannot open $header_file!\n";=0A= }=0A= =0A= # Stream-line continuation lines:=0A= =0A= $header =3D~ s/\n\s+/\t/mg;=0A= =0A= # Remove (key, value) pairs from header where 'value' does not exist:=0A= =0A= $header =3D~ s/^[^:]*:\s*\n//mg;=0A= =0A= # Process the split-up-per-line $header in reverse order,=0A= # so that the last key set for $headers(key} is actually=0A= # the first (non-empty!) occurance thereof!=0A= =0A= my %headers =3D map { split (/: */, $_, 2) } reverse split (/\n/, lc = ($header));=0A= my $pra =3D $headers{'resent-sender'} || $headers{'resent-from'} || = $headers{'sender'} || $headers{'from'} || undef;=0A= =0A= # The next foreach loop looks a bit weird; but=0A= # Mail::Address -> parse expects an array, not a=0A= # scalar context.=0A= =0A= if ($pra) {=0A= foreach (Mail::Address -> parse ($pra)) {=0A= print "PRA: " . $_ -> address . "\n";=0A= last;=0A= }=0A= }=0A= =0A= exit 0; ------=_NextPart_000_03D9_01C48B85.BCA6DD60-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 12:10: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 MAA14748 for ; Thu, 26 Aug 2004 12:10: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 i7QFo65A004934; Thu, 26 Aug 2004 08:50: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 i7QFo60H004933; Thu, 26 Aug 2004 08:50:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFo4V6004902 for ; Thu, 26 Aug 2004 08:50:05 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:22:55 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 15:57:41 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 15:59:12 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 15:57:00 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDgJqk066523; Thu, 26 Aug 2004 06:42:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QDgJsd066522; Thu, 26 Aug 2004 06:42:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDgINB066513 for ; Thu, 26 Aug 2004 06:42:18 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7QDeVqv003335; Thu, 26 Aug 2004 06:40:31 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 06:40:31 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jim Fenton'" , Rand Wacker , ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve) Date: Thu, 26 Aug 2004 06:40:31 -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: 26 Aug 2004 13:57:01.0018 (UTC) FILETIME=[8F51B3A0:01C48B74] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >The solution I would suggest is to put spfv2/pra records in > a sub-domain > >such as _marid.company.com. While it would be nice to recommend that > >people begin allowing TCP DNS queries, it is unlikely that > the highest > >volume sites would ever want to implement such. > > I think it was brought up earlier that using a prefix like > _marid would break the use of wildcards (can't do > _marid.*.example.com). But it wasn't clear (to me, at least) > whether wildcards would work in this application, even > without the prefix. Wildcard support would be very nice to > have, to provide symmetry with wildcard MX records for > incoming mail. Can anyone clear up whether adding the prefix > breaks wildcards, or were they already broken? The situation with the prefix is as follows: 1) Standard (i.e. AXFR communicatable wildcards) do not work for ANY Sender-ID use case. A wildcard only produces a match if there is no data whatsoever in a node. This means that this type of wildcard cannot be used to make any assertions about machines that have a domain name entry. 2) Synthetic wildcards work fine, but are not supported in the AXFR interchange format. 3) Prefixing does not prevent the use of wildcards, but if a wildcard is used the advantage of using a prefix is lost. I.E. *.example.com will match _spf1.example.com and _spf2.example.com 4) Some tools do not support prefix use - this is not a major concern since I would expect sender-id to be promoted mainly through purpose driven tools not through grovelling TXT entries. My opinion is that we should move to a prefix if we introduce a new version identifier. Otherwise we should not. There is a value to using a prefix but it is not by itself sufficient to make a change worthwhile. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 12:11:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14796 for ; Thu, 26 Aug 2004 12:11:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFmuOc004615; Thu, 26 Aug 2004 08:48:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFmui2004614; Thu, 26 Aug 2004 08:48:56 -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 i7QFmtJp004607 for ; Thu, 26 Aug 2004 08:48:55 -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 i7QFmve8030467 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Aug 2004 08:48:58 -0700 Date: Thu, 26 Aug 2004 08:48:57 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: John Glube cc: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> Message-ID: References: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, thanks for the reply. One thing I want to start by saying (and then I'm going to leave the discussion for after last call), its becoming clear that the most fundamental disagreement on this list has to do with the approach of doing *channel* authentication versus *message* authentication. I say this because you tend to hold SPF Classic and Sender ID as equivalent in your response, which I do not. > From your discussions with managers of large email > infrastructures, who are seeing a problem with packet size; > along with the big ISPs who are not interested in using TCP > to receive email because of cost, does it make more sense > not to change the version string? No. Both I and the people looking to implement these records feel quite strongly that using the same record for both is very dangerous. In fact, these largest sites are the ones who are *most* likely to have different records (bit of a Catch 22 there). > It was felt folks who implemented SPF were early adopters. > By changing the version string, this would freeze SPF and > folks would move ahead with Sender-ID. > > What you are telling us is the direct opposite. The truth is that there are some very large sites which have already begun asking senders to publish SPF records. There are other large sites that will be asking senders to publish Sender ID records. (I can think of a third large site that will ask for DomainKeys later ;) The goal of all of these senders is to get their mail through, they don't care so much how they have to do that. > Some of the Big ISPs are using SPF to detect email forgery > at the pre data stage, while telling folks, do you want > less content filtering? Publish an SPF record. ^email forgery^channel forgery. Also for most receivers I've talked to, "pre data" doesn't matter since for the worst spam the packets are already wedged in to their TCP receive buffers. > (Of course this achieves the desired objective of sender > authentication, thwarting spoofing and other steps taken to > hide identity, by getting everyone out in the open.) No offense John, but this is a sub-concious troll to bring the debate back to SPF Classic vs Sender ID. ;) > With the premise of enhanced email delivery, along with > protecting against domain spoofing, SPF is gaining > implementation momentum among domain owners. Enhanced email delivery, yes, but no-one I've talked to is under the delusion that SPF Classic protects against domain spoofing in the "what the user sees" context > This leads one to the conclusion the solution is instead of > creating a sub domain for Sender-ID records, rather it is > not to change the version string. Incorrect conclusion. > P.S. Another question. Since the Big ISPs do not want to > use TCP to check authentication for email delivery, does > this mean from a practical perspective, the Big ISPs would > prefer to create a mirror data base of authentication > records within their own networks and when a domain owner > makes a change, the domain owner's DNS server could > propagate the change through out the mirrored sites? This is functionality already inherent in DNS, which is one of the things that makes it appealing for a task like this. Cheers - Rand From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 12:26: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 MAA15737 for ; Thu, 26 Aug 2004 12:26: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 i7QFwJGf007115; Thu, 26 Aug 2004 08: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 i7QFwJCT007114; Thu, 26 Aug 2004 08:58:19 -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 i7QFwITA007103 for ; Thu, 26 Aug 2004 08:58:19 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7QG6YM0022174 for ; Thu, 26 Aug 2004 09:06:34 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7QG6YfR022171 for ; Thu, 26 Aug 2004 09:06:34 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 Aug 2004 09:06:34 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: MAIL LOOP AND DUPLICATION OF POSTS 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: ATTENTION MAIL ADMINISTRATOR OF THIS LIST. We have a mail loop as somebody is relaying messages already posted to the list back to the list resulting duplicate (and possibly soon triplicate) messages. I'm posting here headers of the post which I received in duplicate, I believe the duplication is being caused by somebody at gfi.com. Please investigate immediatly and if necessary temporarily suspend the subscriber involved. ---------- Forwarded message ---------- Return-Path: Received: from above.proper.com (above.proper.com [208.184.76.39]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7QFuErW021783 for ; Thu, 26 Aug 2004 08:56:14 -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 i7QFVlkv099964; Thu, 26 Aug 2004 08:31: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 i7QFVlTS099962; Thu, 26 Aug 2004 08:31:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFVgDu099902 for ; Thu, 26 Aug 2004 08:31:44 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:23:56 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:12:58 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:15:23 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:14:10 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDsiig070407; Thu, 26 Aug 2004 06:54: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 i7QDsioK070406; Thu, 26 Aug 2004 06:54:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDshkZ070396 for ; Thu, 26 Aug 2004 06:54:43 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-103-225.area3.spcsdns.net ([68.245.145.169]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0Ki9-00073P-Gt for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 09:54:42 -0400 Message-ID: <412DEB94.1030607@solidmatrix.com> Date: Thu, 26 Aug 2004 09:54:28 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: acceptable licenses (Was: Can there be an early decision on the SenderID license?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com X-Source: X-Source-Args: X-Source-Dir: List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 14:14:10.0719 (UTC) FILETIME=[F5119AF0:01C48B76] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sokol.elan.net X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 12:26:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15760 for ; Thu, 26 Aug 2004 12:26: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 i7QG0qPo007714; Thu, 26 Aug 2004 09:00: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 i7QG0qES007713; Thu, 26 Aug 2004 09:00:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QG0p6Y007692 for ; Thu, 26 Aug 2004 09:00:51 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 26 Aug 2004 12:00:49 -0400 id 002F406A.412E0931.000062FE From: David Blacka Organization: VeriSign, Inc. To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve) Date: Thu, 26 Aug 2004 12:00:21 -0400 User-Agent: KMail/1.6.2 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: <200408261200.21556.davidb@verisignlabs.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday 26 August 2004 11:10 am, Hallam-Baker, Phillip wrote: > While David is right, there is also the corollary that *.example.com > will only match nodes that do not exist at all. So there are two issues, > do wildcards work as expected, is the wildcard useful at all. The matching > behavior means that the wildcard is not useful for the use cases given. > > i.e. if we have > > a.example.com > > *.example.com. IN TXT "v=spf1 ..." > > Will match _marid.b.example.com, b.example.com but not a.example.com > regardless of whether a has TXT records or not. This is correct. > So you can't use a wildcard to give a default SPF record for DNS > names of hosts that exist. Only the hosts that don't exist will match. > I don't know what happens for _marid.a.example.com, I think it should > not match but one of the DNS people can say for sure. You are correct, it does not match. The existence of names block wildcards at that name, and for any name below that name. To be explict, if your zone has: *.example.com. IN TXT "spf2.0/..." a.example.com. IN A 1.2.3.4 but does not contain: b.example.com. Then queries for "b.example.com. IN TXT, _marid.b.example.com. IN TXT, something-else.b.example.com. IN TXT", will all return the TXT record. Queries for "a.example.com. IN TXT, _marid.a.example.com. IN TXT, anything-else.a.example.com. IN TXT" will not return the TXT record. > IF _marid.a.example.com did match the wildcard then it would be a way > to make the wildcards useful. For some use cases. It is true that wildcards are not useful as a default "fall-back" record solution. They never were. To my mind, the paramount issue of wildcard wrt MARID is that for folks who *currently* use wildcards (i.e., for wildcard MX records), the MARID solution should be deployable, and it is, with or without a _marid prefix. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 12:28: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 MAA15928 for ; Thu, 26 Aug 2004 12:28: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 i7QFuL1V006693; Thu, 26 Aug 2004 08:56: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 i7QFuLu1006692; Thu, 26 Aug 2004 08:56:21 -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 i7QFuL9d006684 for ; Thu, 26 Aug 2004 08:56:21 -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 i7QFuNeT031945 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 26 Aug 2004 08:56:24 -0700 Date: Thu, 26 Aug 2004 08:56:23 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve) 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: Phillip brings up a very good point here because if the desire for wildcards is to make it easy for sites to indicate where mail *does not* come from for hosts under their domain, then this application is pretty moot because every sane MTA on the planet /already/ rejects mail for this there is no resolvable FQDN (why bother accepting a message if you know up front you couldn't ever reply to it). -Rand On Thu, 26 Aug 2004, Hallam-Baker, Phillip wrote: > While David is right, there is also the corollary that *.example.com > will only match nodes that do not exist at all. So there are two issues, > do wildcards work as expected, is the wildcard useful at all. The matching > behavior means that the wildcard is not useful for the use cases given. > > i.e. if we have > > a.example.com > > *.example.com. IN TXT "v=spf1 ..." > > Will match _marid.b.example.com, b.example.com but not a.example.com > regardless of whether a has TXT records or not. > > So you can't use a wildcard to give a default SPF record for DNS > names of hosts that exist. Only the hosts that don't exist will match. > > > I don't know what happens for _marid.a.example.com, I think it should > not match but one of the DNS people can say for sure. > > > IF _marid.a.example.com did match the wildcard then it would be a way > to make the wildcards useful. > > > From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 12:42:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17298 for ; Thu, 26 Aug 2004 12:42:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGHoSk011066; Thu, 26 Aug 2004 09:17: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 i7QGHo0t011065; Thu, 26 Aug 2004 09:17:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGHnrI011057 for ; Thu, 26 Aug 2004 09:17:49 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7QGHq3Z004716 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 26 Aug 2004 09:17:52 -0700 Date: Thu, 26 Aug 2004 09:17:52 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: IETF MARID WG Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ In-Reply-To: <3hnLJt+qzxTulVQGEybPVw.md5@prosecco.oryx.com> Message-ID: References: <3hnLJt+qzxTulVQGEybPVw.md5@prosecco.oryx.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hmm, IANAL, and believe it or not this has nothing to do with who I work with/for, but from what I've learend about Open Source licensing in the past few weeks it would seem to me that the qmail license itself is incompatible with the definition of open source (specifically that it prohibits re-distribution and sub-licensability). djb's choice of licensing terms is djb's choice, and this group probably shouldn't get too hung up on the requirements of a software package that prohibits *any* modifications to its base code. -Rand On Thu, 26 Aug 2004, Arnt Gulbrandsen wrote: > But isn't that all beside the point? Surely exactly the same > IP/licensing problems would still apply if djb were to release a new > version tomorrow. > > Arnt > > From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 13:03: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 NAA18604 for ; Thu, 26 Aug 2004 13:03: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 i7QGeqm7014700; Thu, 26 Aug 2004 09:40:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QGeq5g014699; Thu, 26 Aug 2004 09:40: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 i7QGeppJ014686 for ; Thu, 26 Aug 2004 09:40: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 1C0NIr-0003QB-5J for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 11:40:54 -0500 To: "IETF MARID WG" References: <412DFD96.104@solidmatrix.com> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 26 Aug 2004 11:40:15 -0500 In-Reply-To: <412DFD96.104@solidmatrix.com> (Yakov Shafranovich's message of "Thu, 26 Aug 2004 11:11:18 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: DEPLOY: IPR/GPL Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <412DFD96.104@solidmatrix.com> Yakov Shafranovich writes: > The following two messages are from Eben Moglen of FSF and Larry Rosen > of OSI. I have received permission from both of them to forward these > messages to the list. And yes, they are both lawyers. Ok, in light of opinions express by these two knowlegable lawyers that the SenderID license is not compatible with open source licenses, the GPL, AFL and OSL in particular, I now feel comfortable saying that I strongly oppose the advancement of the marid-core and marid-pra I-Ds. They can not be deployed in too much of the existing email infrastructure on the Internet. I also oppose the advancement of marid-submitter on the grounds that it is irrelevant without the other two I-Ds. In <868C8B09-F772-11D8-9196-000A95B3BA44@hxr.us> Andrew Newton writes: > On Aug 26, 2004, at 8:54 AM, wayne wrote: > >> Instead of addressing [the suggestion of an early decision on the >> SenderID license], PHB has tried to reframe the discussion. > > If you are admonishing Phil, your energy is misplaced. It is not your > place to decide the schedules of this working group nor how consensus > is arrived at in this working group. You are right, it is not my place, it is *your* place. And you didn't answer the question in your reply, I ask you again: Can there be an early decision on the SenderID license? While I think license issue is very important to discuss, the volume is such that it is drowning out most other discussions about the I-Ds. In <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> Margaret Olson writes: > I largely agree with Phill, but let me try to present the issue a > slightly different way. I use several MTA implementations, both > commercial and open source. I've concluded that the current license > will allow me to continue to have a good selection of open source and > commercial choices with Sender ID implementations. Open source is open > source - Sender ID is sufficiently valuable that I'm convinced that > viable Sender ID variants will emerge, even if they are not > distributed in quite the same way that the code is today. Both Eric > Allman and Phill have discussed ways to approach this problem. I am > speaking as someone who intends to implement receive side Sender ID > as soon as possible. I would be interested in learning on what basis you think that open source developers will risk violating the open source licenses in order to support SenderID. Other than Eric Allman, I know of no other open source developer who is willing to even do the work needed to support SenderID with the current license. Who do you think will do the required work? Are you offering to pay for the development they way Meng offered for SPF? (Mind you, Meng didn't end up having to pay much since, unlike SenderID with the current license, many open source developers volunteered.) -wayne From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 13:08: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 NAA19144 for ; Thu, 26 Aug 2004 13:08: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 i7QGmF5p015433; Thu, 26 Aug 2004 09:48: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 i7QGmFoa015430; Thu, 26 Aug 2004 09:48:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGm9ks015420 for ; Thu, 26 Aug 2004 09:48:15 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7QGm8sQ017517; Thu, 26 Aug 2004 09:48:09 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 09:47:49 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Arnt Gulbrandsen'" , IETF MARID WG Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 09:47: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: > Granted, qmail isn't maintained. (And if you want to comment > negatively > on its quality, I shall offer not one word of disagreement.) > > But isn't that all beside the point? Surely exactly the same > IP/licensing problems would still apply if djb were to release a new > version tomorrow. If QMail was actively maintained the license issues would be exactly the same as for any other mailer. The problems come from the fact that the mailer is abandonware and the license prohibits any other party taking it on. I would not waste my time maintaining QMail, I would replace it wholesale or use one of the many other fine mail systems out there. Phill From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 13: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 NAA21135 for ; Thu, 26 Aug 2004 13:25: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 i7QH69iU017355; Thu, 26 Aug 2004 10:06:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QH69DS017354; Thu, 26 Aug 2004 10:06:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.e-dialog.com (mail1.e-dialog.com [64.28.75.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QH68f6017345 for ; Thu, 26 Aug 2004 10:06:08 -0700 (PDT) (envelope-from jeff.macdonald@e-dialog.com) Received: from [10.0.40.189] (jm-node4.e-dialog.com [10.0.40.189]) by mail1.e-dialog.com (8.12.11/8.12.10) with ESMTP id i7QH63mq022852; Thu, 26 Aug 2004 13:06:03 -0400 Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) From: Jeff Macdonald To: Rand Wacker Cc: John Glube , ietf-mxcomp@imc.org In-Reply-To: References: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> Content-Type: text/plain Organization: E-Dialog Message-Id: <1093539963.30660.28.camel@jmacdonald-work.e-dialog.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 26 Aug 2004 13:06:03 -0400 Content-Transfer-Encoding: 7bit X-Spam-Hits: -4.4 IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-26 at 11:48, Rand Wacker wrote: > No. Both I and the people looking to implement these records feel quite > strongly that using the same record for both is very dangerous. In fact, > these largest sites are the ones who are *most* likely to have different > records (bit of a Catch 22 there). Could you give an example? Or point to one is such an example exists? From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 13:46:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22814 for ; Thu, 26 Aug 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 i7QHQBg7019082; Thu, 26 Aug 2004 10:26: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 i7QHQBOd019081; Thu, 26 Aug 2004 10:26:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHQA4k019074 for ; Thu, 26 Aug 2004 10:26:10 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1C0O0j-0006ji-8y for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 12:26:13 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Thu, 26 Aug 2004 12:26:05 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Thu, 26 Aug 2004 07:49:42 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: >> > Or an alternative MTA :-) >> >> I'm not sure that is really a joking matter. We aren't supposed to >> talk about "hidden agendas", but since you raised the issue, I'll ask >> directly: >> >> Is your goal in supporting the SenderID license to get people to use >> "an alternative MTA", say the one that Harry and Jim work on? > > QMail is not being maintained. The license terms make it impossible > for it to be maintained. This is incorrect. Qmail *is* being maintained, just not by DJB. As I mentioned in my first post[1] about possible qmail conflicts with the SenderID license, the qmail community has to use patches to maintain the program. This makes life hard, but apparently, enough people like it that qmail is still one of the most popular MTAs (possibly the second most popular after sendmail). > I don't think that a standards group should be constrained by the > license terms of an unsupported product that has not been maintained > for years and is unlikely to be maintained in the future. You are right, we should not be constrained by licensing terms of packages. We should, however be constrained by deployment issues. The possibility that requiring every single user of qmail to get a signed license from Microsoft is a reason for concern. (Yes, this is orders of magnitude more work than the patches that qmail users have to do.) >> > If I had to patch Qmail the way I would do it is as follows: >> > >> > [ideas snipped] >> >> Your scheme does not match the design of qmail. What you are >> suggesting is a major rewrite of the qmail MTA. > > Actually not, it is many years since I looked at QMail, but this is > the type of modification I used to do in a day or so. > > Making a call out to a sharred library is no different in principle > than making a call out to an object library. I think you should look at the qmail source again. It makes a several fork/exec's on each SMTP transaction. Despite the fork/execs, qmail is still very fast because it doesn't do any expensive operations such as your suggested dlopen. While in principle, what you have suggested might work, in practice, what you have suggested is a non-starter. In Rand Wacker writes: > [...], but from what I've learend about Open Source licensing in the > past few weeks it would seem to me that the qmail license itself is > incompatible with the definition of open source [...] Yes, you are correct, and I said as much in my first post[1] on the subject of qmail. I do not like qmail because of this and for all the reasons that PHB also complained about. However, Arnt is right, this is besides the point. My concern is not whether the SenderID license causes problems with any specific program, open source, proprietary, or otherwise, but whether the SenderID license causes problems with any major MTA and/or spam filter. -wayne [1] http://www.imc.org/ietf-mxcomp/mail-archive/msg03638.html From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 13:53:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23272 for ; Thu, 26 Aug 2004 13:53: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 i7QHXvGN019524; Thu, 26 Aug 2004 10:33:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QHXvnN019523; Thu, 26 Aug 2004 10:33:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts22-srv.bellnexxia.net (tomts22-srv.bellnexxia.net [209.226.175.184]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHXuZu019517 for ; Thu, 26 Aug 2004 10:33:56 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040826173359.YUZ15743.tomts22-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 26 Aug 2004 13:33:59 -0400 From: "John Glube" To: "'Rand Wacker'" Cc: Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Thu, 26 Aug 2004 13:33:37 -0400 Message-ID: <011e01c48b92$d2081e50$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QHXuZu019518 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Rand, A couple of quick comments: * I appreciate your clarifying that the need is to have separate records, because of the senders' configuration. * You suggest I am putting SPF classic and Sender ID on the same level, or wanting to get into the SPF classic v Sender ID debate. You base this in part on my statement: > (Of course this achieves the desired objective of sender > authentication, thwarting spoofing and other steps taken to > hide identity, by getting everyone out in the open.) The statement reflects a synopsis of the FTC's view of the value of sender authentication, which is the perspective I have been using to view what is going on in an effort to stay objective in my own thinking. My view from a security perspective is that the best approach is to not rely on either one approach or one data set, but to do both message and channel authentication using a variety of data sets. I agree this discussion concerns last call for Sender-ID. I am not wanting to get into a debate over one approach versus another. The issue is: * Whether within Sender-ID it made more sense to go with the same version of records as SPF. You have raised a catch 22 problem for larger organizations with complex records. Going the sub-domain route raises catch 22 problems for the vast number of individual domain holders. Needless to say, I am sure the design and security experts will come forward with a solution. From my own perspective, although some may not consider it directly relevant to last call of any particular proposal, given the issues, infrastructure and underlying import of email, the question in my mind always remains: * How would the FTC view what is decided given the FTC mandate to protect the US consumer's interest, ensure competition and protect against unfair trade? I also keep in the back of my mind that the FTC has clearly stated, if industry does not get it right, (what is right of course being unclear as it helps to keep people on their toes) the Feds reserve the right to step in and do the job. As to the rest of your comments, I greatly appreciate your elaborations. Cheers, John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 13:53:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23348 for ; Thu, 26 Aug 2004 13:53:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHXTTw019458; Thu, 26 Aug 2004 10:33:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QHXTNg019457; Thu, 26 Aug 2004 10:33:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from localhost.localdomain (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHXSSe019443 for ; Thu, 26 Aug 2004 10:33:29 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i7QHXKqF022266; Thu, 26 Aug 2004 10:33:20 -0700 Subject: RE: Can there be an early decision on the SenderID license? From: Ryan Ordway To: "Hallam-Baker, Phillip" Cc: "'IETF MARID WG'" In-Reply-To: References: Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1093541599.21871.6.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 26 Aug 2004 10:33:19 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-25 at 20:56, Hallam-Baker, Phillip wrote: > > Right now, we are supposed to be reviewing all of the documents. > > However, as demonstrated in the "DEPLOY/IPR: Fundamental > > Disagreements, or Get On With It" thread, there doesn't seem to be a > > rough consensus that the SenderID license is acceptable. (Actually, > > there appears to be a rough consensus that it isn't acceptable.) > > I have yet to see a statement that makes a valid legal argument > that the license terms prohibit open source distribution. It will not take a valid legal argument to derail the widespread deployment of any standard that comes from this working group. All that is needed is the, perhaps unfounded, fear that implementing SenderID or any other standard with nebulous IPR issues is going to bite the user in a tender area. FUD can be a quite powerful deterrent. Why spend so much time working on a standard that is so engulfed in it? Ryan -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:09: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 OAA24218 for ; Thu, 26 Aug 2004 14:09: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 i7QHmocb021010; Thu, 26 Aug 2004 10:48:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QHmoZC021009; Thu, 26 Aug 2004 10:48:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHml3w020965 for ; Thu, 26 Aug 2004 10:48:48 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:43:51 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:22:39 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 15:55:06 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 15:56:53 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 15:53:30 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDcvMJ065485; Thu, 26 Aug 2004 06: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 i7QDcv2r065484; Thu, 26 Aug 2004 06:38:57 -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 i7QDcuCv065455 for ; Thu, 26 Aug 2004 06:38:56 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 15906 invoked from network); 26 Aug 2004 13:40:39 -0000 Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 26 Aug 2004 13:40:39 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit From: Margaret Olson Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 09:38:52 -0400 To: "IETF MARID WG" X-Mailer: Apple Mail (2.619) List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 13:53:30.0946 (UTC) FILETIME=[121B4220:01C48B74] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2004, at 8:26 AM, wayne wrote: > > In > > "Hallam-Baker, Phillip" writes: > >>> If not, wouldn't this mean that users of qmail that want to support >>> SenderID (which we hope will be all of them) need to get a license >>> from Microsoft? >> >> Or an alternative MTA :-) > > Is your goal in supporting the SenderID license to get people to use > "an alternative MTA", say the one that Harry and Jim work on? Wayne and others. I largely agree with Phill, but let me try to present the issue a slightly different way. I use several MTA implementations, both commercial and open source. I've concluded that the current license will allow me to continue to have a good selection of open source and commercial choices with Sender ID implementations. Open source is open source - Sender ID is sufficiently valuable that I'm convinced that viable Sender ID variants will emerge, even if they are not distributed in quite the same way that the code is today. Both Eric Allman and Phill have discussed ways to approach this problem. I am speaking as someone who intends to implement receive side Sender ID as soon as possible. So while the license is less than ideal, it's sufficient. It is also fundamentally defensive, and anyone with significant assets contemplating donating IPR has to concern themselves with the defensive legal issues. The fundamental goal is to make sure you can use your own IPR after you have donated it, which is otherwise not assured. I would not like to see contributions to the IETF limited to individuals and corporations who are not successful enough to have this kind of legal concern. For one thing, it would rule out all organizations with significant R&D budgets. Followed to it's logical conclusion, this approach to license requirements give us problems even with open source donations, since some of the open source licenses are mutually incompatible. I have also had the impression that some folks on the list are expecting Microsoft to give them what amounts to legal advice. A lawyer representing me, being paid by me, can't give you legal advice about how to deal with me - there is a conflict of interest. So where Microsoft does provide clarifications or suggestions it will be caveated it left and right with "consult your own lawyer" just to make sure you are not confused about whose interests are being represented. This is how the legal system works; it's not some sort of Microsoft conspiracy to make everyone waste money on legal advice. In the spirit of frugality, I applaud Wayne's contacting of Eben Moglen. It's always a good idea to avoid paying a lawyer (or anyone else, for that matter) to come up to speed on a particular subject. Margaret. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:09: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 OAA24220 for ; Thu, 26 Aug 2004 14:09: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 i7QHoSao021118; Thu, 26 Aug 2004 10:50: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 i7QHoSAH021117; Thu, 26 Aug 2004 10:50:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHoQm9021100 for ; Thu, 26 Aug 2004 10:50:27 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:43:48 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 18:53:42 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 18:56:08 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 18:55:08 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGeqm7014700; Thu, 26 Aug 2004 09:40:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QGeq5g014699; Thu, 26 Aug 2004 09:40: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 i7QGeppJ014686 for ; Thu, 26 Aug 2004 09:40: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 1C0NIr-0003QB-5J for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 11:40:54 -0500 To: "IETF MARID WG" References: <412DFD96.104@solidmatrix.com> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 26 Aug 2004 11:40:15 -0500 In-Reply-To: <412DFD96.104@solidmatrix.com> (Yakov Shafranovich's message of "Thu, 26 Aug 2004 11:11:18 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: DEPLOY: IPR/GPL Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 16:55:08.0626 (UTC) FILETIME=[71A14320:01C48B8D] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <412DFD96.104@solidmatrix.com> Yakov Shafranovich writes: > The following two messages are from Eben Moglen of FSF and Larry Rosen > of OSI. I have received permission from both of them to forward these > messages to the list. And yes, they are both lawyers. Ok, in light of opinions express by these two knowlegable lawyers that the SenderID license is not compatible with open source licenses, the GPL, AFL and OSL in particular, I now feel comfortable saying that I strongly oppose the advancement of the marid-core and marid-pra I-Ds. They can not be deployed in too much of the existing email infrastructure on the Internet. I also oppose the advancement of marid-submitter on the grounds that it is irrelevant without the other two I-Ds. In <868C8B09-F772-11D8-9196-000A95B3BA44@hxr.us> Andrew Newton writes: > On Aug 26, 2004, at 8:54 AM, wayne wrote: > >> Instead of addressing [the suggestion of an early decision on the >> SenderID license], PHB has tried to reframe the discussion. > > If you are admonishing Phil, your energy is misplaced. It is not your > place to decide the schedules of this working group nor how consensus > is arrived at in this working group. You are right, it is not my place, it is *your* place. And you didn't answer the question in your reply, I ask you again: Can there be an early decision on the SenderID license? While I think license issue is very important to discuss, the volume is such that it is drowning out most other discussions about the I-Ds. In <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> Margaret Olson writes: > I largely agree with Phill, but let me try to present the issue a > slightly different way. I use several MTA implementations, both > commercial and open source. I've concluded that the current license > will allow me to continue to have a good selection of open source and > commercial choices with Sender ID implementations. Open source is open > source - Sender ID is sufficiently valuable that I'm convinced that > viable Sender ID variants will emerge, even if they are not > distributed in quite the same way that the code is today. Both Eric > Allman and Phill have discussed ways to approach this problem. I am > speaking as someone who intends to implement receive side Sender ID > as soon as possible. I would be interested in learning on what basis you think that open source developers will risk violating the open source licenses in order to support SenderID. Other than Eric Allman, I know of no other open source developer who is willing to even do the work needed to support SenderID with the current license. Who do you think will do the required work? Are you offering to pay for the development they way Meng offered for SPF? (Mind you, Meng didn't end up having to pay much since, unlike SenderID with the current license, many open source developers volunteered.) -wayne From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:09:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24239 for ; Thu, 26 Aug 2004 14:09: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 i7QHow1I021147; Thu, 26 Aug 2004 10:50: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 i7QHownd021146; Thu, 26 Aug 2004 10:50:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHouSX021136 for ; Thu, 26 Aug 2004 10:50:57 -0700 (PDT) (envelope-from admin@asarian-host.net) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:43:47 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 17:55:22 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 17:57:47 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 17:56:43 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFh5Wr003271; Thu, 26 Aug 2004 08:43: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 i7QFh5L9003270; Thu, 26 Aug 2004 08:43:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFh2ai003252 for ; Thu, 26 Aug 2004 08:43:03 -0700 (PDT) (envelope-from admin@asarian-host.net) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:23:44 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:12:10 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:14:17 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:13:12 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE04sF072211; Thu, 26 Aug 2004 07:00: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 i7QE040J072210; Thu, 26 Aug 2004 07:00:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE02O5072197 for ; Thu, 26 Aug 2004 07:00:03 -0700 (PDT) (envelope-from SRS0=wCa/I6YQ=LQ=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7QE02ed006269 for ; Thu, 26 Aug 2004 16:00:02 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408261400.I7QE01HM006259@asarian-host.net> Date: Thu, 26 Aug 2004 14:00:02 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY - reference implementation X-Trace: N2RfEMcdLVr7Cuy0wdV9tKXqn75J9ce+TM1l3h5/LhApEDyL+aGLXBZuTdm7Y0n2syWdUKl8uGPwOOii7xehxw== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <412CE5F4.5010006@redhat.com> <20040826111249.GA5702@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03D9_01C48B85.BCA6DD60" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQS3s4jFqW1BleBN9AQGRKAf+IdV6kNH0lBhRxk40nVzo8frILtC+Yl+J ESOLq2H8+8No782tarKslhz1DbJ8xRYDik7iDKCTfOKfsF7loojrCylA4UugW0fH bFQP/fMl2URZ56tFd4BFqn1qg3RZ3sMyPU+mjFBw83bTNPq2JPjCgXawJ3RV6L1Z 0oNikcBzcvBaurIfvnyCXu7LRgNPVYRK0RhbowZBEhtFLImUhxA0e8mrNbQhiS7L yMDAipL3BhRj0ckn5QtSMteNUMVt7uhyJfx3KFisYInT5epumzz+huaTh8QAWtYT P7g4IBtLQ/xyWe8xLdSbZifObakjfA5rlfcNgvtomKUyQSKy2sFxGA== =GHZA List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 14:13:12.0345 (UTC) FILETIME=[D2467090:01C48B76] List-Archive: List-Unsubscribe: List-ID: 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_03D9_01C48B85.BCA6DD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > Basically, Sender-ID is "get the PRA", then "get the PRD", send "apply > SPF to the PRD". > > The last step is complicated but there are many free software SPF > implementations. > > The first step is very simple, I attached my own implementation. Bug > reports are welcome to show me where I've misread -pra. Just for the heck of it, here is my Perl implementation of PRA. :) - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx ------=_NextPart_000_03D9_01C48B85.BCA6DD60 Content-Type: application/octet-stream; name="pra.pl" Content-Disposition: attachment; filename="pra.pl" Content-Transfer-Encoding: quoted-printable #!/usr/local/bin/perl -w=0A= #=0A= # AIM: Implements the PRA (Purported Responsible Address) algorithm=0A= # described in Internet-Draft draft-ietf-marid-par-00.txt.=0A= #=0A= # USE: ./pra.pl =0A= #=0A= # Requires: Perl.=0A= # mailTools-1.64=0A= #=0A= # LICENCE: trivial work, not patentable, not licenceable.=0A= #=0A= # WARNING: Microsoft claims a patent on the PRA algorithm.=0A= # The author did not requested a licence.=0A= #=0A= # AURHOR: Mark Kramer =0A= =0A= use Mail::Address;=0A= use strict;=0A= =0A= my $header_file =3D $ARGV[0] or die "Usage: $0 ";=0A= my $header;=0A= =0A= if (open (HEADERS, $header_file)) {=0A= $header .=3D $_ while ();=0A= close (HEADERS);=0A= } else {=0A= die "Cannot open $header_file!\n";=0A= }=0A= =0A= # Stream-line continuation lines:=0A= =0A= $header =3D~ s/\n\s+/\t/mg;=0A= =0A= # Remove (key, value) pairs from header where 'value' does not exist:=0A= =0A= $header =3D~ s/^[^:]*:\s*\n//mg;=0A= =0A= # Process the split-up-per-line $header in reverse order,=0A= # so that the last key set for $headers(key} is actually=0A= # the first (non-empty!) occurance thereof!=0A= =0A= my %headers =3D map { split (/: */, $_, 2) } reverse split (/\n/, lc = ($header));=0A= my $pra =3D $headers{'resent-sender'} || $headers{'resent-from'} || = $headers{'sender'} || $headers{'from'} || undef;=0A= =0A= # The next foreach loop looks a bit weird; but=0A= # Mail::Address -> parse expects an array, not a=0A= # scalar context.=0A= =0A= if ($pra) {=0A= foreach (Mail::Address -> parse ($pra)) {=0A= print "PRA: " . $_ -> address . "\n";=0A= last;=0A= }=0A= }=0A= =0A= exit 0; ------=_NextPart_000_03D9_01C48B85.BCA6DD60-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:09: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 OAA24272 for ; Thu, 26 Aug 2004 14:09: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 i7QHmfAY020963; Thu, 26 Aug 2004 10:48:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QHmfcj020962; Thu, 26 Aug 2004 10:48:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHmeJE020935 for ; Thu, 26 Aug 2004 10:48:40 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:43:51 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:22:41 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:53:44 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:56:10 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:49:37 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEWeFr082090; Thu, 26 Aug 2004 07:32: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 i7QEWeiZ082089; Thu, 26 Aug 2004 07:32:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEWdi0082077 for ; Thu, 26 Aug 2004 07:32:39 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-103-225.area3.spcsdns.net ([68.245.145.169]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0LIs-0000sy-O1; Thu, 26 Aug 2004 10:32:40 -0400 Message-ID: <412DF478.7030502@solidmatrix.com> Date: Thu, 26 Aug 2004 10:32:24 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Margaret Olson CC: IETF MARID WG Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ References: <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> In-Reply-To: <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 14:49:37.0928 (UTC) FILETIME=[E8FBF080:01C48B7B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Margaret Olson wrote: > On Aug 26, 2004, at 8:26 AM, wayne wrote: >> In >> > > "Hallam-Baker, Phillip" writes: >> >>>> If not, wouldn't this mean that users of qmail that want to support >>>> SenderID (which we hope will be all of them) need to get a license >>>> from Microsoft? >>> >>> Or an alternative MTA :-) >> >> Is your goal in supporting the SenderID license to get people to use >> "an alternative MTA", say the one that Harry and Jim work on? > > Wayne and others. > I largely agree with Phill, but let me try to present the issue a > slightly different way. I use several MTA implementations, both > commercial and open source. I've concluded that the current license > will allow me to continue to have a good selection of open source and > commercial choices with Sender ID implementations. Open source is open > source - Sender ID is sufficiently valuable that I'm convinced that > viable Sender ID variants will emerge, even if they are not distributed > in quite the same way that the code is today. Both Eric Allman and > Phill have discussed ways to approach this problem. I am speaking as > someone who intends to implement receive side Sender ID as soon as > possible. > The problem is not limited to open source or commercial. The main issue at hand is whether this specific license would be detrimental to deployment at large of this standard (in my personal opinion, the main place where this issue will come to play out is not the main open source and commercial email applications, but rather within ISPs and small companies that want to implement this in-house). The question we should be asking is whether this specific license will be detrimental to deployment of Sender-ID at large. While you argue that alternatives will emerge, others including potential implementors have made points as to why this license may scare away potential implementors. The problem is that we really don't know until the standard is approved which makes it kind of a catch-22. . > I have also had the impression that some folks on the list are > expecting Microsoft to give them what amounts to legal advice. A lawyer > representing me, being paid by me, can't give you legal advice about > how to deal with me - there is a conflict of interest. So where > Microsoft does provide clarifications or suggestions it will be > caveated it left and right with "consult your own lawyer" just to make > sure you are not confused about whose interests are being represented. > This is how the legal system works; it's not some sort of Microsoft > conspiracy to make everyone waste money on legal advice. > > In the spirit of frugality, I applaud Wayne's contacting of Eben > Moglen. It's always a good idea to avoid paying a lawyer (or anyone > else, for that matter) to come up to speed on a particular subject. > In the context of the original question that is posted - how will this affect deployment, the lawyer issue is rather important. If a signficant number of potential implementors will not want to implement Sender-ID because they are unsure about what they are signing and cannot afford a lawyer, it will be detrimental to the overall success of the standard. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:09: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 OAA24274 for ; Thu, 26 Aug 2004 14:09: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 i7QHkZVx020769; Thu, 26 Aug 2004 10:46:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QHkZG1020768; Thu, 26 Aug 2004 10:46:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHkXP8020751 for ; Thu, 26 Aug 2004 10:46:34 -0700 (PDT) (envelope-from william@elan.net) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:43:53 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 18:13:57 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 18:16:22 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 18:15:22 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFwJGf007115; Thu, 26 Aug 2004 08: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 i7QFwJCT007114; Thu, 26 Aug 2004 08:58:19 -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 i7QFwITA007103 for ; Thu, 26 Aug 2004 08:58:19 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7QG6YM0022174 for ; Thu, 26 Aug 2004 09:06:34 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7QG6YfR022171 for ; Thu, 26 Aug 2004 09:06:34 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 Aug 2004 09:06:34 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: MAIL LOOP AND DUPLICATION OF POSTS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 16:15:22.0575 (UTC) FILETIME=[E36EC5F0:01C48B87] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ATTENTION MAIL ADMINISTRATOR OF THIS LIST. We have a mail loop as somebody is relaying messages already posted to the list back to the list resulting duplicate (and possibly soon triplicate) messages. I'm posting here headers of the post which I received in duplicate, I believe the duplication is being caused by somebody at gfi.com. Please investigate immediatly and if necessary temporarily suspend the subscriber involved. ---------- Forwarded message ---------- Return-Path: Received: from above.proper.com (above.proper.com [208.184.76.39]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7QFuErW021783 for ; Thu, 26 Aug 2004 08:56:14 -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 i7QFVlkv099964; Thu, 26 Aug 2004 08:31: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 i7QFVlTS099962; Thu, 26 Aug 2004 08:31:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFVgDu099902 for ; Thu, 26 Aug 2004 08:31:44 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:23:56 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:12:58 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:15:23 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:14:10 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDsiig070407; Thu, 26 Aug 2004 06:54: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 i7QDsioK070406; Thu, 26 Aug 2004 06:54:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDshkZ070396 for ; Thu, 26 Aug 2004 06:54:43 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-103-225.area3.spcsdns.net ([68.245.145.169]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0Ki9-00073P-Gt for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 09:54:42 -0400 Message-ID: <412DEB94.1030607@solidmatrix.com> Date: Thu, 26 Aug 2004 09:54:28 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: acceptable licenses (Was: Can there be an early decision on the SenderID license?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com X-Source: X-Source-Args: X-Source-Dir: List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 14:14:10.0719 (UTC) FILETIME=[F5119AF0:01C48B76] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sokol.elan.net X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:11:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24394 for ; Thu, 26 Aug 2004 14:11:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHpthx021207; Thu, 26 Aug 2004 10:51: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 i7QHptOP021206; Thu, 26 Aug 2004 10:51:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHprLr021185 for ; Thu, 26 Aug 2004 10:51:54 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:43:45 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 18:02:01 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 18:04:26 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 18:03:08 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFo65A004934; Thu, 26 Aug 2004 08:50: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 i7QFo60H004933; Thu, 26 Aug 2004 08:50:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFo4V6004902 for ; Thu, 26 Aug 2004 08:50:05 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:22:55 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 15:57:41 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 15:59:12 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 15:57:00 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDgJqk066523; Thu, 26 Aug 2004 06:42:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QDgJsd066522; Thu, 26 Aug 2004 06:42:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDgINB066513 for ; Thu, 26 Aug 2004 06:42:18 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7QDeVqv003335; Thu, 26 Aug 2004 06:40:31 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 06:40:31 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jim Fenton'" , Rand Wacker , ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve) Date: Thu, 26 Aug 2004 06:40:31 -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: 26 Aug 2004 13:57:01.0018 (UTC) FILETIME=[8F51B3A0:01C48B74] List-Archive: List-Unsubscribe: List-ID: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >The solution I would suggest is to put spfv2/pra records in > a sub-domain > >such as _marid.company.com. While it would be nice to recommend that > >people begin allowing TCP DNS queries, it is unlikely that > the highest > >volume sites would ever want to implement such. > > I think it was brought up earlier that using a prefix like > _marid would break the use of wildcards (can't do > _marid.*.example.com). But it wasn't clear (to me, at least) > whether wildcards would work in this application, even > without the prefix. Wildcard support would be very nice to > have, to provide symmetry with wildcard MX records for > incoming mail. Can anyone clear up whether adding the prefix > breaks wildcards, or were they already broken? The situation with the prefix is as follows: 1) Standard (i.e. AXFR communicatable wildcards) do not work for ANY Sender-ID use case. A wildcard only produces a match if there is no data whatsoever in a node. This means that this type of wildcard cannot be used to make any assertions about machines that have a domain name entry. 2) Synthetic wildcards work fine, but are not supported in the AXFR interchange format. 3) Prefixing does not prevent the use of wildcards, but if a wildcard is used the advantage of using a prefix is lost. I.E. *.example.com will match _spf1.example.com and _spf2.example.com 4) Some tools do not support prefix use - this is not a major concern since I would expect sender-id to be promoted mainly through purpose driven tools not through grovelling TXT entries. My opinion is that we should move to a prefix if we introduce a new version identifier. Otherwise we should not. There is a value to using a prefix but it is not by itself sufficient to make a change worthwhile. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:11: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 OAA24414 for ; Thu, 26 Aug 2004 14:11: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 i7QHpu4K021215; Thu, 26 Aug 2004 10:51: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 i7QHpuCX021214; Thu, 26 Aug 2004 10:51:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHprLt021185 for ; Thu, 26 Aug 2004 10:51:55 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:43:45 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 18:02:41 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 18:05:06 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 18:03:24 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFmuOc004615; Thu, 26 Aug 2004 08:48:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFmui2004614; Thu, 26 Aug 2004 08:48:56 -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 i7QFmtJp004607 for ; Thu, 26 Aug 2004 08:48:55 -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 i7QFmve8030467 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Aug 2004 08:48:58 -0700 Date: Thu, 26 Aug 2004 08:48:57 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: John Glube cc: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> Message-ID: References: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 16:03:25.0114 (UTC) FILETIME=[37CAE9A0:01C48B86] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, thanks for the reply. One thing I want to start by saying (and then I'm going to leave the discussion for after last call), its becoming clear that the most fundamental disagreement on this list has to do with the approach of doing *channel* authentication versus *message* authentication. I say this because you tend to hold SPF Classic and Sender ID as equivalent in your response, which I do not. > From your discussions with managers of large email > infrastructures, who are seeing a problem with packet size; > along with the big ISPs who are not interested in using TCP > to receive email because of cost, does it make more sense > not to change the version string? No. Both I and the people looking to implement these records feel quite strongly that using the same record for both is very dangerous. In fact, these largest sites are the ones who are *most* likely to have different records (bit of a Catch 22 there). > It was felt folks who implemented SPF were early adopters. > By changing the version string, this would freeze SPF and > folks would move ahead with Sender-ID. > > What you are telling us is the direct opposite. The truth is that there are some very large sites which have already begun asking senders to publish SPF records. There are other large sites that will be asking senders to publish Sender ID records. (I can think of a third large site that will ask for DomainKeys later ;) The goal of all of these senders is to get their mail through, they don't care so much how they have to do that. > Some of the Big ISPs are using SPF to detect email forgery > at the pre data stage, while telling folks, do you want > less content filtering? Publish an SPF record. ^email forgery^channel forgery. Also for most receivers I've talked to, "pre data" doesn't matter since for the worst spam the packets are already wedged in to their TCP receive buffers. > (Of course this achieves the desired objective of sender > authentication, thwarting spoofing and other steps taken to > hide identity, by getting everyone out in the open.) No offense John, but this is a sub-concious troll to bring the debate back to SPF Classic vs Sender ID. ;) > With the premise of enhanced email delivery, along with > protecting against domain spoofing, SPF is gaining > implementation momentum among domain owners. Enhanced email delivery, yes, but no-one I've talked to is under the delusion that SPF Classic protects against domain spoofing in the "what the user sees" context > This leads one to the conclusion the solution is instead of > creating a sub domain for Sender-ID records, rather it is > not to change the version string. Incorrect conclusion. > P.S. Another question. Since the Big ISPs do not want to > use TCP to check authentication for email delivery, does > this mean from a practical perspective, the Big ISPs would > prefer to create a mirror data base of authentication > records within their own networks and when a domain owner > makes a change, the domain owner's DNS server could > propagate the change through out the mirrored sites? This is functionality already inherent in DNS, which is one of the things that makes it appealing for a task like this. Cheers - Rand From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:14: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 OAA24701 for ; Thu, 26 Aug 2004 14:14: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 i7QHtALP021447; Thu, 26 Aug 2004 10:55: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 i7QHtAdh021446; Thu, 26 Aug 2004 10:55:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHt9Vl021439 for ; Thu, 26 Aug 2004 10:55:09 -0700 (PDT) (envelope-from SRS0=wCa/I6YQ=LQ=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7QHtCLl013786 for ; Thu, 26 Aug 2004 19:55:12 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408261755.I7QHTBR4013775@asarian-host.net> Date: Thu, 26 Aug 2004 17:55:12 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY - reference implementation X-Trace: jF6DFEpP/dcF6Toh6BPticdUi4tDsjIJYlZAl2KTG0+dnxOQtN3yA+r7bU+KAUIMHxFdP/RbtT59vaSmNBCqYg== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <412CE5F4.5010006@redhat.com> <20040826111249.GA5702@nic.fr> <200408261400.I7QE01HM006259@asarian-host.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_056D_01C48BA6.94AA5780" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQS4kADFqW1BleBN9AQGdrQf/Y5PWSFbgPBJGWtP+Ocg6k/ApHCALIzdc Swbch+glRO0swLcIQML32SR6Zfp2HAg02zCvvr0oqtrpXL6nWl6RDsYPDMJgJiLH AqR5HmyoyyHqDrJJbt1pIgZck970yLBUcN6SszBHYsRQp2WN2KYJQZUZL6uroAxV T7yg50jIZ0u5tUIy1qRt9uI1T/2dIYvk+cLlIkvKj7hDzds/w2N99deDr2x5T80t W8aDvktaDYs2FwCk415TT4X959louPfbxl5l1xX622WPqWUDklspBbAq1wWcVuij bSPv8VBMizp+hJs4YwOHkDS3+3fi9OOFhbEnzLqydiiLqsndC0ZREg== =H4XG 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_056D_01C48BA6.94AA5780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mark wrote: >> The first step is very simple, I attached my own implementation. Bug >> reports are welcome to show me where I've misread -pra. > > Just for the heck of it, here is my Perl implementation of PRA. :) Actually, I made quite a few boo-boo's in that quicky jumbled together piece of Perl. My apologies for that. This is how I should have done it. As far as I can tell, it now follows the letter of draft-ietf-marid-pra-00.txt. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx ------=_NextPart_000_056D_01C48BA6.94AA5780 Content-Type: application/octet-stream; name="pra1.pl" Content-Disposition: attachment; filename="pra1.pl" Content-Transfer-Encoding: quoted-printable #!/usr/local/bin/perl -w=0A= #=0A= # AIM: Implements the PRA (Purported Responsible Address) algorithm=0A= # described in Internet-Draft draft-ietf-marid-par-00.txt.=0A= #=0A= # USE: ./pra.pl =0A= #=0A= # Requires: Perl.=0A= # mailTools-1.64=0A= #=0A= # LICENCE: trivial work, not patentable, not licenceable.=0A= #=0A= # WARNING: Microsoft claims a patent on the PRA algorithm.=0A= # The author did not requested a licence.=0A= #=0A= # AURHOR: Mark Kramer =0A= =0A= use Mail::Address;=0A= use strict;=0A= =0A= my $pra;=0A= my $header;=0A= =0A= sub process_header {=0A= =0A= # Stream-line continuation lines:=0A= =0A= (my $header =3D (shift)) =3D~ s/\n\s+/\t/mg;=0A= =0A= # Remove (key, value) pairs from header where 'value' does not exist:=0A= =0A= $header =3D~ s/^[^:]*:\s*\n//mg;=0A= =0A= my $pra;=0A= if ($header =3D~ /^Resent-Sender: *(.+)/mi) {=0A= $pra =3D $1;=0A= return ($pra) if ($` !~ /^Resent-From: = *(.+)(.|\n)*?^(Received|Return-Path):/mi);=0A= }=0A= return ($1) if ($header =3D~ /^Resent-From: *(.+)/mi);=0A= if ($header =3D~ /^Sender: *(.+)/mi) {=0A= $pra =3D $1;=0A= if (($header =3D~ s/^Sender: *(.+)//mgi) > 1) {=0A= return undef;=0A= } else {=0A= return ($pra);=0A= }=0A= } elsif ($header !~ /^From: *(.+)/mi) {=0A= return undef;=0A= } else {=0A= return ($1);=0A= }=0A= }=0A= =0A= my $header_file =3D $ARGV[0] or die "Usage: $0 ";=0A= =0A= if (open (HEADERS, $header_file)) {=0A= $header .=3D $_ while ();=0A= close (HEADERS);=0A= } else {=0A= die "Cannot open $header_file!\n";=0A= }=0A= =0A= if ($pra =3D process_header ($header)) {=0A= =0A= # Getting is here is equivalent to step 5; not getting here to step 6=0A= =0A= my @candidates =3D Mail::Address -> parse ($pra);=0A= =0A= # Multiple mailboxes is equivalent to step 6=0A= =0A= if (@candidates =3D=3D 1) {=0A= print "PRA: " . pop (@candidates) -> address . "\n";=0A= }=0A= }=0A= =0A= exit 0; ------=_NextPart_000_056D_01C48BA6.94AA5780-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:19:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25078 for ; Thu, 26 Aug 2004 14: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 i7QI1xma021958; Thu, 26 Aug 2004 11:01:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QI1xm5021957; Thu, 26 Aug 2004 11:01:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI1v98021949 for ; Thu, 26 Aug 2004 11:01:58 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:40:53 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 18:32:32 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 18:34:56 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 18:33:32 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGHoSk011066; Thu, 26 Aug 2004 09:17: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 i7QGHo0t011065; Thu, 26 Aug 2004 09:17:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGHnrI011057 for ; Thu, 26 Aug 2004 09:17:49 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7QGHq3Z004716 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 26 Aug 2004 09:17:52 -0700 Date: Thu, 26 Aug 2004 09:17:52 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: IETF MARID WG Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ In-Reply-To: <3hnLJt+qzxTulVQGEybPVw.md5@prosecco.oryx.com> Message-ID: References: <3hnLJt+qzxTulVQGEybPVw.md5@prosecco.oryx.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 16:33:32.0713 (UTC) FILETIME=[6D34A190:01C48B8A] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hmm, IANAL, and believe it or not this has nothing to do with who I work with/for, but from what I've learend about Open Source licensing in the past few weeks it would seem to me that the qmail license itself is incompatible with the definition of open source (specifically that it prohibits re-distribution and sub-licensability). djb's choice of licensing terms is djb's choice, and this group probably shouldn't get too hung up on the requirements of a software package that prohibits *any* modifications to its base code. -Rand On Thu, 26 Aug 2004, Arnt Gulbrandsen wrote: > But isn't that all beside the point? Surely exactly the same > IP/licensing problems would still apply if djb were to release a new > version tomorrow. > > Arnt > > From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14: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 OAA25117 for ; Thu, 26 Aug 2004 14:19:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI1cH7021939; Thu, 26 Aug 2004 11:01: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 i7QI1clX021938; Thu, 26 Aug 2004 11:01:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI1YqO021929 for ; Thu, 26 Aug 2004 11:01:35 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:40:53 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 18:59:36 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 19:02:01 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 19:00:53 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGmF5p015433; Thu, 26 Aug 2004 09:48: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 i7QGmFoa015430; Thu, 26 Aug 2004 09:48:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGm9ks015420 for ; Thu, 26 Aug 2004 09:48:15 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7QGm8sQ017517; Thu, 26 Aug 2004 09:48:09 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 09:47:49 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Arnt Gulbrandsen'" , IETF MARID WG Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 09:47:46 -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: 26 Aug 2004 17:00:53.0653 (UTC) FILETIME=[3F483450:01C48B8E] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Granted, qmail isn't maintained. (And if you want to comment > negatively > on its quality, I shall offer not one word of disagreement.) > > But isn't that all beside the point? Surely exactly the same > IP/licensing problems would still apply if djb were to release a new > version tomorrow. If QMail was actively maintained the license issues would be exactly the same as for any other mailer. The problems come from the fact that the mailer is abandonware and the license prohibits any other party taking it on. I would not waste my time maintaining QMail, I would replace it wholesale or use one of the many other fine mail systems out there. Phill From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14: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 OAA25154 for ; Thu, 26 Aug 2004 14:19: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 i7QHxgce021788; Thu, 26 Aug 2004 10:59: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 i7QHxgJ3021787; Thu, 26 Aug 2004 10:59:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHxeOw021778 for ; Thu, 26 Aug 2004 10:59:41 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:40:57 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 18:19:15 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 18:21:40 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 18:19:24 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFuL1V006693; Thu, 26 Aug 2004 08:56: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 i7QFuLu1006692; Thu, 26 Aug 2004 08:56:21 -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 i7QFuL9d006684 for ; Thu, 26 Aug 2004 08:56:21 -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 i7QFuNeT031945 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 26 Aug 2004 08:56:24 -0700 Date: Thu, 26 Aug 2004 08:56:23 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 16:19:24.0834 (UTC) FILETIME=[73D49020:01C48B88] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Phillip brings up a very good point here because if the desire for wildcards is to make it easy for sites to indicate where mail *does not* come from for hosts under their domain, then this application is pretty moot because every sane MTA on the planet /already/ rejects mail for this there is no resolvable FQDN (why bother accepting a message if you know up front you couldn't ever reply to it). -Rand On Thu, 26 Aug 2004, Hallam-Baker, Phillip wrote: > While David is right, there is also the corollary that *.example.com > will only match nodes that do not exist at all. So there are two issues, > do wildcards work as expected, is the wildcard useful at all. The matching > behavior means that the wildcard is not useful for the use cases given. > > i.e. if we have > > a.example.com > > *.example.com. IN TXT "v=spf1 ..." > > Will match _marid.b.example.com, b.example.com but not a.example.com > regardless of whether a has TXT records or not. > > So you can't use a wildcard to give a default SPF record for DNS > names of hosts that exist. Only the hosts that don't exist will match. > > > I don't know what happens for _marid.a.example.com, I think it should > not match but one of the DNS people can say for sure. > > > IF _marid.a.example.com did match the wildcard then it would be a way > to make the wildcards useful. > > > From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:21:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25305 for ; Thu, 26 Aug 2004 14:21: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 i7QI2x02022066; Thu, 26 Aug 2004 11:02: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 i7QI2xDO022065; Thu, 26 Aug 2004 11:02:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI2xa0022053 for ; Thu, 26 Aug 2004 11:02:59 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 11:03:02 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 11:03:06 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 11:03:02 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 11:02:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: DNS Record Types Date: Thu, 26 Aug 2004 11:03:00 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAC2F@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: DNS Record Types Thread-Index: AcSKPSfqawj3rZy3TgG+27QBulK+BABWK1pw From: "Jim Lyon" To: "Margaret Olson" , "Mark Lentczner" Cc: "IETF MARID WG" X-OriginalArrivalTime: 26 Aug 2004 18:02:59.0190 (UTC) FILETIME=[EBE00960:01C48B96] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QI2xa0022055 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On August 24, 2004, at 5:48 PM, Margaret Olson wrote (replying to my request): > 1. Publishers MUST publish using the new SPF2 record type. > Change this to SHOULD > 2. Publishers MAY also publish using TXT records. > Leave as is > 3. Consumers MUST do lookups using the new SPF2 record type. > Change this to SHOULD > 4. Consumers MAY also do lookups using TXT records. > Leave as is > 5. Consumers MAY do both lookups (3 and 4) in parallel. > Leave as is > 6. If consumers receive records from both lookups, they SHOULD use > the SPF2 record and ignore the TXT record. > Change this to MUST, since we want the world to move to the SPF2 record I'm OK with 1, 3, 5 and 6. However, 2 and 4 need to at least be SHOULD (they need to be as strong as the wording on 1 and 3). My reasoning is as follows: You publish records primarily for the benefit of others. (I know there's a secondary benefit to you, but that's not the point here.) In order for those consumers who can't see your SPF2 record to benefit, you'll need to publish a TXT record. Similarly, if you're a consumer, in order to get the benefit from a publisher who can't publish an SPF2 record, you'll need to query for the TXT record. In spec language, the word MAY means truly optional. But we don't want truly optional here, we want people to understand that they should publish and query for the TXT records in order to get this stuff off the ground. -- Jim Lyon -- Jim Lyon mailto:JimLyon@Microsoft.Com tel:+1-425-706-0867 Internet commerce will never really take off until you can buy something online without getting spammed by the vendor. -----Original Message----- Here are my suggested changes, working from Jim Lyon's simplification. The goal is to both moving the world to the new resource record and to allow everyone to be compliant in the very short term. I dislike the idea of having a spec with which most people in fact won't be able to comply. Coupled with the significant forgery/spam reduction incentive of implementing Sender ID the current wording ultimately works against the goals of the DNS folks by making a spec violation "standard practice". 1. Publishers MUST publish using the new SPF2 record type. Change this to SHOULD 2. Publishers MAY also publish using TXT records. Leave as is 3. Consumers MUST do lookups using the new SPF2 record type. Change this to SHOULD 4. Consumers MAY also do lookups using TXT records. Leave as is 5. Consumers MAY do both lookups (3 and 4) in parallel. Leave as is 6. If consumers receive records from both lookups, they SHOULD use the SPF2 record and ignore the TXT record. Change this to MUST, since we want the world to move to the SPF2 record Margaret. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:21:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25323 for ; Thu, 26 Aug 2004 14:21:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI20Sv021967; Thu, 26 Aug 2004 11:02: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 i7QI20LH021966; Thu, 26 Aug 2004 11:02:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI1v9A021949 for ; Thu, 26 Aug 2004 11:01:59 -0700 (PDT) (envelope-from cdhutzler@aol.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:40:53 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 17:21:53 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 17:08:53 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 17:07:16 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEkNuV085498; Thu, 26 Aug 2004 07:46: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 i7QEkNBr085497; Thu, 26 Aug 2004 07:46:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-d20.mx.aol.com (imo-d20.mx.aol.com [205.188.139.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEkMRq085467 for ; Thu, 26 Aug 2004 07:46:23 -0700 (PDT) (envelope-from cdhutzler@aol.com) Received: from cdhutzler@aol.com by imo-d20.mx.aol.com (mail_out_v37_r3.4.) id 7.66.44d5ad2d (15887) for ; Thu, 26 Aug 2004 10:46:10 -0400 (EDT) Received: from [10.0.24.213] ([10.0.24.213]) by air-id08.mx.aol.com (v101.19) with ESMTP id MAILINID82-3e0f412df7b1267; Thu, 26 Aug 2004 10:46:10 -0400 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 26 Aug 2004 10:46:08 -0400 Subject: AOL's stance on SenderID and IPR issues From: Carl Hutzler To: IETF-MXCOMP Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AOL-IP: 10.0.24.213 X-Mailer: Unknown (No Version) List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 15:07:16.0870 (UTC) FILETIME=[6029AA60:01C48B7E] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Someone on the list asked me to post AOL's thoughts on the IPR/SenderID thread... Our internal patent lawyer has reviewed the license agreement and said that he found no IP issues and we are free to pursue a license to use it in our infrastructure. The only issues I have seen on the lists likely do not apply to AOL: A) Sendmail redistrubutes/sells software - AOL does not sell MTAs other than perhaps netscape iplanet. But I am not closely related to that team. B) Some have complained about the nuisance of applying for a license for every "small organization" and potential costs of that. Folks really want a GPL. While I understand this, AOL is not in this category and likely would not see licensing this technology as an undue burden. That's the scoop from AOL land :-) -Carl -- Carl Hutzler Director, AntiSpam Operations America Online Mail Operations cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:24:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25445 for ; Thu, 26 Aug 2004 14:24: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 i7QHx8HE021742; Thu, 26 Aug 2004 10:59: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 i7QHx8T1021741; Thu, 26 Aug 2004 10:59:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHx7qI021734 for ; Thu, 26 Aug 2004 10:59:07 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7QHx83q026061; Thu, 26 Aug 2004 10:59:09 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 10:59:08 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ryan Ordway'" , "Hallam-Baker, Phillip" Cc: "'IETF MARID WG'" Subject: RE: Can there be an early decision on the SenderID license? Date: Thu, 26 Aug 2004 10:59:08 -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: > It will not take a valid legal argument to derail > the widespread deployment of any standard that comes from > this working group. All that is needed is the, perhaps > unfounded, fear that implementing SenderID or any other > standard with nebulous IPR issues is going to bite the user > in a tender area. An unfounded claim can certainly block progress. But an unsubstantiated claim cannot. It is not sufficient to say 'we don't like it' From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:24:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25463 for ; Thu, 26 Aug 2004 14:24: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 i7QI5LTs022655; Thu, 26 Aug 2004 11: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 i7QI5Lob022654; Thu, 26 Aug 2004 11:05:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI5LIp022648 for ; Thu, 26 Aug 2004 11:05:21 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7QI5OfC012103 for ; Thu, 26 Aug 2004 11:05:24 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 11:05:24 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 11:05:24 -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 is incorrect. Qmail *is* being maintained, just not by DJB. And DJB refuses to allow Qmail to be updated. Therefore I stick by my original claim. > > Making a call out to a sharred library is no different in principle > > than making a call out to an object library. > > I think you should look at the qmail source again. It makes a several > fork/exec's on each SMTP transaction. Despite the fork/execs, qmail > is still very fast because it doesn't do any expensive operations such > as your suggested dlopen. Do the dlopen in the initialization loop and pass it to the child process along with the socket. If the O/S supports transfer of sockets then this is almost certain to work. Calling a handle returned by a dynamic link library is not going to be any slower than a normal handle call. This can be made to work if anyone cares to want to make it work. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:24: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 OAA25481 for ; Thu, 26 Aug 2004 14:24: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 i7QI6dTn022796; Thu, 26 Aug 2004 11:06:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QI6dOA022795; Thu, 26 Aug 2004 11:06:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI6buB022778 for ; Thu, 26 Aug 2004 11:06:38 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:40:50 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:22:48 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 15:56:10 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 15:57:32 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 15:54:16 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDe9tV065968; Thu, 26 Aug 2004 06:40:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QDe9Sb065967; Thu, 26 Aug 2004 06:40:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from icicle.pobox.com (icicle.pobox.com [207.8.226.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QDe8J6065957 for ; Thu, 26 Aug 2004 06:40:08 -0700 (PDT) (envelope-from SRS0=fzKj=LQ=dumbo.pobox.com=mengwong@bounce2.pobox.com) Received: from emerald.pobox.com (emerald.pobox.com [207.8.226.12]) by icicle.pobox.com (Postfix) with ESMTP id 42E5B11A638; Thu, 26 Aug 2004 09:40:11 -0400 (EDT) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id EF6F0132D1A; Thu, 26 Aug 2004 09:39:37 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 93BAB87C; Thu, 26 Aug 2004 09:40:09 -0400 (EDT) Date: Thu, 26 Aug 2004 09:40:09 -0400 From: Meng Weng Wong To: Rand Wacker Cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Message-ID: <20040826134009.GA3684@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 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 13:54:16.0742 (UTC) FILETIME=[2D672C60:01C48B74] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 25, 2004 at 08:44:16PM -0700, Rand Wacker wrote: | | This is a concern that has been voiced to me by several major sites that | are exactly the same set of sites we use as examples for where we need to | stop phishing from. They are most likely going to publish *both* spfv1 | and spfv2/pra records, and their initial investigation of their email | architectures has indicated that those records are going to be pushing | this real-world 240-byte limit (a 480 byte effective UDP packet split in | two) | The divergence between v=spf1 and spf2.0/pra records was motivated by the desire to accommodate those domains whose sets of permitted IPs differed according to context. Example.com might wish to permit one set of MTAs to use its name in mail-from, and another set of MTAs to use its domain in the PRA. My initial response to this requirement was to say, "example.com should just take the union of both those sets and publish that." I believe that some people have spoken up and said that a union solution was unappealing. As things stand, the current draft means most people would do: example.com TXT "v=spf1 blah blah blah" example.com TXT "spf2.0/pra blah blah blah" I believe that the vast majority of all domains will have exactly the same "blah blah blah". Rand's objection appears to share this belief. Therefore, I suggest that we introduce the %{e} scope macro to accommodate the very small fraction of domains who need to distinguish the scopes, and allow everyone else to leave things alone. At the Microsoft event earlier this month, we spent some time discussing this issue. The audience represented the ESP community, who I believe are the folks who would most want to assert the distinction between scopes. The audience felt that changing the prefix would be fine, but doing a scope macro would also be fine. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:26: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 OAA25584 for ; Thu, 26 Aug 2004 14:26: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 i7QI7odS022906; Thu, 26 Aug 2004 11:07: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 i7QI7oXZ022905; Thu, 26 Aug 2004 11:07:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI7mG6022891 for ; Thu, 26 Aug 2004 11:07:49 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:40:50 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 17:22:01 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 17:13:01 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 17:10:43 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEnfvM086344; Thu, 26 Aug 2004 07:49: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 i7QEnf1h086343; Thu, 26 Aug 2004 07:49:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEnerR086334 for ; Thu, 26 Aug 2004 07:49:40 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7QEnhu5002864 for ; Thu, 26 Aug 2004 07:49:43 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Aug 2004 07:49:43 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 07:49:42 -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: 26 Aug 2004 15:10:43.0598 (UTC) FILETIME=[DB61DAE0:01C48B7E] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Or an alternative MTA :-) > > I'm not sure that is really a joking matter. We aren't supposed to > talk about "hidden agendas", but since you raised the issue, I'll ask > directly: > > Is your goal in supporting the SenderID license to get people to use > "an alternative MTA", say the one that Harry and Jim work on? QMail is not being maintained. The license terms make it impossible for it to be maintained. There are better mailers out there with true open source licenses. These do not create issues in the standards development area. I would advise anyone using QMail to move to a supported product. Whether that support is commercial or voluntary does not matter to me, I don't sell mail servers. I don't think that a standards group should be constrained by the license terms of an unsupported product that has not been maintained for years and is unlikely to be maintained in the future. > > If I had to patch Qmail the way I would do it is as follows: > > > > [ideas snipped] > > Your scheme does not match the design of qmail. What you are > suggesting is a major rewrite of the qmail MTA. Actually not, it is many years since I looked at QMail, but this is the type of modification I used to do in a day or so. Making a call out to a sharred library is no different in principle than making a call out to an object library. Take a look at the following: http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-libraries.ht ml#shared_dlsym #include /* defines dlopen(), etc. */ void* lib_handle; /* handle of the opened library */ lib_handle = dlopen("/full/path/to/library", RTLD_LAZY); if (!lib_handle) { fprintf(stderr, "Error during dlopen(): %s\n", dlerror()); exit(1); } /* first define a function pointer variable to hold the function's address */ struct local_file* (*readfile)(const char* file_path); /* then define a pointer to a possible error string */ const char* error_msg; /* finally, define a pointer to the returned file */ struct local_file* a_file; /* now locate the 'readfile' function in the library */ readfile = dlsym(lib_handle, "readfile"); /* check that no error occured */ error_msg = dlerror(); if (error_msg) { fprintf(stderr, "Error locating 'readfile' - %s\n", error_msg); exit(1); } /* finally, call the function, with a given file path */ a_file = (*readfile)("hello.txt"); dlclose(lib_handle); Phill From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:26: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 OAA25602 for ; Thu, 26 Aug 2004 14:26: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 i7QI6n6u022829; Thu, 26 Aug 2004 11:06:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QI6nnf022828; Thu, 26 Aug 2004 11:06:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI6lxx022810 for ; Thu, 26 Aug 2004 11:06:48 -0700 (PDT) (envelope-from kevin.peuhkurinen@HEPCOE.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:40:50 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 17:17:21 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 16:22:45 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:25:10 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 16:24:05 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE9uP2075278; Thu, 26 Aug 2004 07:09:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QE9uur075277; Thu, 26 Aug 2004 07:09:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QE9tW9075266 for ; Thu, 26 Aug 2004 07:09:56 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 10:09:57 -0400 Message-ID: <412DEF35.7090908@hepcoe.com> Date: Thu, 26 Aug 2004 10:09:57 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: DEPLOY/IPR: Fundamental Disagreements, or Get On With It Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Aug 2004 14:09:57.0982 (UTC) FILETIME=[5E6CFFE0:01C48B76] List-Archive: List-Unsubscribe: List-ID: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hello everyone. I have been watching this thread for a while and just decided to voice my opinion. My reasons for recommending the rejection of the IPR encumbered algorithm(s) are not due to my own interpretation of the license nor my feelings about the IPR holder but rather how the license will hurt the standard in the real world: 1. The IPR license will slow development This license is not clear nor unambiguous. If it were, you would not need to seek an attorney's advice on it. I think this much we can all agree upon, including Mr. Katz himself. This means that if I'm a developer who wishes to include Sender-ID in my open source product even if my attorney tells me that doing so is allowed under the license, and Lessig and Moglen themselves publish opinions saying that doing so is allowable, it does me no good if the IPR holder disagrees and sues me. It would be me and my attorney against a multi billion dollar company with a platoon of IP lawyers and an ambiguous license in question. Even if I am in the right, trying to fight such a suit in a different country on the other side of the continent would bankrupt me within weeks. Why would any open source developer take this risk? 2. The IPR license will slow adoption I think it is safe to say that at least half (and probably more) MTAs in use are open source. Certainly most ISPs that I know of use open source MTAs. I think it is also safe to say that a majority of people who deploy open source MTAs are probably at least somewhat suspicious of the motives and business tactics of your typical multi billion dollar software companies. It is therefore likely that many of them will be slower to adopt Sender-ID if it is encumbered by this license (even if they do not themselves need to personally get a license from the holder) than otherwise. Speaking personally as an MTA admin for a medium sized company, I will not adopt Sender-ID if it is encumbered by this license. It may be argued that MTA admins will be forced by their management to adopt it eventually, but it will definitely slow down the process. Obviously these are just my opinions. IANAL, etc. However, I don't think it would be easy to argue that the IPR license in any way benefits the standard nor can it be easily argued that the license will definitely do no harm to it. I think the chairs need to decide whether the potential harm is less problematic than replacing the encumbered algorithms. Kevin Peuhkurinen Network Security Analyst HEPCOE Credit Union Ltd. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:28:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25694 for ; Thu, 26 Aug 2004 14:28: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 i7QI8Vsg022982; Thu, 26 Aug 2004 11:08: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 i7QI8V2Y022981; Thu, 26 Aug 2004 11: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.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI8SbD022969 for ; Thu, 26 Aug 2004 11:08:30 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7QIHiho022238; Thu, 26 Aug 2004 14:17:44 -0400 From: To: "'Margaret Olson'" , "'IETF MARID WG'" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 14:05:28 -0400 Message-ID: <009301c48b97$71ddcb60$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I have also had the impression that some folks on the list are > expecting Microsoft to give them what amounts to legal > advice. Your missing an important point: Some folks on the list asked for clarification of the license. Harry then referred them to consult with the MS lawyers (as opposed to answering the questions himself). Being told to "go ask my lawyer" is fundamentally different then "expecting legal advice from Microsoft". > A lawyer representing me, being paid by me, can't give you legal advice about > how to deal with me - there is a conflict of interest. AGREED! That's why Harry should have answered the questions himself, or with a response from his lawyers. Instead he opted to say "go ask my companies lawyers. I don't think that was an acceptable response, if for no other reason then the LAWYERS are not list members, and HARRY is. > So where > Microsoft does provide clarifications or suggestions it will be > caveated it left and right with "consult your own lawyer" > just to make > sure you are not confused about whose interests are being > represented. AGREED. Again a point to why HARRY should answer the questions asked of him, and/or produce a license which is more concise. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:33: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 OAA26118 for ; Thu, 26 Aug 2004 14:33: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 i7QI6Bo5022732; Thu, 26 Aug 2004 11:06: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 i7QI6BVa022731; Thu, 26 Aug 2004 11:06:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI69Np022703 for ; Thu, 26 Aug 2004 11:06:10 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Thu, 26 Aug 2004 19:40:51 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Aug 2004 18:18:10 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 18:20:34 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 18:18:45 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QG0qPo007714; Thu, 26 Aug 2004 09:00: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 i7QG0qES007713; Thu, 26 Aug 2004 09:00:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QG0p6Y007692 for ; Thu, 26 Aug 2004 09:00:51 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 26 Aug 2004 12:00:49 -0400 id 002F406A.412E0931.000062FE From: David Blacka Organization: VeriSign, Inc. To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve) Date: Thu, 26 Aug 2004 12:00:21 -0400 User-Agent: KMail/1.6.2 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: <200408261200.21556.davidb@verisignlabs.com> List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 26 Aug 2004 16:18:46.0148 (UTC) FILETIME=[5CC58C40:01C48B88] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday 26 August 2004 11:10 am, Hallam-Baker, Phillip wrote: > While David is right, there is also the corollary that *.example.com > will only match nodes that do not exist at all. So there are two issues, > do wildcards work as expected, is the wildcard useful at all. The matching > behavior means that the wildcard is not useful for the use cases given. > > i.e. if we have > > a.example.com > > *.example.com. IN TXT "v=spf1 ..." > > Will match _marid.b.example.com, b.example.com but not a.example.com > regardless of whether a has TXT records or not. This is correct. > So you can't use a wildcard to give a default SPF record for DNS > names of hosts that exist. Only the hosts that don't exist will match. > I don't know what happens for _marid.a.example.com, I think it should > not match but one of the DNS people can say for sure. You are correct, it does not match. The existence of names block wildcards at that name, and for any name below that name. To be explict, if your zone has: *.example.com. IN TXT "spf2.0/..." a.example.com. IN A 1.2.3.4 but does not contain: b.example.com. Then queries for "b.example.com. IN TXT, _marid.b.example.com. IN TXT, something-else.b.example.com. IN TXT", will all return the TXT record. Queries for "a.example.com. IN TXT, _marid.a.example.com. IN TXT, anything-else.a.example.com. IN TXT" will not return the TXT record. > IF _marid.a.example.com did match the wildcard then it would be a way > to make the wildcards useful. For some use cases. It is true that wildcards are not useful as a default "fall-back" record solution. They never were. To my mind, the paramount issue of wildcard wrt MARID is that for folks who *currently* use wildcards (i.e., for wildcard MX records), the MARID solution should be deployable, and it is, with or without a _marid prefix. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:33:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26137 for ; Thu, 26 Aug 2004 14:33:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIE1NQ023541; Thu, 26 Aug 2004 11:14:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QIE16j023540; Thu, 26 Aug 2004 11:14:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from localhost.localdomain (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIE09i023508 for ; Thu, 26 Aug 2004 11:14:01 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i7QIDsjJ022356; Thu, 26 Aug 2004 11:13:54 -0700 Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ From: Ryan Ordway To: Margaret Olson Cc: IETF MARID WG In-Reply-To: <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> References: <44B4AB1E-F765-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1093544033.21871.16.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 26 Aug 2004 11:13:54 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-26 at 06:38, Margaret Olson wrote: > > So while the license is less than ideal, it's sufficient. It is also > fundamentally defensive, and anyone with significant assets > contemplating donating IPR has to concern themselves with the defensive > legal issues. The fundamental goal is to make sure you can use your own > IPR after you have donated it, which is otherwise not assured. I would > not like to see contributions to the IETF limited to individuals and > corporations who are not successful enough to have this kind of legal > concern. For one thing, it would rule out all organizations with > significant R&D budgets. If this was the extent of the license, I would agree with you Margaret. I have no problems with Microsoft protecting themselves. I have problems with Microsoft attempting to prevent competitors, both commercial and open source, from being able to implement Internet standards without tying themselves to Microsoft. Ryan -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:34: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 OAA26240 for ; Thu, 26 Aug 2004 14:34: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 i7QICsGi023397; Thu, 26 Aug 2004 11:12: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 i7QICs0R023396; Thu, 26 Aug 2004 11:12:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QICsLX023388 for ; Thu, 26 Aug 2004 11:12:54 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 11:12:57 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 11:12:59 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 11:12:57 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 11:12:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY - IP, HELO & touch count. DOC-BUG too. Date: Thu, 26 Aug 2004 11:12:55 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAC40@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY - IP, HELO & touch count. DOC-BUG too. Thread-Index: AcSKUoStaghWsg75Qlq/zIqVc35WmwBRQpmQ From: "Jim Lyon" To: "Matthew Elvey" , "MXCOMP" X-OriginalArrivalTime: 26 Aug 2004 18:12:56.0219 (UTC) FILETIME=[4FBB6EB0:01C48B98] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QICsLX023389 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Matthew Elvey raises two points that I summarize as follows: > 1. If you don't know what a domain's outward-facing MTAs are, > it's really hard to build a SenderID record. (And he estimates > that half of his customers are in this boat.) True. > 2. If instead of SenderID, we'd merely authenticated the HELO name, > and built up reputation systems that say whether particular > HELO names behave reasonably, these people's lives would be easier. It's true, but it's a whole lot weaker form of authentication. I don't care whether a mail server is who he says he is, I care whether he's authorized to send the message he's trying to send. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:46: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 OAA27012 for ; Thu, 26 Aug 2004 14:46: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 i7QIOOrE024767; Thu, 26 Aug 2004 11: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 i7QIOOSE024766; Thu, 26 Aug 2004 11:24:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIOOXA024750 for ; Thu, 26 Aug 2004 11:24:24 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 13:24:23 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02BEBDB2@cliff.bai.org> Thread-Topic: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ thread-index: AcSLkj+0xVzJ3CsJQ46zeDbLHv0W7wABPciw From: "Ryan Malayter" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QIOOXA024760 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [wayne] > The possibility that requiring every single user of qmail to get a > signed license from Microsoft is a reason for concern. IANAL, but it is quite clear to me that the MS license requires nothing of the sort: "For clarification, this Agreement does not impose any obligation on You to require the recipients of Your source code implementations of such Licensed Implementations to accept this or any other Agreement with Microsoft. Your End Users may use the Licensed Implementations licensed in this section 2.2 or in section 2.1 that they receive directly or indirectly from You without executing this Agreement. This Agreement will be available to all parties without prejudice." So, a qmail pactch consisting of source code containing the PRA is a source code implementation. Creators of such soruce code implementations will need to sign the MS license to include PRA, but *users* do not. The trademark requirement for what is considered a "licensed implementation" seems a bit onerous. But it says NOTHING about it being a "registered trademark", and mentions no jurisdictional requirements. So make up a brand name for your qmail patch, and you have a trademark. All is right with the world. From the USPTO Trademark FAQ: Do I have to register my trademark? No, but federal registration has several advantages, including notice to the public of the registrant's claim of ownership of the mark, a legal presumption of ownership nationwide, and the exclusive right to use the mark on or in connection with the goods or services set forth in the registration. and What are common law rights? Federal registration is not required to establish rights in a trademark. Common law rights arise from actual use of a mark. Generally, the first to either use a mark in commerce or file an intent to use application with the Patent and Trademark Office has the ultimate right to use and registration. However, there are many benefits of federal trademark registration. -- Ryan From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:54: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 OAA27279 for ; Thu, 26 Aug 2004 14:54: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 i7QIRF6V024997; Thu, 26 Aug 2004 11:27: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 i7QIRFwC024996; Thu, 26 Aug 2004 11:27:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIRENk024983 for ; Thu, 26 Aug 2004 11:27:14 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 11:27:18 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 11:27:19 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 11:27:18 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 11:27:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH OMISSION: Stronger checks against email forgery Date: Thu, 26 Aug 2004 11:27:15 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAC52@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: TECH OMISSION: Stronger checks against email forgery Thread-Index: AcSKaZ5a2NrHapDxQZWYzOg6tJtfzgBLvyGg From: "Jim Lyon" To: "John Glube" , "IETF MARID WG" X-OriginalArrivalTime: 26 Aug 2004 18:27:15.0354 (UTC) FILETIME=[4FD107A0:01C48B9A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QIRENk024990 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit John points out that a forger can defeat SenderID checks by inserting a Resent-From (or similar) header that references either himself a domain that hasn't published a SenderID record. He goes on to suggest possible ameliorations, including EHLO checks and/or classic SPF checks using MAIL-FROM. He's right that there's a potential problem, but I think he got the wrong amelioration. If there's consensus that a change is required, I would recommend: Whenever the PRA is not equal to the 2822 "From", and the SenderID result is anything other than "pass", and at least 6 months have elapsed since SenderID became a Proposed Standard, then the message SHOULD be treated as forged. Reasons for this proposal: 1. For most instances of personal mail, PRA == 2822 From == bounce address, and none of these issues apply. They only apply in the cases of specialized agents like forwarders, list servers, third-party mailers and similar. 2. It's reasonable to hold specialized agents to a higher standard than the rest of the E/Mail community (by requiring a "pass" instead of merely the absence of a "fail", for instance.) 3. When the set of documents hits Proposed Standard, many of the legitimate specialized agents won't yet be in compliance. But as a whole, it's a well-managed community that can move fairly quickly. Reasons against EHLO or bounce address: 1. EHLO tells you a name for the sending MTA. But it gives you no idea whether that MTA is authorized to act on behalf of the name mentioned in the message he's sending. It seems therefore to be irrelevant. 2. bounce address tells you who wants to know if the message isn't delivered. It's also irrelevant when deciding whether the MTA is authorized to act of behalf of the name mentioned in the message he's sending. -- Jim Lyon mailto:JimLyon@Microsoft.Com tel:+1-425-706-0867 Internet commerce will never really take off until you can buy something online without getting spammed by the vendor. -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of John Glube Sent: Tuesday, August 24, 2004 10:51 PM To: 'IETF MARID WG' Subject: TECH OMISSION: Stronger checks against email forgery It is very easy to forge domain information in email. Two simple cases: * Forging the SMTP mail from address; and * Inserting a false received line or resent-from header. In essence this involves using someone else's domain without consent. Also, many who forge domain information also apparently send direct from an IP address to the recipient's mail server. Shouldn't we have stronger checks to prevent these types of activities? One approach is to run a mail from check at the data stage using the SPF record format and test protocol. Another is to run an ehelo or helo check using client smtp validation. Keep in mind those engaged in email forgery (which for sophisticated operators is a form of criminal fraud) will likely adopt approaches to muddy and defeat authentication, so that those engaged in fighting email forgery will need to use a range of tools, recognizing that although one data set might be corrupted, matching of data against a number of identifiers will likely generate better results. (I am basing these general comments on existing research and studies carried out by others in the criminal forensics field.) Amending the Sender-ID drafts to reflect using a number of data sets is one option. My personal recommendation is that a best current practices document be published concurrently with any authentication technologies recommended by this WG which would in essence recommend receivers run PRA checks using Sender-ID: Authenticating Email, mail from checks using the SPF record format and test protocol and ehelo/helo checks using client smtp validation. It may also be appropriate to establish a steering group to review and propose document updates on a regular basis, although there may be other ad hoc groups which could include this process within their mandate. 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.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:55:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27299 for ; Thu, 26 Aug 2004 14:55: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 i7QISTGl025100; Thu, 26 Aug 2004 11:28:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QISTfu025099; Thu, 26 Aug 2004 11:28:29 -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 i7QISTJl025093 for ; Thu, 26 Aug 2004 11:28:29 -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 i7QISWY07227 for ; Thu, 26 Aug 2004 11:28:32 -0700 Date: Thu, 26 Aug 2004 11:28:29 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <203073460.20040826112829@brandenburg.com> To: "IETF MARID WG" Subject: Re: DEPLOY: DNS Record Types In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAC2F@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAC2F@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 Folks, >> 1. Publishers MUST publish using the new SPF2 record type. >> Change this to SHOULD >> 2. Publishers MAY also publish using TXT records. >> Leave as is JL> I'm OK with 1, 3, 5 and 6. However, 2 and 4 need to at least be SHOULD This is starting to look like an interesting topic. If 1 is SHOULD and 2 is MAY or SHOULD, then the publisher of the information is not mandated to publish in any particular form. If there were a problem with publishing the new record type, that would be a significant barrier. Unless there is a claim that publishing such data is highly problematic, then requiring the long-term record type to be used seems to make sense. What I have assumed we are facing is a problem with requiring that only that record get used throughout the system. That's different than whether it is published. Looking at the other side of this, making publishing in a TXT record be a SHOULD means that there is a long-term requirement for support, whereas the intention is to use it for the near-term. So, I suggest that #1 be MUST and #2 be MAY, with a note about the reason that one is likely to want to publish #2 as well as #1. What is the problem with this view? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14:56: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 OAA27357 for ; Thu, 26 Aug 2004 14:56: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 i7QIZRkJ026169; Thu, 26 Aug 2004 11:35:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QIZRHa026168; Thu, 26 Aug 2004 11:35:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIZQYo026162 for ; Thu, 26 Aug 2004 11:35:26 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-103-225.area3.spcsdns.net ([68.245.145.169]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0P5r-0006nh-R5; Thu, 26 Aug 2004 14:35:28 -0400 Message-ID: <412E2D60.6070603@solidmatrix.com> Date: Thu, 26 Aug 2004 14:35:12 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'Ryan Ordway'" , "'IETF MARID WG'" Subject: Re: Can there be an early decision on the SenderID license? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: >> It will not take a valid legal argument to derail >>the widespread deployment of any standard that comes from >>this working group. All that is needed is the, perhaps >>unfounded, fear that implementing SenderID or any other >>standard with nebulous IPR issues is going to bite the user >>in a tender area. > > > An unfounded claim can certainly block progress. But an > unsubstantiated claim cannot. > > It is not sufficient to say 'we don't like it' > This is no longer simple unsubstantiated. Two prominent open source *lawyers* have expressed their expert opinion that this license is not compatible with open source software: http://www.imc.org/ietf-mxcomp/mail-archive/msg03678.html The facts are on the table: this license is potentially not usable with open source software. This is something that will affect deployment since anyone using open source will be hesistating before implementation. Whether their interpretation is correct is irrelevant - the fact that multiple lawyers are not arguing about it, only makes the legal issue more confusing, thus delaying deployment. Yakov From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 14: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 OAA27486 for ; Thu, 26 Aug 2004 14: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 i7QIWU8D025569; Thu, 26 Aug 2004 11:32: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 i7QIWU4S025568; Thu, 26 Aug 2004 11:32:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vodka.at-once.com (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIWTDG025545 for ; Thu, 26 Aug 2004 11:32:29 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vodka.at-once.com (8.12.11/8.12.11) with ESMTP id i7QIWSC8003046; Thu, 26 Aug 2004 11:32:28 -0700 Subject: RE: Can there be an early decision on the SenderID license? From: Ryan Ordway To: "Hallam-Baker, Phillip" Cc: "'IETF MARID WG'" In-Reply-To: References: Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1093545147.2995.4.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 26 Aug 2004 11:32: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-08-26 at 10:59, Hallam-Baker, Phillip wrote: > > It will not take a valid legal argument to derail > > the widespread deployment of any standard that comes from > > this working group. All that is needed is the, perhaps > > unfounded, fear that implementing SenderID or any other > > standard with nebulous IPR issues is going to bite the user > > in a tender area. > > An unfounded claim can certainly block progress. But an > unsubstantiated claim cannot. > > It is not sufficient to say 'we don't like it' Surely you are correct, when referring to the design of the standard. I am referring to the post-design deployment. -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 15:07:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28234 for ; Thu, 26 Aug 2004 15:07:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIcQrY026409; Thu, 26 Aug 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 i7QIcQgq026408; Thu, 26 Aug 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 manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIcPg2026401 for ; Thu, 26 Aug 2004 11:38:25 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-103-225.area3.spcsdns.net ([68.245.145.169]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0P8i-00077R-N1; Thu, 26 Aug 2004 14:38:26 -0400 Message-ID: <412E2E14.8090209@solidmatrix.com> Date: Thu, 26 Aug 2004 14:38:12 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 CC: "Hallam-Baker, Phillip" , "'Ryan Ordway'" , "'IETF MARID WG'" Subject: Re: Can there be an early decision on the SenderID license? (typo fixed) References: <412E2D60.6070603@solidmatrix.com> In-Reply-To: <412E2D60.6070603@solidmatrix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yakov Shafranovich wrote: > Hallam-Baker, Phillip wrote: > >>> It will not take a valid legal argument to derail >>> the widespread deployment of any standard that comes from >>> this working group. All that is needed is the, perhaps >>> unfounded, fear that implementing SenderID or any other >>> standard with nebulous IPR issues is going to bite the user >>> in a tender area. >> >> >> >> An unfounded claim can certainly block progress. But an >> unsubstantiated claim cannot. >> >> It is not sufficient to say 'we don't like it' >> > > This is no longer simple unsubstantiated. Two prominent open source > *lawyers* have expressed their expert opinion that this license is not > compatible with open source software: > > http://www.imc.org/ietf-mxcomp/mail-archive/msg03678.html > > The facts are on the table: this license is potentially not usable with > open source software. This is something that will affect deployment > since anyone using open source will be hesitating before > implementation. Whether their interpretation is correct is irrelevant - > the fact that multiple lawyers are arguing about it, only makes the > legal issue more confusing, thus delaying deployment. > > Yakov > From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 16:15: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 QAA06768 for ; Thu, 26 Aug 2004 16:15:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QJncY7033089; Thu, 26 Aug 2004 12:49: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 i7QJnc81033088; Thu, 26 Aug 2004 12:49:38 -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 i7QJnbVD033082 for ; Thu, 26 Aug 2004 12:49:37 -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 i7QJnfg2018431 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 26 Aug 2004 12:49:41 -0700 Date: Thu, 26 Aug 2004 12:49:41 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: IETF MARID WG Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ 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, 26 Aug 2004, wayne wrote: > This is incorrect. Qmail *is* being maintained, just not by DJB. As I > mentioned in my first post[1] about possible qmail conflicts with the > SenderID license, the qmail community has to use patches to maintain > the program. This makes life hard, but apparently, enough people like > it that qmail is still one of the most popular MTAs (possibly the second > most popular after sendmail). So in spite of its burdensome and open source incompatible license, qmail has *still* managed to see wide deployment. (Some would say that qmail's license is /wildly/ more restrictive than Sender ID's). > The possibility that requiring every single user of qmail to get a > signed license from Microsoft is a reason for concern. (Yes, this is > orders of magnitude more work than the patches that qmail users have > to do.) The license requires no such thing from end-users of qmail that are applying patches. > You are right, we should not be constrained by licensing terms of > packages. We should, however be constrained by deployment issues. You are exactly right. So what's the issue? ;) -Rand From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 16:35:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09375 for ; Thu, 26 Aug 2004 16:35: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 i7QKEjoa035151; Thu, 26 Aug 2004 13:14: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 i7QKEjYV035150; Thu, 26 Aug 2004 13:14:45 -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 i7QKEjlk035143 for ; Thu, 26 Aug 2004 13:14:45 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7QKEDP7023784 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Aug 2004 13:14:13 -0700 Date: Thu, 26 Aug 2004 13:14:13 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Jeff Macdonald cc: John Glube , ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <1093539963.30660.28.camel@jmacdonald-work.e-dialog.com> Message-ID: References: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> <1093539963.30660.28.camel@jmacdonald-work.e-dialog.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 Aug 2004, Jeff Macdonald wrote: > > No. Both I and the people looking to implement these records feel quite > > strongly that using the same record for both is very dangerous. In fact, > > these largest sites are the ones who are *most* likely to have different > > records (bit of a Catch 22 there). > > Could you give an example? Or point to one is such an example exists? Example of large sites that will have spfv1 records that would differ from spfv2.0/pra? Sure: A number of very large commercial banks run fairly complex outbound mail systems. More complex even than AOL -- which seems to be the yardstick -- because their email systems have evolved over the years through various business actions. It's not uncommon for a single bank to send outbound mail from more than a *dozen* different systems scattered all over the world (literally, more than a dozen). In ip4: notation this would take something like 12 x 21 bytes = 252. (Note that these outbound sites are completely separate from their inbound servers, so mx: wouldn't work). Add to this the fact that these corporations regularly outsource marketing and other material delivery to third party firms. Since they want these messages to be branded as coming from their primary domain, the spv2.0/pra record would include many include: statements like "include:esp1.com include:esp2.com include:esp3.com" It doesn't take many additions here to completely blow that 240 byte-ish limit that we're bumping up against by inserting *two* records in one UDP response packet. How would this differ from their spfv1 record? Well, since most outsourced mailings use an ESP-controlled MAIL FROM address (for bounce handling purposes), the spfv1 record would not necessarily include those additional ESP references. So for a specific bank I am thinking of (13 outbound sites + 8 identified ESP partners), the spfv2.0/pra record would be something like 401 bytes and the spfv1 record would be something like 252 bytes, for a total of 653 bytes, blowing the cap on the UDP response packet. Note that this doesn't apply just to banks, I've talk to numerous online consumer sites and various media companies that will have the same problem. They didn't have concerns when it looked like Sender ID would re-use the same records as spfv1, but now they are starting to worry. The complexity of global corporate mail systems is not to be believed and to assume that Hotmail/AOL/Yahoo have the biggest outbound delivery system is being a little naive. -Rand From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 16:35: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 QAA09393 for ; Thu, 26 Aug 2004 16:35: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 i7QKCV8c035011; Thu, 26 Aug 2004 13:12:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QKCVoV035010; Thu, 26 Aug 2004 13:12:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QKCVqt035000 for ; Thu, 26 Aug 2004 13:12:31 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 13:12:32 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 13:12:32 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 13:12:32 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 13:12:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Thu, 26 Aug 2004 13:12:28 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAC96@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Legal liability for creating bounces from forged messages Thread-Index: AcSKgy6894WqyUEBT6WlsK/idw+UGQBF2W+g From: "Jim Lyon" To: "Chris Haynes" Cc: "IETF MARID WG" X-OriginalArrivalTime: 26 Aug 2004 20:12:10.0521 (UTC) FILETIME=[F8074890:01C48BA8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QKCVqt035005 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Regarding silently discarding messages, Chris Haynes writes: > Actually I was advocating (2) [silent discard] - but only > in the special case when the Mail-From entity has declined > responsibility for the message by causing a test 'fail'. In other words, Chris believes that it's OK to silently discard mail when you believe the bounce address is forged, but not when the PRA is forged. I submit that, as a matter of practice, people who forge one also forge the other. Also as a matter of practice, checking the PRA will produce fewer false rejections than checking the bounce address will. Chris also disputes that there is any legal basis for silently discarding mail at all. He's right that RFC 2821 requires that every message be delivered, rejected or bounced. However, see draft-zinn-smtp-bounces-01, which explicitly authorizes silent discards. (I know, it's not a standard. Yet.) See also RFC 3834, which deals with automated responses in general (including bounces) and says: - A responder MAY refuse to send a response to a subject message which contains any header or content which makes it appear to the responder that a response would not be appropriate. RFC 3834 is now a Proposed Standard. Quoting Chris again: > You claim in (2) that the drafts give authority for MTAs to silently > discard messages. I cannot find that authority in the drafts. In the SenderID drafts, the only requirement imposed is that if an MTA performs SenderID tests during a mail transaction and the test fails, it SHOULD reject the message. This leaves open two possibilities for silent discards: 1. An MTA might ignore the above SHOULD (after all, it's not MUST). 2. An MTA might perform the tests after receipt, in which case the specs impose no requirement on what the MTA does. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 16:39: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 QAA09734 for ; Thu, 26 Aug 2004 16:39: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 i7QKJbKn035481; Thu, 26 Aug 2004 13:19:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QKJbYJ035480; Thu, 26 Aug 2004 13:19:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QKJbk9035474 for ; Thu, 26 Aug 2004 13:19:37 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 13:19:41 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 13:19:41 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 13:19:41 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 13:19:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Thu, 26 Aug 2004 13:19:37 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FACB0@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Legal liability for creating bounces from forged messages Thread-Index: AcSKjvZPCfbWhh81R2ekvsBzp/Up2wBGlTuw From: "Jim Lyon" To: "Stephane Bortzmeyer" , "John Glube" Cc: "IETF MARID WG" X-OriginalArrivalTime: 26 Aug 2004 20:19:18.0720 (UTC) FILETIME=[F7414400:01C48BA9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QKJbk9035475 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Stephane Bortzmeyer asks: > Is it unrealistic to assume that, if the current Sender-ID becomes a > RFC as it is, nevertheless, some people will use SPF records (as > specified in -protocol) to perform checks on the 2821 MAIL FROM and > not only on the official PRA? A sort of unofficial "Unified SPF"? Yes, it's realistic to assume that some software will do this. The technical term for such a program is "broken". :-) The whole point of having a standard is so that senders know what the expectations are for the mail they send, and that receivers know what they should be looking for. The whole PRA stuff was invented because of an observation that there's lots of legitimate mail that passes a PRA check but fails a bounce-address check. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 16:44: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 QAA10245 for ; Thu, 26 Aug 2004 16:44: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 i7QKPQm9035845; Thu, 26 Aug 2004 13:25:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QKPQLn035844; Thu, 26 Aug 2004 13:25:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.e-dialog.com (mail1.e-dialog.com [64.28.75.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QKPPcO035831 for ; Thu, 26 Aug 2004 13:25:25 -0700 (PDT) (envelope-from jeff.macdonald@e-dialog.com) Received: from [10.0.40.189] (jm-node4.e-dialog.com [10.0.40.189]) by mail1.e-dialog.com (8.12.11/8.12.10) with ESMTP id i7QKPM5c016075; Thu, 26 Aug 2004 16:25:22 -0400 Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ From: Jeff Macdonald To: Rand Wacker Cc: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Organization: E-Dialog Message-Id: <1093551922.30660.52.camel@jmacdonald-work.e-dialog.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 26 Aug 2004 16:25:22 -0400 Content-Transfer-Encoding: 7bit X-Spam-Hits: -4.9 EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-26 at 15:49, Rand Wacker wrote: > On Thu, 26 Aug 2004, wayne wrote: > > > This is incorrect. Qmail *is* being maintained, just not by DJB. As I > > mentioned in my first post[1] about possible qmail conflicts with the > > SenderID license, the qmail community has to use patches to maintain > > the program. This makes life hard, but apparently, enough people like > > it that qmail is still one of the most popular MTAs (possibly the second > > most popular after sendmail). > > So in spite of its burdensome and open source incompatible license, qmail > has *still* managed to see wide deployment. (Some would say that qmail's > license is /wildly/ more restrictive than Sender ID's). > Qmail is one of several MTAs that one can choose. If there is only one way to determine a PRA and that way requires a license then that leaves no freedom to choose. I know of no binary based Distributions that distribute Qmail. But those distributions have other choices to choose from. It seems to me that this license would exclude Open Software based distributions. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 16: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 QAA10625 for ; Thu, 26 Aug 2004 16:50: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 i7QKRMug036258; Thu, 26 Aug 2004 13:27:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QKRMXa036256; Thu, 26 Aug 2004 13:27: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 i7QKRKBr036221 for ; Thu, 26 Aug 2004 13:27:20 -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 i7QKRObj026658 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Aug 2004 13:27:24 -0700 Date: Thu, 26 Aug 2004 13:27:24 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: John Glube cc: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <011e01c48b92$d2081e50$6c62fea9@ibmrkydk2ufvdd> Message-ID: References: <011e01c48b92$d2081e50$6c62fea9@ibmrkydk2ufvdd> 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, 26 Aug 2004, John Glube wrote: > My view from a security perspective is that the best > approach is to not rely on either one approach or one data > set, but to do both message and channel authentication > using a variety of data sets. I totally agree. It has been Sendmail's stated belief for quite some time that multiple technologies will arise to address these issues and it is our intention to support those that work best to meet the needs of the Internet community at large. > * Whether within Sender-ID it made more sense to go with > the same version of records as SPF. > > You have raised a catch 22 problem for larger organizations > with complex records. Going the sub-domain route raises > catch 22 problems for the vast number of individual domain > holders. Hmm, in addition to working with a number of globally large enterprise customers, Sendmail also represents a huge number of those individual domain holders (I for one manage a "vast number" of individual domains in my spare time ;) I haven't seen much that presents a problem deploying to sub-domains. In fact, our operational experience with DomainKeys so far has shown using a whole separate sub-domain namespace gives you a tremendous amount of flexibility in both record depth and server deployment. > * How would the FTC view what is decided given the FTC > mandate to protect the US consumer's interest, ensure > competition and protect against unfair trade? Not speaking for the FTC, but the universal core concern for the large enterprises I've talked to (the ones whose customers are targets of phishing campains) are as follows: - Firstly, to provide end-users the information to protect themselves by authenticating something the end user will see - Secondly, to ensure reliable delivery of their customer relationship email Because of these dual requirements -- and because of the already well-publicized recommendations by many large receivers that volume senders publish one/the other/both -- senders are going to deploy records for Sender ID /and/ for SPF, and almost all of them are looking at what its going to take to put a cryptographic signer in place in the future as well. My whole point of this thread is to point out the real-world deployment issues that utlizing the top-level FQDN TXT space is going to pose. I fully support making some type of indication of what records apply to what message addresses, I'm looking for different alternatives. -Rand From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 17:03: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 RAA11921 for ; Thu, 26 Aug 2004 17: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 i7QKZJjZ036924; Thu, 26 Aug 2004 13:35: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 i7QKZJfN036923; Thu, 26 Aug 2004 13:35: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 i7QKZJvW036916 for ; Thu, 26 Aug 2004 13:35: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 E21F6414DA; Thu, 26 Aug 2004 13:35:23 -0700 (PDT) Subject: RE: DEPLOY - IP, HELO & touch count. DOC-BUG too. From: Douglas Otis To: Jim Lyon Cc: Matthew Elvey , MXCOMP In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAC40@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAC40@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1093552522.4552.163.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 26 Aug 2004 13:35: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 Thu, 2004-08-26 at 11:12, Jim Lyon wrote: > Matthew Elvey raises two points that I summarize as follows: > > > 1. If you don't know what a domain's outward-facing MTAs are, > > it's really hard to build a SenderID record. (And he estimates > > that half of his customers are in this boat.) > > True. > > > 2. If instead of SenderID, we'd merely authenticated the HELO name, > > and built up reputation systems that say whether particular > > HELO names behave reasonably, these people's lives would be easier. > > It's true, but it's a whole lot weaker form of authentication. An authenticated and authorized EHLO domain as an "accountable identity" is orders of magnitude stronger than what is established using a Sender-ID selection of an RFC2822 Mailbox Domain as an "accountable identity." The authentication of the EHLO domain clearly authenticates the entity sending the mail as a message broker. The identity of the sender is obfuscated by the relayed nature of mail (the many brokers). The identity of the sender depends upon these brokers controlling access. Any identity that attempts to resolve to a sender is premised upon each broker controlling access. Nothing within Sender-ID can establish this assumption. Nothing within Sender-ID locates a specific MTA not controlling access. Basing reputation on EHLO would locate faulty MTA administration. Nothing within Sender-ID allows a strong assertion of the sender's identity. > I don't care whether a mail server is who he says he is, I care > whether he's authorized to send the message he's trying to send. Authentication is not authorization! A) Is the specific Mailbox Domain within a prescribed Mail Channel? B) Is this the sender of the message? These are two different questions you seem to be confusing. By implying Sender-ID provides the answer to 'B', grievous harm may befall those submitted to a reputation service. As the EHLO domain does authenticate the entity, unlike Sender-ID, this identity can be safely submitted to a reputation service. It would be "really good" if Microsoft would include all the headers when mail gets forwarded to facilitate a reputation submittal. It would be "really bad" if Microsoft convinced users, only the PRA is required. Whether the Mailbox Domain is within a prescribed Mail Channel forms an entirely different question from whether is this the sender of the message! See: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt Although there may be exceptional Mailbox Domain restrictions or sorting based upon prescribed message brokers, there is _no_ means to authenticate the author of message in this manner. The MTA may be shared, the MTA may not be checking Mail Channel prescriptions for submitted Mailbox Domains, and a lapse may occur within either an inbound or an outbound relay. SMTP is not an end-to-end system. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 17: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 RAA13710 for ; Thu, 26 Aug 2004 17:21:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QKw2AE038614; Thu, 26 Aug 2004 13:58:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QKw2ed038613; Thu, 26 Aug 2004 13:58:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QKw2Db038607 for ; Thu, 26 Aug 2004 13:58:02 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 13:58:06 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 13:58:06 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 13:58:06 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 13:57:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Misuse of Resent-From Date: Thu, 26 Aug 2004 13:58:02 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAD06@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Misuse of Resent-From Thread-Index: AcSK4W8FlD/DCSknS96iiZ3QN+vIfwAzTfqw From: "Jim Lyon" To: "Douglas Otis" , "MARID" X-OriginalArrivalTime: 26 Aug 2004 20:57:40.0302 (UTC) FILETIME=[531ACEE0:01C48BAF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QKw2Db038608 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In a long message, Doug Otis says (I think) that SenderID is broken because (1) We verify the PRA, which isn't just the 2822 From, and (2) We don't verify the identity of the MTA that sent the message. While agreeing with (1) and (2), the conclusion that that SenderID is broken doesn't follow. He argues that merely validating the EHLO domain is far better. I disagree. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 17:25: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 RAA14093 for ; Thu, 26 Aug 2004 17:25: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 i7QL6rha039607; Thu, 26 Aug 2004 14:06: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 i7QL6rJd039606; Thu, 26 Aug 2004 14:06:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.e-dialog.com (mail1.e-dialog.com [64.28.75.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QL6q66039585 for ; Thu, 26 Aug 2004 14:06:52 -0700 (PDT) (envelope-from jeff.macdonald@e-dialog.com) Received: from [10.0.40.189] (jm-node4.e-dialog.com [10.0.40.189]) by mail1.e-dialog.com (8.12.11/8.12.10) with ESMTP id i7QL6nO5021030; Thu, 26 Aug 2004 17:06:51 -0400 Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) From: Jeff Macdonald To: Rand Wacker Cc: John Glube , ietf-mxcomp@imc.org In-Reply-To: References: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> <1093539963.30660.28.camel@jmacdonald-work.e-dialog.com> Content-Type: text/plain Organization: E-Dialog Message-Id: <1093554409.30660.86.camel@jmacdonald-work.e-dialog.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 26 Aug 2004 17:06:49 -0400 Content-Transfer-Encoding: 7bit X-Spam-Hits: -4.9 EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-26 at 16:14, Rand Wacker wrote: > On Thu, 26 Aug 2004, Jeff Macdonald wrote: > > > > No. Both I and the people looking to implement these records feel quite > > > strongly that using the same record for both is very dangerous. In fact, > > > these largest sites are the ones who are *most* likely to have different > > > records (bit of a Catch 22 there). > > > > Could you give an example? Or point to one is such an example exists? > > Example of large sites that will have spfv1 records that would differ from > spfv2.0/pra? Sure: Actually I meant "using the same record for both is very dangerous". I suppose you mean hitting the UDP limits. But since you detailed the 2 records scenario I'm kinda confused. complex bank scenario > Add to this the fact that these corporations regularly outsource marketing > and other material delivery to third party firms. Since they want these > messages to be branded as coming from their primary domain, the spv2.0/pra > record would include many include: statements like "include:esp1.com > include:esp2.com include:esp3.com" It doesn't take many additions here to > completely blow that 240 byte-ish limit that we're bumping up against by > inserting *two* records in one UDP response packet. > I'm sure there is a real concern about the size. However, these records would be in the the Bank's primary domain space. > How would this differ from their spfv1 record? Well, since most > outsourced mailings use an ESP-controlled MAIL FROM address (for bounce > handling purposes), the spfv1 record would not necessarily include those > additional ESP references. I think you meant the Bank's IPs listed (SPF2) in the Bank's primary domain won't/shouldn't be listed in the ESP's spf records. However, since the MAIL FROM is in the ESP's domain space, is this not a separate DNS record anyway? See my confusion? If MAIL FROM and Header FROM are different in the domain portion that should mean that different DNS records need to be looked up. I realize with Sender-ID doubles the amount of data. The SPF and SPF2 records would indeed be different. However, help me understand how the content of a SPF/SPF2 record could be different if the MAIL FROM and the PRA have the same domain portion. -- :: Jeff Macdonald | Senior Software Engineer :: e-Dialog | jmacdonald@e-dialog.com :: 131 Hartwell Ave. | Lexington, MA 02421 :: v: 781-372-1922 | f: 781-863-8118 :: www.e-dialog.com From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 17: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 RAA14648 for ; Thu, 26 Aug 2004 17:34: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 i7QLDOd6040154; Thu, 26 Aug 2004 14:13:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QLDOKC040151; Thu, 26 Aug 2004 14:13:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLDNce040130 for ; Thu, 26 Aug 2004 14:13:23 -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 8904240EB for ; Thu, 26 Aug 2004 14:13:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <011e01c48b92$d2081e50$6c62fea9@ibmrkydk2ufvdd> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Thu, 26 Aug 2004 14:13:41 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm not going to weigh in on the underlying debate here, but I'm going to inject some information that might be useful: 1) Domains with large records will overflow the UDP limit: Domains with large records that want to publish large, different records for under both v=spf1 and spf2.0/pra can do so as follows: example.com. IN TXT "v=spf1 redirect=_spf1.%{d}" example.com. IN TXT "spf2.0/pra redirect=_spf2.%{d}" _spf1.example.com. IN TXT "v=spf1 ... some very long record here ..." _spf2.example.com. IN TXT "spf2.0/pra ... some different very long record here ..." Yes, this will require two DNS lookups (though both can be cached the same as the one, so any reasonable TTL makes this less of an issue). Neither query will fall over to TCP (assuming the long records are individually under the UDP limit) 2) Wildcards All the major points about wildcards have been made: Essentially, they don't work the way you'd like them to whether or not there is a prefix -- it is the nature of DNS wildcards. On the other hand, if a domain uses wildcard MX records, then wildcard TXT and/or SPF2 records can be used to achieve a matching effect. See the protocol-03 draft for an example and discussion of just this point. I will only add here that publishing under a prefix or not makes no difference - the use of wildcards has the same caveats and difficulties. 3) Incorporating scope into the record format Several schemes have been proposed on this list for incorporating scoping into the protocol syntax. I will summarize them here: 3a) Put scopes in the field Proposed by Wayne in http://www.imc.org/ietf-mxcomp/mail-archive/msg03441.html This scheme replaces the "/pra" and field in the version string with a list of scopes. For example: "spf2.0/pra,mailfrom" or "spf2.0/mailfrom". It applies to the whole record, so it only helps domains with very large records if their v=spf1 and spf2.0/pra records are otherwise the same. If the above two large records were the same, this would look like: example.com. IN TXT "spf2.0/pra,mailfrom ... some very long record here ..." If the large records are different, they'd still have to resort to the method presented in (1) above. 3b) Add a scope macro %{e} Originally in the Unified-SPF concept, but recently proposed by Meng in http://www.imc.org/ietf-mxcomp/mail-archive/msg03663.html This scheme adds a macro that is replaced with the identifier for the scope being checked: "pra" or "mailfrom". It can be used with the include: mechanism or redirect= modifier to incorporate different parts into mostly common record: example.com. IN TXT "spf2.0/pra ...common... redirect=_%{e}.%{d}" _pra.example.com. IN TXT "spf2.0/pra ... pra only stuff ..." _mailfrom.example.com. IN TXT "spf2.0/pra ... mailfrom only stuff ..." If the common mechanisms work, then only one DNS query needs to be done. Otherwise, this basically devolves into the method presented in (1) above. 3c) Add a scope modifier Variations discussed in the past, recently proposed by William in http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html This scheme adds a modifier that alters the applicable scope for the following mechanisms until the next scope modifier. For the big company case, this is only a help if bulk of the records for PRA and MAILFROM are the same, and the common, plus all the difference, plus the overhead of the scope modifier still fit in one record: example.com. IN TXT "v=spf1 ... mailfrom only stuff ... " "sc=pm ...common... " "sc=m -all " "sc=p ... pra only stuff ..." If it doesn't fit, then it devolves into the method presented in (1) above. This idea has several structural problems: Modifiers would have to be substantially reworked to achieve this "environment variable" like behavior. The current document doesn't support such modifiers. Also, this scheme has several important subtle restrictions to achieve backward compatibility with existing SPF systems. 3-Summary) For sites where records for Sender-ID and SPF are large, similar though not the same, none of these methods is a win over the method in (1). For sites with small, similar records, only (3c) has any advantage over (1). For sites where the records are the same (claimed by many to be the vast majority of sites), (3a) is the biggest win. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 17:36: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 RAA14838 for ; Thu, 26 Aug 2004 17:36:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLI2cM040545; Thu, 26 Aug 2004 14:18: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 i7QLI2QB040544; Thu, 26 Aug 2004 14:18:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLHxCT040537 for ; Thu, 26 Aug 2004 14:18:02 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 14:18:04 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 14:18:04 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 14:18:04 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 14:17:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH-ERROR: DNS Record Types Date: Thu, 26 Aug 2004 14:18:00 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAD21@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: TECH-ERROR: DNS Record Types Thread-Index: AcSJ80ETSrGH2noTTjCdiXcnLg6G4wBvUKaA From: "Jim Lyon" To: "Ted Hardie" , "IETF MARID WG" X-OriginalArrivalTime: 26 Aug 2004 21:17:59.0706 (UTC) FILETIME=[29ED17A0:01C48BB2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QLI2CT040539 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Regarding publishing TXT records, Ted Hardie (speaking just for himself) said: > I am concerned that MUST here means that we can never transition. > While I would agree with shifting SPF2 from MUST to SHOULD, > I believe, speaking personally, that strengthening MAY to MUST > goes to far. Both as SHOULDs makes some sense; at the moment > someone can deploy without SPF2 if they cannot publish > the new record, but in the future someone can deploy without > publishing a TXT record (which they may want to do in order to > use TXT for something else). A few points: 1. If we went with "MUST" like I proposed, a future transition away from TXT records takes the following direction: a. Initially, everyone publishes TXT records, and those that can publish SPF2 records. Those that can, query SPF2 records, and then TXT records if no SPF2 record exists. (Those who can't query SPF2 records just query TXT records.) b. Time passes, and more and more people gain the ability to publish and query SPF2 records. c. Eventually, almost everyone publishes SPF2 records and almost everyone queries for SPF2 and gets a response. At this time, the TXT records still exist but are not being queried for. d. A future standards effort reduces the MUSTs about TXT records to MAY (or possibly even to SHOULD NOT). 2. Even if the spec said SHOULD about TXT records instead of MUST (as Ted suggests), the future evolution is exactly the same. 3. If time passes and SPF2 records do not become widely deployed / queried, then MUST was probably the right thing for the spec. 4. While I still believe that "MUST" is a better choice, I could probably live with "SHOULD". -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 17:45:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15381 for ; Thu, 26 Aug 2004 17:45:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLPLge041380; Thu, 26 Aug 2004 14:25: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 i7QLPLQK041379; Thu, 26 Aug 2004 14:25:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLPK52041373 for ; Thu, 26 Aug 2004 14:25:20 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 14:25:25 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 14:25:25 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 14:25:24 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 14:25:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Legal liability for creating bounces from forgedmessages Date: Thu, 26 Aug 2004 14:25:21 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAD2B@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: RE: DEPLOY: Legal liability for creating bounces from forgedmessages Thread-Index: AcSLszEIs74XMkgQQiazrxqfWWadUw== From: "Jim Lyon" To: "Mark Shewmaker" , "MARID" X-OriginalArrivalTime: 26 Aug 2004 21:25:21.0520 (UTC) FILETIME=[31448F00:01C48BB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QLPK52041374 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Mark Shewmaker point out that if you have an SMTP transaction for which *all* of the following are true: 1. The sender didn't use SUBMITTER, and 2. There is more than one recipient, and 3. The SenderID test fails, and 4. Your MTA implements a per-user white list for SenderID failures, and 5. At least one recipient white-listed the PRA, and 6. At least one other recipient didn't white-list the PRA, and 7. You feel it's immoral to silently discard forged mail then you need to generate a bounce (instead of rejecting a message). He's right. But it's such a corner case that I'm not worried. This should be a very small fraction of the mail, and won't generate very many bounces at all. He then goes on to argue that if we validated the bounce address instead of the PRA, he wouldn't need to generate a bounce. He's right again. But I don't see this minor virtue of checking bounce addresses outweighing the fact that checking bounce addresses too often gives the wrong answer. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 17: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 RAA16054 for ; Thu, 26 Aug 2004 17:54: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 i7QLZuA4042149; Thu, 26 Aug 2004 14:35:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QLZufv042148; Thu, 26 Aug 2004 14:35:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLZtBI042138 for ; Thu, 26 Aug 2004 14:35:55 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 14:35:57 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 14:35:57 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 14:35:56 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 14:35:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Thu, 26 Aug 2004 14:35:53 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAD36@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Thread-Index: AcSLICR3EhOECX5tTYCGB8PNFpYGfgAk7SrA From: "Jim Lyon" To: "Rand Wacker" , X-OriginalArrivalTime: 26 Aug 2004 21:35:55.0445 (UTC) FILETIME=[AB1DD650:01C48BB4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QLZtBI042143 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In this thread, Rand points out that complicated domains may wish to publish both SPF1 and SPF2 records, and that this effectively cuts their maximum record size in half (if they want to fit into a DNS UDP packet, which they do). He also points out than these are exactly the domains that may be pushing the DNS UDP size limits. While this is an issue, there's a trivially easy workaround: For your domain, publish very short SPF1 and SPF2 records, that just contain "REDIRECT=subdomain". If your SPF1 and SPF2 data are identical, they can both refer to the same subdomain; if your SPF1 and SPF2 data differ, they can refer to different subdomains. Problem solved. But wait, I hear critics cry: Doesn't that double the number of lookups someone has to do? Yes, it does. But the large, complicated domains that have this issue are almost exactly the ones that send lots of legitimate mail. As such, their records will usually already be in your resolver's DNS cache. (Said differently, it doesn't matter how complicated AOL's records are, because your DNS cache will only fetch them once a week.) -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 18:02: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 SAA16611 for ; Thu, 26 Aug 2004 18:02: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 i7QLhdpo042616; Thu, 26 Aug 2004 14:43:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QLhd5x042615; Thu, 26 Aug 2004 14:43:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLhcd9042609 for ; Thu, 26 Aug 2004 14:43:39 -0700 (PDT) (envelope-from SRS0=wCa/I6YQ=LQ=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7QLhgAm021218 for ; Thu, 26 Aug 2004 23:43:42 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408262143.I7QLHG72021208@asarian-host.net> Date: Thu, 26 Aug 2004 21:43:42 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: DEPLOY - reference implementation X-Trace: XYuW7oSGC7/4+7tvO2bxng9/Ai3mn0AiwXailKqoPoHWllD6tjmh+kUHvcBsy75P9hmC1x4xl9v9xUsqpDm4Fg== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <412CE5F4.5010006@redhat.com> <20040826111249.GA5702@nic.fr> <200408261400.I7QE01HM006259@asarian-host.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0683_01C48BC6.58265870" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQS5ZjjFqW1BleBN9AQElhAf6A2/2/DU6Kg69jpFbe/kqkf7N6cozv6dM Xlr7hmG+61ASRZaTawi1UIQH4E+/CquL7kw+5RZAYnoW/EhSQ7AONQmKfPtRc787 pEt5we3gOT2Zkcj2lVe8lRFpUXRjNQKCCNhX6XDTjuNj7ETN8c9l9rjeoVoIfYkv zyh4cdU+OZyxWLU/c9e/bo4wnd46uSPc9wFHiMfVkA7cCuAG121QUaBQHdEINUmv jGDhVV+kvwS5iIBWW3WfVlHt41lbJJk4MBtee8leNX9V6AwB/XLXmW/mS9Gzi8n4 lz4cougQDhMdMzvd2irNvkWWpWFHdvX/juuWHAQrv+/nWiKaVATygA== =m38G 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_0683_01C48BC6.58265870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mark wrote: > Just for the heck of it, here is my Perl implementation of PRA. :) Ok, last call. :) Not to worry, code is still the same; just all tidied up, and all neatly condensed into this one "gimme_pra" subroutine, for easy use within your own program. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx ------=_NextPart_000_0683_01C48BC6.58265870 Content-Type: application/octet-stream; name="pra2.pl" Content-Disposition: attachment; filename="pra2.pl" Content-Transfer-Encoding: quoted-printable #!/usr/local/bin/perl -w=0A= #=0A= # AIM: Implements the PRA (Purported Responsible Address) algorithm=0A= # described in Internet-Draft draft-ietf-marid-par-00.txt.=0A= #=0A= # USE: ./pra.pl =0A= #=0A= # Requires: Perl.=0A= # mailTools-1.64=0A= #=0A= # LICENCE: trivial work, not patentable, not licenceable.=0A= #=0A= # WARNING: Microsoft claims a patent on the PRA algorithm.=0A= # The author did not requested a licence.=0A= #=0A= # AURHOR: Mark Kramer =0A= =0A= use Mail::Address;=0A= use strict;=0A= =0A= my $pra;=0A= my $header;=0A= =0A= sub gimme_pra {=0A= my @candidates;=0A= if (eval {((@candidates =3D Mail::Address -> parse (extract_header = (@_))) =3D=3D 1)}) {=0A= return (lc (pop (@candidates) -> address ()));=0A= } else {=0A= return undef;=0A= }=0A= sub extract_header {=0A= (my $header =3D (shift)) =3D~ s/\n\s+/\t/mg;=0A= $header =3D~ s/^[^:]*:\s*\n//mg;=0A= my $pra;=0A= if ($header =3D~ /^Resent-Sender: *(.+)/mi) {=0A= $pra =3D $1;=0A= return ($pra) if ($` !~ /^Resent-From: = *(.+)(.|\n)*?^(Received|Return-Path):/mi);=0A= }=0A= if ($header =3D~ /^Resent-From: *(.+)/mi) {=0A= return ($1);=0A= } elsif ($header =3D~ /^Sender: *(.+)/mi) {=0A= $pra =3D $1;=0A= if (($header =3D~ s/^Sender: *(.+)//mgi) > 1) {=0A= return undef;=0A= } else {=0A= return ($pra);=0A= }=0A= } elsif ($header !~ /^From: *(.+)/mi) {=0A= return undef;=0A= } else {=0A= return ($1);=0A= }=0A= }=0A= }=0A= =0A= my $header_file =3D $ARGV[0] or die "Usage: $0 ";=0A= =0A= if (open (HEADERS, $header_file)) {=0A= $header .=3D $_ while ();=0A= close (HEADERS);=0A= } else {=0A= die "Cannot open $header_file!\n";=0A= }=0A= =0A= if ($pra =3D gimme_pra ($header)) {=0A= print "PRA: $pra\n";=0A= }=0A= =0A= exit 0; ------=_NextPart_000_0683_01C48BC6.58265870-- From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 18:13: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 SAA19466 for ; Thu, 26 Aug 2004 18:13: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 i7QLshlZ043918; Thu, 26 Aug 2004 14:54:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QLshs3043917; Thu, 26 Aug 2004 14:54:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLsgZb043911 for ; Thu, 26 Aug 2004 14:54:42 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7QLsj77031420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 26 Aug 2004 17:54:46 -0400 Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ From: Mark Shewmaker To: IETF MARID WG In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02BEBDB2@cliff.bai.org> References: <792DE28E91F6EA42B4663AE761C41C2A02BEBDB2@cliff.bai.org> Content-Type: text/plain Message-Id: <1093557382.2386.2127.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 26 Aug 2004 17:56:22 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Thu, 26 Aug 2004 17:54:46 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-26 at 14:24, Ryan Malayter wrote: > [wayne] > > The possibility that requiring every single user of qmail to get a > > signed license from Microsoft is a reason for concern. > > IANAL, but it is quite clear to me that the MS license requires nothing > of the sort: IANAL also, but to me it looks like the qmail users, (or at least the admins installing qmail), *would* have to sign Microsoft's license. Section 2.1 grants signatories the right to "make" object code versions of implementations. It also grants them the right to "use" the object code versions they made. Since section 2.1 specifically separates the notion of a right to "make" an object code version from the right to "use" an object code version, to me that implies that you can't assume that just because you've got one right that you've also got the other. > "Your End Users may use the Licensed Implementations licensed ^^^ > in this section 2.2 or in section 2.1 that they receive directly or > indirectly from You without executing this Agreement. In the section you quoted, they grant End Users a "use" right without any mention of a right to "make" object code. I can only conclude that End Users aren't allowed to compile source code implementations into object code, but that they are allowed to use the source code if such use doesn't require compilation. So bash scripts are okay, but qmail is right out, as are source RPMS, perl scripts (as perl creates temporary object code), and python scripts (as python not only compiles code into object files, but saves the object code in .pyc files). Furthermore, not only could End Users not install qmail, they also couldn't install source distributions such as gentoo and the various BSDs, if those distributions were to incorporate SenderID. And heaven help us if anyone out there considers sendmail.cf to be object code, as then the license wouldn't even allow an End User to trigger the m4-generation of a SenderID-supporting sendmail.cf. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 18:23: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 SAA20660 for ; Thu, 26 Aug 2004 18:23: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 i7QM0pHo044224; Thu, 26 Aug 2004 15:00: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 i7QM0ppr044223; Thu, 26 Aug 2004 15:00: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 i7QM0oBf044217 for ; Thu, 26 Aug 2004 15:00: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 EAFAF414E0; Thu, 26 Aug 2004 15:00:55 -0700 (PDT) Subject: RE: TECH OMISSION: Stronger checks against email forgery From: Douglas Otis To: Jim Lyon Cc: John Glube , IETF MARID WG In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAC52@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAC52@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1093557654.4552.242.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 26 Aug 2004 15:00:54 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-26 at 11:27, Jim Lyon wrote: > John points out that a forger can defeat SenderID checks by inserting a > Resent-From (or similar) header that references either himself a domain > that hasn't published a SenderID record. > > He goes on to suggest possible ameliorations, including EHLO checks > and/or classic SPF checks using MAIL-FROM. > > He's right that there's a potential problem, but I think he got the > wrong amelioration. > > If there's consensus that a change is required, I would recommend: > > Whenever the PRA is not equal to the 2822 "From", and the SenderID > result is anything other than "pass", and at least 6 months have elapsed > since SenderID became a Proposed Standard, then the message SHOULD be > treated as forged. The reference could be from any domain that provides an "open-ended" record. The referenced record could be from a "throw-away" domain as a means to still spoof _ANY_ RFC2822 From Mailbox Domain. As checks become more stringent, more domains may be tempted to publish "+all" records to quell picayune refusals. Reputation services will become inundated and ineffectual due to lack of Sender-ID identity authentication. Will Sender-ID really force the world to publish highly problematic records as pertaining to reputation services? > Reasons for this proposal: > > 1. For most instances of personal mail, PRA == 2822 From == bounce > address, and none of these issues apply. They only apply in the cases > of specialized agents like forwarders, list servers, third-party mailers > and similar. Sender-ID will likely invite such assumptions to change. From providers dealing with customers expecting to send mail from their networks, the norm could easily become inclusion of the Resent-From header. This "every field is the same" model does not fit for large amounts mail and will impose exceptional problems for most domains to confront. > 2. It's reasonable to hold specialized agents to a higher standard than > the rest of the E/Mail community (by requiring a "pass" instead of > merely the absence of a "fail", for instance.) This could create a deployment reaction of having Resent-From included routinely to ameliorate a long list of potential problems. Once that becomes the norm, EHLO authentication and authorization would then provide the same identity. If one were to follow this logic of all fields are normally the same, only authenticating and confirming authorization of the EHLO domain arrives at the same identity with much less chance of this identity being spoofed! > 3. When the set of documents hits Proposed Standard, many of the > legitimate specialized agents won't yet be in compliance. But as a > whole, it's a well-managed community that can move fairly quickly. How will they move? Where are we going and why are we in this hand-basket? : ) Will they re-train their customers or add a Resent-From? > Reasons against EHLO or bounce address: > > 1. EHLO tells you a name for the sending MTA. But it gives you no idea > whether that MTA is authorized to act on behalf of the name mentioned in > the message he's sending. It seems therefore to be irrelevant. Seems irrelevant? There you go, blaming the message rather than the messenger. : ) It is a matter of first establishing accountability. The assumptions used to validate a Sender-ID identity will not allow the Sender-ID identity to be held accountable. A simple scheme to impose a Mail Channel prescription upon either the RFC2821 MAIL FROM or the RFC2822 From is illustrated in this draft: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt Accountability is established first, and this scales well for then prescribing the Mail Channel. The use of the prescription is for authorization, never authentication. > 2. bounce address tells you who wants to know if the message isn't > delivered. It's also irrelevant when deciding whether the MTA is > authorized to act of behalf of the name mentioned in the message he's > sending. By also allowing a Mail Channel prescription for the MAIL FROM Mailbox Domain would curtail bounce traffic. The use of reputation services can not abate this type of traffic. Again, I refer you back to the MPR draft as how this type of restriction can be imposed while not requiring sequential DNS lookups. -Doug > -- Jim Lyon > mailto:JimLyon@Microsoft.Com > tel:+1-425-706-0867 > > Internet commerce will never really take off until you can buy something > online without getting spammed by the vendor. > > > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of John Glube > Sent: Tuesday, August 24, 2004 10:51 PM > To: 'IETF MARID WG' > Subject: TECH OMISSION: Stronger checks against email forgery > > > > It is very easy to forge domain information in email. > > Two simple cases: > > * Forging the SMTP mail from address; and > > * Inserting a false received line or resent-from header. > > In essence this involves using someone else's domain without > consent. > > Also, many who forge domain information also apparently send > direct from an IP address to the recipient's mail server. > > Shouldn't we have stronger checks to prevent these types of > activities? > > One approach is to run a mail from check at the data stage using > the SPF record format and test protocol. > > Another is to run an ehelo or helo check using client smtp > validation. > > Keep in mind those engaged in email forgery (which for > sophisticated operators is a form of criminal fraud) will likely > adopt approaches to muddy and defeat authentication, so that > those engaged in fighting email forgery will need to use a range > of tools, recognizing that although one data set might be > corrupted, matching of data against a number of identifiers will > likely generate better results. > > (I am basing these general comments on existing research and > studies carried out by others in the criminal forensics field.) > > Amending the Sender-ID drafts to reflect using a number of > data sets is one option. > > My personal recommendation is that a best current practices > document be published concurrently with any authentication > technologies recommended by this WG which would in essence > recommend receivers run PRA checks using Sender-ID: > Authenticating Email, mail from checks using the SPF record > format and test protocol and ehelo/helo checks using client > smtp validation. > > It may also be appropriate to establish a steering group to > review and propose document updates on a regular basis, although > there may be other ad hoc groups which could include this process > within their mandate. > > 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.737 / Virus Database: 491 - Release Date: 11/08/2004 > > > From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 18:58: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 SAA22597 for ; Thu, 26 Aug 2004 18:58: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 i7QMdEcS046537; Thu, 26 Aug 2004 15:39:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QMdEko046536; Thu, 26 Aug 2004 15:39:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QMdDXU046530 for ; Thu, 26 Aug 2004 15:39:14 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 15:39:18 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 15:39:17 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 15:39:18 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 15:39:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: DNS Record Types Date: Thu, 26 Aug 2004 15:39:13 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAD6B@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: DNS Record Types Thread-Index: AcSLm9LYFUV58RshTT6rWAB7pNpL6gAH1hsA From: "Jim Lyon" To: "Dave Crocker" , "IETF MARID WG" X-OriginalArrivalTime: 26 Aug 2004 22:39:23.0474 (UTC) FILETIME=[88E0F320:01C48BBD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QMdEXU046531 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dave Crocker wrote (regard whether one MAY, SHOULD or MUST publish a TXT record): > If there were a problem with publishing the new record type, that [not > requiring a TXT record] would be a significant barrier. Unless there > is a claim that publishing such data is highly problematic, then requiring > the long-term record type to be used seems to make sense. For many of us, there *IS* a problem with publishing the new record type, and it *IS* a significant barrier. There *IS* a claim that publishing a new record type is highly problematic. As has been repeatedly discussed: 1. Microsoft DNS server (all currently deployed versions) cannot publish the new record type. (Exception: some can, but only if they received the data via a zone transfer and have not been restarted since receiving it. If you attempt to restart them after receiving the unknown record type, startup fails.) 2. The DNS resolver APIs on all Microsoft OS's don't let you query for an unknown record type. 3. Even if you write your own DNS resolver code, if you're behind a firewall created by Microsoft ISA Server, you usually can't successfully send and receive a query for a new record type. I can't speak for other name servers, resolvers or firewalls, but I believe that the above is a substantial enough segment of the population to constitute a significant barrier. Dave also says: > Looking at the other side of this, making publishing in a TXT record be > a SHOULD means that there is a long-term requirement for support, > whereas the intention is to use it for the near-term. Perhaps the disagreement has to do with a difference in time-scales. Assuming that Microsoft set out to change (1) through (3) above (and it hasn't), then it would probably be 3 years from start of design until a non-beta product became available. It's probably another 2 years for 50% adoption, or another 5 to 10 years for 90% adoption. Putting it all together, "short-term" lasts somewhere between 5 and 13 years from when Microsoft starts to fix their DNS stuff. Given that the IETF standards process, slow as it is, is much faster than this, it makes sense to mandate the short-term behavior today, and to revisit the issue once the motivation for the short-term behavior has passed. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 19: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 TAA23555 for ; Thu, 26 Aug 2004 19:16:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QMpGSL047195; Thu, 26 Aug 2004 15:51: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 i7QMpGrq047194; Thu, 26 Aug 2004 15:51:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QMpDdT047182 for ; Thu, 26 Aug 2004 15:51:15 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Date: Thu, 26 Aug 2004 17:51:13 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02BEBE4C@cliff.bai.org> Thread-Topic: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ thread-index: AcSLt6R/OawZaP1KTYKac+smArCaVwABDu+A From: "Ryan Malayter" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QMpFdT047189 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Mark Shewmaker] >In the section you quoted, they grant End Users a "use" right without >any mention of a right to "make" object code. Huh? How do you use a source code implementation, except as to run it in interpreted fashion or build it? I think you're reaching. The separation of source code versus object code sections in the license seems to be made so that one form (source) requires a statement of IP ownership be attached, while the other (object) does not. Microsoft's license FAQ says basically the same thing: only when you implement their IP do you need a license, not to use a licensed implementation. I have a tentative agreement for an *independent* (niether MS nor FSF) IP lawyer friend confirm these issues for me on a pro-bono basis. I will let everyone know what he says, or if he tells me I'm going to have to pay up because analyzing these four pages (the MS license in combination with the GPL) turns out to be too much work to do for free ;-). Regards, Ryan From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 19:19: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 TAA23799 for ; Thu, 26 Aug 2004 19:19: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 i7QMua3L047615; Thu, 26 Aug 2004 15:56: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 i7QMuade047614; Thu, 26 Aug 2004 15:56: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 (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QMuZ6S047608 for ; Thu, 26 Aug 2004 15:56:35 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Aug 2004 15:56:40 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 2004 15:56:39 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Aug 2004 15:56:40 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 15:56:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY - IP, HELO & touch count. DOC-BUG too. Date: Thu, 26 Aug 2004 15:56:35 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAD7B@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY - IP, HELO & touch count. DOC-BUG too. Thread-Index: AcSLrEUvrgte5MZ0SOqtPHHJ4j9oiwAEX30w From: "Jim Lyon" To: "Douglas Otis" Cc: "Matthew Elvey" , "MXCOMP" X-OriginalArrivalTime: 26 Aug 2004 22:56:41.0953 (UTC) FILETIME=[F3DC4510:01C48BBF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QMuZ6S047609 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, August 26, 2004 at 1:35 PM, Doug Otis wrote about the authentication and authorization aspects of SenderID, compared to schemes involving EHLO. After much thinking, I realized that our disagreements have to do with confusions about how the two schemes treat identity, authentication and authorization. Sender-ID: Identity: The identity of a sending MTA is its IP address. Authentication: There is no authentication other than that implicit in the TCP/IP stack. Because in practice you can't perform an SMTP transaction without being able to receive packets destined to the IP address, this works well. (Yes, I know about TCP/IP spoofing attacks, but they're impractical for sending bulk e-mail.) Authorization: The SenderID test determines whether the sending MTA is authorized to send mail that claims to come from a particular domain. This authorization can only be bestowed by the domain that the mail claims to come from. EHLO-based schemes: Identity: The identity of a sending MTA is its EHLO name. Authentication: Various scheme to determine whether the EHLO name that an SMTP client sent is true. Authorization: Depending on the scheme, there might be none. Otherwise, there might be a scheme to determine whether the sending MTA is authorized by its domain owner to be an SMTP client. There is no authorization of individual messages. The SenderID series of documents is based on an explicit decision to pursue the first world-view; the fact that it doesn't do the second is not a bug. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 19:20: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 TAA23859 for ; Thu, 26 Aug 2004 19:20: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 i7QMx2qP047878; Thu, 26 Aug 2004 15:59: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 i7QMx2m1047870; Thu, 26 Aug 2004 15:59:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QMwvqC047784 for ; Thu, 26 Aug 2004 15:58:57 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7QN75n4009458; Thu, 26 Aug 2004 16:07:05 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7QN75QF009455; Thu, 26 Aug 2004 16:07:05 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 Aug 2004 16:07:05 -0700 (PDT) From: "william(at)elan.net" To: Mark Lentczner cc: IETF MARID WG Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 Aug 2004, Mark Lentczner wrote: > 2) Wildcards > All the major points about wildcards have been made: Essentially, they > don't work the way you'd like them to whether or not there is a prefix > -- it is the nature of DNS wildcards. > > On the other hand, if a domain uses wildcard MX records, then wildcard > TXT and/or SPF2 records can be used to achieve a matching effect. See > the protocol-03 draft for an example and discussion of just this point. > I will only add here that publishing under a prefix or not makes no > difference - the use of wildcards has the same caveats and > difficulties. I disagree that publishing under prefix makes no difference as to workability of wildcards. As noted wildcards can be used to extend spf policy to all subdomains under example.com which are not specifically defined as separate records in dns, i.e.: a.example.com. IN TXT "v=spf1 ip4:192.168.0.0/16 ~all" *.example.com. IN TXT "v=spf1 ip4:10.0.0.0/8 ~all" will apply to b.example.com and c.example.com and d.example.com, etc but not to a.example.com which has its own record In case we decide to have main record be located within subdomain prefix depending on the identity, then in order to achieve same effect with wildcards, we'd still have to place the record in root of the domain, i.e. a._marid_pra.example.com. IN TXT "v=spf1 ip4:192.168.0.0/16 ~all" *.example.com. IN TXT "v=spf1 ip4:10.0.0.0/8 ~all" In this case wildcard record will apply to b._marid_pra.example.com and c._marid_pra.example.com, etc but not to a._marid_pra.example.com. But at the same time here the record from the wildcard (i.e. 10.0.0.0/8) will also apply to a._spf_mfrom.example.com. eventhough this might be different identity and while for specific record we can do: a._marid_pra.example.com. IN TXT "v=spf1 ip4:192.168.0.0/16 ~all" b._spf_mfrom.example.com. IN TXT "v=spf1 ip4:192.168.10.0/24 ~all" The same can not be done for wildcard records as there identity you only have one place to put such record and it would have to be same for any kind of identity (even ones not yet defined...). In my view this makes wildcards are bad choice for achieving scoping and identity separation. That is unless we decide that we don't need to support wildcards at all and in that case to avoid problems (as some will still do it seeing how its possiblems), the document would have to specifically say that you CAN NOT use wildcards or CAN NOT place records in anything but the specified scope/identity prefix. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 19:31: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 TAA24405 for ; Thu, 26 Aug 2004 19:31: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 i7QNAo4j048565; Thu, 26 Aug 2004 16: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 i7QNAoSE048564; Thu, 26 Aug 2004 16:10: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 i7QNAo8T048556 for ; Thu, 26 Aug 2004 16:10:50 -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 i7QNAtY25603; Thu, 26 Aug 2004 16:10:55 -0700 Date: Thu, 26 Aug 2004 16:10:50 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <92686983.20040826161050@brandenburg.com> To: "Jim Lyon" CC: "IETF MARID WG" Subject: Re: DEPLOY: DNS Record Types In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAD6B@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAD6B@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> 1. Microsoft DNS server (all currently deployed versions) cannot publish ... JL> 2. The DNS resolver APIs on all Microsoft OS's don't let you query for I did recall that there were problems on the client side. So the thought is to make the record available, but realize that it will only get queried as clients get more capable. In any event, having a specification that contains no "MUST" strikes me as odd, since there is no identifiable core of functionality that is guaranteed to be implemented. Such a guarantee is usually the basis for IETF protocols being assured to work. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 19:31: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 TAA24413 for ; Thu, 26 Aug 2004 19:31: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 i7QNAjET048540; Thu, 26 Aug 2004 16:10: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 i7QNAjbD048539; Thu, 26 Aug 2004 16:10: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 i7QNAiLs048533 for ; Thu, 26 Aug 2004 16:10: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 i7QNJ2Iv009724; Thu, 26 Aug 2004 16:19:02 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7QNJ29i009721; Thu, 26 Aug 2004 16:19:02 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 Aug 2004 16:19:02 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: Rand Wacker , Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAD36@df-fido-msg.exchange.corp.microsoft.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, 26 Aug 2004, Jim Lyon wrote: > In this thread, Rand points out that complicated domains may wish to > publish both SPF1 and SPF2 records, and that this effectively cuts their > maximum record size in half (if they want to fit into a DNS UDP packet, > which they do). He also points out than these are exactly the domains > that may be pushing the DNS UDP size limits. > > While this is an issue, there's a trivially easy workaround: For your > domain, publish very short SPF1 and SPF2 records, that just contain > "REDIRECT=subdomain". If your SPF1 and SPF2 data are identical, they > can both refer to the same subdomain; if your SPF1 and SPF2 data differ, > they can refer to different subdomains. > Problem solved. Actually no, its not. The problem is that because you enter scope identity as part of SPF version string, you simple can not refer from one type of SPF record to another. So for example if we have example.com. IN TXT "v=spf1 ip4:10.0.0.0/8 -all" example.com. IN TXT "spf2.0/pra ip4:10.0.0.0/8 -all" And assuming that ip4 was to be a lot larger set of records and as Jim suggested we would want to do it as: example.com. IN TXT "v=spf1 redirect=_spf.%{d}" example.com. IN TXT "spf2.0/pra redirect=_spf.%{d}" And you want to refer them to same record _spf.example.com and publish it as: _spf.example.com. IN TXT "spf2.0/pra ip4:10.0.0.0/8 -all" Then the problem is that SPF1 clients will not see since for then only valid SPF records are the ones that start with "v=SPF1". And similarly if it is published as: _spf.example.com. IN TXT "v=spf1 ip4:10.0.0.0/8 -all" Then its clients looking for PRA that will not see it since MARID draft specifies that all MARID TXT records should start with "spf2.0/pra". This is fundamental problem with current scoping syntax that one type of identity record can not refer to another type of identity record causing necessity to completely duplicate the data in case its the same. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 19:38:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24899 for ; Thu, 26 Aug 2004 19: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 i7QNKOdj049284; Thu, 26 Aug 2004 16: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 i7QNKOoJ049283; Thu, 26 Aug 2004 16:20:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QNKO1d049269 for ; Thu, 26 Aug 2004 16:20:24 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so366173rnk for ; Thu, 26 Aug 2004 16:20:16 -0700 (PDT) Received: by 10.38.171.20 with SMTP id t20mr2767648rne; Thu, 26 Aug 2004 16:20:15 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Thu, 26 Aug 2004 16:20:15 -0700 (PDT) Message-ID: <94df60cf0408261620bba39b5@mail.gmail.com> Date: Thu, 26 Aug 2004 19:20:15 -0400 From: Reply-To: To: Jim Lyon Subject: Re: DEPLOY: Legal liability for creating bounces from forgedmessages Cc: MARID In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAD2B@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <81AC085044D04B429F5FB883D94FA1AF8FAD2B@df-fido-msg.exchange.corp.microsoft.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 14:25:21 -0700, Jim Lyon wrote: > > Mark Shewmaker point out that if you have an SMTP transaction for which > *all* of the following are true: > > 1. The sender didn't use SUBMITTER, and > 2. There is more than one recipient, and > 3. The SenderID test fails, and > 4. Your MTA implements a per-user white list for SenderID failures, and > 5. At least one recipient white-listed the PRA, and > 6. At least one other recipient didn't white-list the PRA, and > 7. You feel it's immoral to silently discard forged mail > > then you need to generate a bounce (instead of rejecting a message). > > He's right. But it's such a corner case that I'm not worried. This > should be a very small fraction of the mail, and won't generate very > many bounces at all. In my experience (which might not be typical, as I'm in a computer science department), this case is actually fairly common. In all of the university environments I'm familiar with, different people have very different opinions about how they want spam filtered. It's also the case that mail to certain addresses--especially mailing lists--is filtered more stringently, and mail to other addresses--particularly addresses to which users report bugs--is filtered far less aggressively if at all (so as not to reject bug reports about mail). Now two things: 1. A significant fraction of the spam I get seems to have been sent to more than one user at the same host. 2. I don't think it's immoral to discard mail silently, but I think it's highly problematic (having on occasion lost a very important piece of mail). It might be immoral to bounce mail to a forged address, but a lot of people do it anyway because they fear losing one important message silently. In fact, I have to say I am guilty of this, though I try to reject most of my mail in response to the SMTP RCPT command, not after the fact. SPFv1 is one tool that allows me to do this. That said, I actually don't agree that you need to generate a bounce when your cases 1-7 exist. The alternative, when you have multiple recipients with different policies, is to reject all but the first RCPT command with a 4xx error code, With typical SMTP clients, this has the unfortunate side effect of delaying mail for some recipients for (typically) tens of minutes. But, if we are talking about extending RFC2821 anyway with things like SUBMITTER, one might consider some kind of error code that means "send a separate copy of message to this recipient immediately." David P.S., On a related note, I sent a detailed message from my nyu.edu address to the list with some questions/concerns about the implications of the MS license for projects in academia. That message appears to have been silently discarded! Is this possible? This is exactly why I hate silently discarded mail... I don't know whether to try re-sending from my gmail account or not. From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 19:38:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24900 for ; Thu, 26 Aug 2004 19:38: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 i7QNI3dG049110; Thu, 26 Aug 2004 16:18:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QNI3Iv049109; Thu, 26 Aug 2004 16:18:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QNI2RL049102 for ; Thu, 26 Aug 2004 16:18:03 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7QNI677001145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 26 Aug 2004 19:18:07 -0400 Subject: RE: TECH-OMISSION: Legal liability for creating bounces from forgedmessages From: Mark Shewmaker To: MARID In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAD2B@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAD2B@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1093562383.2381.2292.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 26 Aug 2004 19:19:43 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Thu, 26 Aug 2004 19:18:08 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-26 at 17:25, Jim Lyon wrote: > Mark Shewmaker point out that if you have an SMTP transaction for which > *all* of the following are true: > > 1. The sender didn't use SUBMITTER, and > 2. There is more than one recipient, and > 3. The SenderID test fails, and > 4. Your MTA implements a per-user white list for SenderID failures, and > 5. At least one recipient white-listed the PRA, and > 6. At least one other recipient didn't white-list the PRA, and > 7. You feel it's immoral to silently discard forged mail > > then you need to generate a bounce (instead of rejecting a message). You restated that really, really well. > He's right. But it's such a corner case that I'm not worried. This > should be a very small fraction of the mail, and won't generate very > many bounces at all. Perhaps it's a corner case in legitimate mail, but legitimate mail is not my main concern; I'm more worried about from the standpoint of it opening up an exploitable vulnerability, and two problems that can result from spammers exploiting that vulnerability: 1. Spammers will get their bounce message spams to a bunch of victims, using the exploited machine. (Any individual victim's machine could of course avoid this threat by implementing SES.) 2. The exploited machine will become known as a source of bounce spam, and be added to domain-based blocklists. (1) is bad in and of itself, but (2) means that if someone doesn't like you or your machine, that they'll be able to get you black-listed. The only way to solve this problem would be to allow for an override of the must-accept-100-recipients requirement in RFC 2821. You can't completely avoid this problem through the addition of classic-SPF test, and you can't completely avoid it with SES, (though the recipients could.) And that was the point of my email that you responded to: The only way to completely avoid this blow back vulnerability that shows up in the no-SUBMITTER case, (other than silently dropping the email), is to give a transient "too many recipients" error upon the first recipient with a differing PRA white-list, if you haven't verified that the Return Path is legitimate. (If you have positively verified the bounce address with Classic-SPF, or with any other method of positive verification, then obviously you can safely bounce any messages and thus would have no need to limit the number of recipients in an attempt to avoid this vulnerability.) -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 20: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 UAA26906 for ; Thu, 26 Aug 2004 20: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 i7QNtXoi051560; Thu, 26 Aug 2004 16:55:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QNtXRk051559; Thu, 26 Aug 2004 16:55:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QNtWYB051553 for ; Thu, 26 Aug 2004 16:55:32 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7R03rro010844; Thu, 26 Aug 2004 17:03:53 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7R03r8W010841; Thu, 26 Aug 2004 17:03:53 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 Aug 2004 17:03:53 -0700 (PDT) From: "william(at)elan.net" To: Mark Lentczner cc: IETF MARID WG Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 Aug 2004, Mark Lentczner wrote: > 3) Incorporating scope into the record format > Several schemes have been proposed on this list for incorporating > scoping into the protocol syntax. I will summarize them here: > > 3a) Put scopes in the field > Proposed by Wayne in > http://www.imc.org/ietf-mxcomp/mail-archive/msg03441.html > This scheme replaces the "/pra" and field in the version > string with a list of scopes. For example: "spf2.0/pra,mailfrom" or > "spf2.0/mailfrom". It applies to the whole record, so it only helps > domains with very large records if their v=spf1 and spf2.0/pra records > are otherwise the same. If the above two large records were the same, > this would look like: > > example.com. IN TXT "spf2.0/pra,mailfrom ... some very > long record here ..." > > If the large records are different, they'd still have to resort to the > method presented in (1) above. > > 3b) Add a scope macro %{e} > Originally in the Unified-SPF concept, but recently proposed by Meng > in http://www.imc.org/ietf-mxcomp/mail-archive/msg03663.html > This scheme adds a macro that is replaced with the identifier for the > scope being checked: "pra" or "mailfrom". It can be used with the > include: mechanism or redirect= modifier to incorporate different parts > into mostly common record: > > example.com. IN TXT "spf2.0/pra ...common... > redirect=_%{e}.%{d}" > _pra.example.com. IN TXT "spf2.0/pra ... pra only stuff ..." > _mailfrom.example.com. IN TXT "spf2.0/pra ... mailfrom only stuff > ..." > > If the common mechanisms work, then only one DNS query needs to be > done. Otherwise, this basically devolves into the method presented in > (1) above. > > 3c) Add a scope modifier > Variations discussed in the past, recently proposed by William in > http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html > This scheme adds a modifier that alters the applicable scope for the > following mechanisms until the next scope modifier. For the big > company case, this is only a help if bulk of the records for PRA and > MAILFROM are the same, and the common, plus all the difference, plus > the overhead of the scope modifier still fit in one record: > > example.com. IN TXT "v=spf1 ... mailfrom only stuff ... " > "sc=pm ...common... " > "sc=m -all " > "sc=p ... pra only stuff ..." > > If it doesn't fit, then it devolves into the method presented in (1) > above. > > This idea has several structural problems: Modifiers would have to be > substantially reworked to achieve this "environment variable" like > behavior. The current document doesn't support such modifiers. Also, > this scheme has several important subtle restrictions to achieve > backward compatibility with existing SPF systems. I disagree about "substantially reworked" part. Its true that currently there are no modifiers that work like as enviroment variable, but creating is not that hard or at least not any harder to write down in draft document then any other scoping description. Implementing it is pretty easy too, all programming languages allow for local and global variables and spf scope is likely to be global variable for the library doing spf record processing anyway. > 3-Summary) > For sites where records for Sender-ID and SPF are large, similar though > not the same, none of these methods is a win over the method in (1). Not quite. If records for different identies are 100% different and both are very large, then method in (1) is the only way of not overruning DNS UDP record limit. And I want to point out too that if records are so large as not not fit one record, you'd have to split it among two or more record by using include or redirect anyway. At the same time if records are large but contain primarily shared/same portion the in 3c you can have this shared portion as part of the main and if differences are small, the total would not overrun UDP limit. > For sites with small, similar records, only (3c) has any advantage over (1). That would be for "large, similar records", see above. For small similar records its also true, though there you can just enter records side-side and not worry about overrunning UDP limit (although I personally think that is bad and duplication should be avoided if possible). > For sites where the records are the same (claimed by many to be > the vast majority of sites), (3a) is the biggest win. 3(c) offers exactly same advantages and disadvantages as 3(a) if records are the same (and with shortered scoping names, its even smaller is size) example.com. IN TXT "spf2.0/pra,mailfrom ... some very long record" vs example.com. IN TXT "v=spf1 sc=pm ... some very long record" ------- I want to point out another important point for comparing different record formats that originally caused new spf version string to be incorporated into current version of MARID documents. That is if we want separate MARID PRA identity in record format in such a way that current base of SPF record do not apply so as not to create confusion for different clients. In case of 3(a) this is true as we have new version string (same as has been achieved now), however to support this new version with mailfrom identity ALL existing SPF records would have to be republished and duplicated (so that both SPF1 and SPF2 clients can see them). In case of 3(b) if main SPF version stays the same "v=SPF1" and record is the same for different identities, then and MARID-aware client can not tell the difference between that being origional SPF1 record that was never supposed to apply for MARID and record that is shared between MARID PRA and Mail-From identities, so original goal is not meat. However if we do change version string, then we have same problem as what I described above where existing SPF base has to publish both new version records and old SPF1 records for compatibility with different clients. In case of 3(c) the objective is meat because if there is no scope modifier then client can assume to be old not-yet updated SPF1 record that applies only to mail-from identity. At the same time when domain owner does update the record to support both mail-from and pra, he would not have to duplicate the mail-from part of the record to support both old spf1 and new spf2 clients (as is likely the case with 3a and 3b). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 20: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 UAA27085 for ; Thu, 26 Aug 2004 20:26: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 i7R06qNX052206; Thu, 26 Aug 2004 17:06: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 i7R06q2f052205; Thu, 26 Aug 2004 17:06: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 i7R06qt5052197 for ; Thu, 26 Aug 2004 17:06:52 -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 F0414414D9; Thu, 26 Aug 2004 17:06:57 -0700 (PDT) Subject: RE: DEPLOY - IP, HELO & touch count. DOC-BUG too. From: Douglas Otis To: Jim Lyon Cc: Matthew Elvey , MXCOMP In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAD7B@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAD7B@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1093565216.4552.369.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 26 Aug 2004 17:06:56 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-26 at 15:56, Jim Lyon wrote: > On Thursday, August 26, 2004 at 1:35 PM, Doug Otis wrote about the > authentication and authorization aspects of SenderID, compared to > schemes involving EHLO. > > After much thinking, I realized that our disagreements have to do with > confusions about how the two schemes treat identity, authentication and > authorization. > > > Sender-ID: > > Identity: The identity of a sending MTA is its IP address. > > Authentication: There is no authentication other than that implicit in > the TCP/IP stack. Because in practice you can't perform an SMTP > transaction without being able to receive packets destined to the IP > address, this works well. (Yes, I know about TCP/IP spoofing attacks, > but they're impractical for sending bulk e-mail.) > > Authorization: The SenderID test determines whether the sending MTA is > authorized to send mail that claims to come from a particular domain. > This authorization can only be bestowed by the domain that the mail > claims to come from. The Identity being authorized is the PRA Mailbox Domain by way of reference to a Mail Channel prescription of IP addresses. This PRA Mailbox is the Identity the draft hopes exposed to the user. The Mailbox Domain has not been authenticated, only authorized as the Mail Channel will not safely permit such conclusion. The domain administratively accountable for the MTA remains anonymous beyond the IP address. There is no identity authenticated through this relationship unless you wish to claim some significance with the MTA IP address. If there is a problem, what identity will the user report? If there is a problem, what identity will the MTA/MUA filter or reject? In each case, the PRA Mailbox Domain is the identity affected. The problem is that this identity has not been authenticated, but the authenticated MTA IP address is ignored. > EHLO-based schemes: > > Identity: The identity of a sending MTA is its EHLO name. > > Authentication: Various scheme to determine whether the EHLO name that > an SMTP client sent is true. The goal of CSV is to ensure a consistent and simple scheme authenticates and verifies MTA authorization. The identity is the EHLO domain as the message broker. This authenticated identity can be held accountable. The Sender-ID identity as represented by the PRA Mailbox Domain has not been authenticated as this requires unverifiable assumptions made with respect to Mail Channel. Bug. > Authorization: Depending on the scheme, there might be none. > Otherwise, there might be a scheme to determine whether the sending MTA > is authorized by its domain owner to be an SMTP client. There is no > authorization of individual messages. As I said, CSV provides both MTA authentication and authorization. This was the goal of the MARID charter. : ) > The SenderID series of documents is based on an explicit decision to > pursue the first world-view; the fact that it doesn't do the second is > not a bug. Not authenticating the identity you wish everyone to hold accountable is a bug in this logic. By allowing an "open-ended" record to exist, this process becomes an exercise in futility, as not even the IP address of the otherwise anonymous MTA is checked. Such "open-ended" records leave open the door for endless spoofing. Sender-ID's false assumptions of identity trustworthiness will ensure great potential for harm. : ( -Doug From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 20:28:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27162 for ; Thu, 26 Aug 2004 20:28:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R03m6n051960; Thu, 26 Aug 2004 17:03: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 i7R03mxB051959; Thu, 26 Aug 2004 17:03:48 -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 i7R03iMk051952 for ; Thu, 26 Aug 2004 17:03:44 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C0UDZ-0003Lu-00 for ; Fri, 27 Aug 2004 02:03:49 +0200 Received: from 212.82.251.34 ([212.82.251.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Aug 2004 02:03:45 +0200 Received: from nobody by 212.82.251.34 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Aug 2004 02:03:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Fri, 27 Aug 2004 01:59:11 +0200 Organization: Lines: 44 Message-ID: <412E794F.3135@xyzzy.claranet.de> References: <011e01c48b92$d2081e50$6c62fea9@ibmrkydk2ufvdd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.34 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: > example.com. IN TXT "v=spf1 redirect=_spf1.%{d}" > example.com. IN TXT "spf2.0/pra redirect=_spf2.%{d}" > _spf1.example.com. IN TXT "v=spf1 ... some very long [...]" > _spf2.example.com. IN TXT "spf2.0/pra some different [...]" Nice idea. [wildcards] > See the protocol-03 draft for an example and discussion of > just this point. Where can I get protocol-03 ? > 3-Summary) > For sites where records for Sender-ID and SPF are large, > similar though not the same, none of these methods is a win > over the method in (1). True. > For sites where the records are the same (claimed by many to > be the vast majority of sites), (3a) is the biggest win. Looking at your summary (3b) could be more flexible than (3a), but (3a) is probably clearer. At the moment "SPF classic" and "SenderId / PRA" still use almost the same "protocol" (= format of the sender policy), although I'm not sure what results like UNKNOWN or SOFTFAIL _mean_ in conjuction with "SenderId / PRA". In fact I don't understand SOFTFAIL at all. But assuming that this is only my problem it would be nice to have _one_ format for the three kinds of sender policies: "SPF classic" (mailfrom) only, "SenderId / PRA" only, and both. Either (3a) or (3b) offer this feature. And in theory it's still possible to fix the PRA algorithm for compatibility with RfC 2476 (when an MSA "forgot" to add a Sender), or when a mailing list uses Errors-To instead of Sender. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 20:50: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 UAA28429 for ; Thu, 26 Aug 2004 20:50:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R0Tr4b054576; Thu, 26 Aug 2004 17:29: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 i7R0TrwS054575; Thu, 26 Aug 2004 17:29:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts36-srv.bellnexxia.net (tomts36.bellnexxia.net [209.226.175.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R0Tq5s054568 for ; Thu, 26 Aug 2004 17:29:52 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040827002957.ZNN25796.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 26 Aug 2004 20:29:57 -0400 From: "John Glube" To: "'Douglas Otis'" , "'Jim Lyon'" Cc: "'IETF MARID WG'" Subject: RE: TECH OMISSION: Stronger checks against email forgery Date: Thu, 26 Aug 2004 20:29:33 -0400 Message-ID: <013501c48bcc$ed6eb020$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <1093557654.4552.242.camel@ddev.mail-abuse.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7R0Tq5s054570 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In the interests of process, I am forwarding to the list a note I sent earlier today to the WG Chairs concerning the subject. The body of the note read as follows: >Andy, >I trust this note finds you and yours well. >This note is further to my two messages concerning the >subject found at: >http://www.imc.org/ietf-mxcomp/mail-archive/msg03597.html >http://www.imc.org/ietf-mxcomp/mail-archive/msg03615.html >Having reflected on matters, it seems best that we not >clutter the situation further at this stage with a best >current practice document, but rather allow the Sender-ID >drafts to proceed. >In my view the issue of a best current practice document >can be raised and dealt with once the Sender-ID drafts are >approved by the IETF MARID Working Group. >Once Sender-ID is approved by the WG, subject to proper >procedure the issue of a Best current practice document can >be raised and discussed at that time. The note had the following post script: >P.S. Although I am formally withdrawing my concerns, I do >not propose to send a formal message to the list, unless >you feel this is appropriate. I say this only as others may >wish to pursue the discussion further at this stage. Based on guidance received from Marshall to whom the note was copied, as the reader can see, I have sent the full message to the list. Why? The WG works by consensus. The WG Chairs can best gauge consensus from comments made to the public list. Accordingly, if the WG consensus is that a BCP is needed concerning the issues raised in the noted messages and these should be dealt with at this juncture instead of after Sender-ID approval then such is the proper course. 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.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 21:27:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00490 for ; Thu, 26 Aug 2004 21:27:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R15hZj056691; Thu, 26 Aug 2004 18:05: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 i7R15hWG056690; Thu, 26 Aug 2004 18:05:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R15god056683 for ; Thu, 26 Aug 2004 18:05:42 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7R1E4RJ013192; Thu, 26 Aug 2004 18:14:04 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7R1E4Jn013189; Thu, 26 Aug 2004 18:14:04 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 Aug 2004 18:14:03 -0700 (PDT) From: "william(at)elan.net" To: Carl Hutzler cc: IETF-MXCOMP Subject: Re: AOL's stance on SenderID and IPR issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd like to also hear how this license would impact Yahoo. It is my understanding that Yahoo is one of the largest (if not the largest) companies using Qmail and there have been substantial discussions on this list in the last day that license terms may not compatible with that at all. I don't know if there is anybody on this list who works for yahoo, but I know there is at least one person here who worked for it not long ago (for company recently aquired by it), possibly he knows right person at yahoo to ask or maybe somebody else does. On Thu, 26 Aug 2004, Carl Hutzler wrote: > Someone on the list asked me to post AOL's thoughts on the IPR/SenderID > thread... > > Our internal patent lawyer has reviewed the license agreement and said that > he found no IP issues and we are free to pursue a license to use it in our > infrastructure. > > The only issues I have seen on the lists likely do not apply to AOL: > > A) Sendmail redistrubutes/sells software - AOL does not sell MTAs other than > perhaps netscape iplanet. But I am not closely related to that team. > > B) Some have complained about the nuisance of applying for a license for > every "small organization" and potential costs of that. Folks really want a > GPL. While I understand this, AOL is not in this category and likely would > not see licensing this technology as an undue burden. > > That's the scoop from AOL land :-) > > -Carl From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 21:57: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 VAA02407 for ; Thu, 26 Aug 2004 21:57: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 i7R1caV0059028; Thu, 26 Aug 2004 18:38: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 i7R1ca3b059027; Thu, 26 Aug 2004 18:38:36 -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 i7R1cWBp058979 for ; Thu, 26 Aug 2004 18:38:33 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1C0VhG-00037b-4Y for ietf-mxcomp@imc.org; Thu, 26 Aug 2004 20:38:38 -0500 To: "IETF MARID WG" References: <792DE28E91F6EA42B4663AE761C41C2A02BEBDB2@cliff.bai.org> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 26 Aug 2004 20:34:27 -0500 In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02BEBDB2@cliff.bai.org> (Ryan Malayter's message of "Thu, 26 Aug 2004 13:24:23 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <792DE28E91F6EA42B4663AE761C41C2A02BEBDB2@cliff.bai.org> "Ryan Malayter" writes: > [wayne] >> The possibility that requiring every single user of qmail to get a >> signed license from Microsoft is a reason for concern. > > IANAL, but it is quite clear to me that the MS license requires nothing > of the sort: I think it would be really cool if you are right. A qmail patch is basically taking a hunk of source code and installing it into another program, possibliy modifying the patch code in order to make it work with the modified program. So, if I, as a small ISP or whatever, want to add SenderID functionality to a specialized program that I have, all I would need to do is take the qmail patch, modify it as needed to make it work with my specialized program, and not have to worry about a license. Or, at least not have to worry unless I decide to redistribute it. However, my gut feel says that MS has not intended such a thing. > So, a qmail pactch consisting of source code containing the PRA is a > source code implementation. Creators of such soruce code implementations > will need to sign the MS license to include PRA, but *users* do not. Can a qmail patch be a licensed implementation? I don't think so. In particular, take a look at section 2.2 again: 2.2 _Source_Code_Distribution_ You also have [...], a [...] license to distribute or otherwise disclose source code copies of such Licensed Implementation licensed in Section 2.1 only if You [....] This seems to say that a source code distribution can only be a Licensed Implementation if you can take the source code, compile it into object code and have a Licensed Implementation as per section 2.1. > The trademark requirement for what is considered a "licensed > implementation" seems a bit onerous. But it says NOTHING about it being > a "registered trademark", and mentions no jurisdictional requirements. > So make up a brand name for your qmail patch, and you have a trademark. Yeah, I agree, trademarks, are granted automatically. I raised the issue because it again points to my belief that MS is intending this license to be applyed to a classic software product, that functions and does something useful, not just random snip-its of code. I'm not even certain that a library that contains the PRA algorithm would qualify as a Licenced Product because you must implement all required parts of the SenderID specification. I believe that would include things like the SUBMITTER functionality, which may mean that you can only have MTAs as Licensed Products. I haven't thought about that part very hard though, take it with a grain of salt. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 22:05: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 WAA02760 for ; Thu, 26 Aug 2004 22:05:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1kVNC059985; Thu, 26 Aug 2004 18:46:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R1kVQ1059984; Thu, 26 Aug 2004 18:46:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1kVum059978 for ; Thu, 26 Aug 2004 18:46:31 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7R1srDw014326 for ; Thu, 26 Aug 2004 18:54:53 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7R1srco014323 for ; Thu, 26 Aug 2004 18:54:53 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 Aug 2004 18:54:53 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID WG Subject: TECH-ERROR: Duplication of version number as part of the name for SPF2 dns record (this is possibly TECH-OMISSION) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In the draft-eitf-marid-protocol-02.txt in section 2.1 an example is given of SPF record as example.com. IN SPF2 "spf2.0/pra +mx +a:colo.examp.e.com/28 -all" It is noteable that "spf2" part is repeated twice once as the name of the dns type and second time as a version of the record. I do not believe such duplication is appropriate because dns record type should be more general then the version number of the spf record and should not incorporate spf record version as part of the type name. To fix it is recomended that all references to SPF dns record type and examples be changed from "SPF2" to just "SPF" with note in the text that such dns type records should confront to SPF2.0 or later records. So above example would change to: example.com. IN SPF "spf2.0/pra +mx +a:colo.examp.e.com/28 -all" -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 22:24: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 WAA03987 for ; Thu, 26 Aug 2004 22:24: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 i7R234sd061276; Thu, 26 Aug 2004 19:03: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 i7R234pA061275; Thu, 26 Aug 2004 19:03:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R234oR061261 for ; Thu, 26 Aug 2004 19:03:04 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1C0W4z-000Jf0-00; Fri, 27 Aug 2004 03:03:01 +0100 Message-ID: <10cc01c48bd9$b3ddacf0$0200000a@ringo> From: "Chris Haynes" To: "Jim Lyon" Cc: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF8FAC96@df-fido-msg.exchange.corp.microsoft.com> Subject: Re: DEPLOY: Legal liability for creating bounces from forged messages Date: Fri, 27 Aug 2004 03:00:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "Jim Lyon" argues that messages may be silently discarded / 'bounces' may be suppressed as follows: > > Regarding silently discarding messages, Chris Haynes writes: > > > Actually I was advocating (2) [silent discard] - but only > > in the special case when the Mail-From entity has declined > > responsibility for the message by causing a test 'fail'. > > In other words, Chris believes that it's OK to silently discard mail > when you believe the bounce address is forged, but not when the PRA is > forged. > > I submit that, as a matter of practice, people who forge one also forge > the other. Also as a matter of practice, checking the PRA will produce > fewer false rejections than checking the bounce address will. > > Chris also disputes that there is any legal basis for silently > discarding mail at all. He's right that RFC 2821 requires that every > message be delivered, rejected or bounced. > > However, see draft-zinn-smtp-bounces-01, which explicitly authorizes > silent discards. (I know, it's not a standard. Yet.) > If Sender-ID is relying on another darft for its authority, then should not that draft be brought into this 'last call' process, so that the overall proposal can be assessed for technical coherence, compatibility etc. However, let's look at the draft... Section 3 - proposal says: "Although there is clearly an obligation to deliver or notify .. when an MTA can accurately determined (sic) that a message has a forged "reverse path" and has no content useful to the addressee, the message SHOULD be silently discarded." The draft ONLY permits silent discard when the message is shown to be a forgery by testing the return path - the Mail-From address. It makes it clear that in all other cases the 'deliver or notify' obligation remains. Only a failed Mail-From test gives you authority to break the SMTP obligation. This is EXACTLY what I proposed in the first of my paragraphs that you selected for quotation. Let me repeat my proposal here: > > Actually I was advocating (2) [silent discard] - but only > > in the special case when the Mail-From entity has declined > > responsibility for the message by causing a test 'fail'. I congratulate BZ Zinn for drafting exactly the right rule. However, you persevere... >See also RFC > 3834, which deals with automated responses in general (including > bounces) and says: > > - A responder MAY refuse to send a response to a subject message > which contains any header or content which makes it appear to the > responder that a response would not be appropriate. > > RFC 3834 is now a Proposed Standard. Thanks for referring to this new document (August 2004). I contend that your claim that the paragraph that you quote above includes 'bounces' is wrong. Earlier in RFC 3834 it says: "At least two types of automatic responses have been defined in IETF standards - Delivery Status Notifications [I2. RFC 3464] which are intended to report the status of a message delivery by the message transport system, and Message Diosposition Notifications ... These responses are defined elsewhere and are generally not within the purview of this document, except that this document recommends specific cases where they should or should not be used." Now, in my book 'bounces' are DSNs - they are described in RFC 3464. The paragraph you quote above does not contain (and is not within the context of) a specific recommendation that a DSN should not be used, so bounces are "not within the purview" of the paragraph you quote. Thus RFC 3834 does not give you authority to 'refuse to send a response' where that response is an RFC 3464 'bounce'. ============ Thank you for drawing my attention to RFC 3834 - it is is indeed an interesting document. Take, for example, the sub-section immediately before the one you quoted to me - the one on page 6 beginning "Because the vast majority of mail is unauthenticated...." It proceeds to say that large responses [bounces] should not be returned "...without specific knowledge that the request was actually authorized by the party associated with the address to which the response will be sent." Bingo! To conform to this new RFC, resposes must either have all responses trimmed to less than "a few kilobytes" or must have ensured that the request was actually authorised by the party associated with the Mail-From address. Looks like a _mandate_ to test the Mail-From address for forgery to me! Either that or ensure that _all_ responses are trimmed, which is not something you can actually do when you instruct an offering MTA to send the bounce for you. (I re-invoke my earlier argument about you still being responsible for generating the bounce even if you ask another host to do it for you). ============ I knew I had morality, business ethics and legal considerations on my side, now I have an RFC and a draft as well! You continue... > > Quoting Chris again: > > You claim in (2) that the drafts give authority for MTAs to silently > > discard messages. I cannot find that authority in the drafts. > > In the SenderID drafts, the only requirement imposed is that if an MTA > performs SenderID tests during a mail transaction and the test fails, it > SHOULD reject the message. This leaves open two possibilities for > silent discards: > > 1. An MTA might ignore the above SHOULD (after all, it's not MUST). > 2. An MTA might perform the tests after receipt, in which case the specs > impose no requirement on what the MTA does. > If detailed specs within the SMTP family specify options like SHOULD, but leave other behaviour unspecified, my contention has been all along that the unspecified behaviour MUST still be within the scope of the SMTP conmmitment to 'deliver or report', unless some other RFC provides specific authority for dropping bounces. Had RFC 3834 given you that authority, I would have conceded the argument to you - but it clearly does not, as I have demonstrated above. And please note the abstract to Zinn's draft, in which he states " [his later detailed advocacy of silent dropping following detection of a forged Mail-From address] should not be taken as a permanent carte-blanche to silently discard any message that one does not like". ============== Thanks for the great references, Jim. They have clearly proven my case! Chris Haynes From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 23:24: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 XAA07313 for ; Thu, 26 Aug 2004 23:24: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 i7R34cKr065833; Thu, 26 Aug 2004 20:04: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 i7R34c5r065832; Thu, 26 Aug 2004 20:04:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R34bO9065825 for ; Thu, 26 Aug 2004 20:04:37 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so377700rnk for ; Thu, 26 Aug 2004 20:04:38 -0700 (PDT) Received: by 10.38.99.64 with SMTP id w64mr2854872rnb; Thu, 26 Aug 2004 20:04:38 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Thu, 26 Aug 2004 20:04:38 -0700 (PDT) Message-ID: <94df60cf04082620046ffaea65@mail.gmail.com> Date: Thu, 26 Aug 2004 23:04:38 -0400 From: Reply-To: To: ietf-mxcomp@imc.org Subject: DEPLOY/IPR: Implications of MS license for academia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm the author of Mail Avenger (www.mailavenger.org), a GPLed, SPFv1-compliant SMTP server. I would, of course, like to comply with whatever standard emerges from the MARID effort. However, I have several questions/concerns about the license terms offered by Microsoft. * Reciprocal license agreement at universities My first concern is about section 2.3, the reciprocal patent license. I myself have no software patents and no plans to acquire any that might interfere with Sender ID. So I personally have no problem reciprocally licensing my (non-existent) patent portfolio. However, I'm also a professor at NYU, where I developed Mail Avenger, and from whose network I distribute the source code. The question is whether the contract applies just to patents on which I'm an inventor, or to any patent application by any faculty member at NYU. In the latter case (which sounds more likely), this could pose some serious problems. Unlike companies, which often enter into blanket patent cross-licensing agreements, NYU (like many universities) doesn't tend to license a patent without the consent of the inventor. Thus, at the very least, this kind of blanket patent license would constitute a new case that would need to be investigated. I could easily imagine having to get every faculty member with a remotely related patent or patent application to agree that it is unrelated to Sender ID. While it's unlikely someone at NYU has applied for any relevant patents, I doubt people would agree to sign over their patent rights without at least reading over the internet drafts to make sure. That's asking already busy people with no vested interest in my software to do work, which could then easily fall of the end of their to-do lists. A related problem is that some patent applications might be secret. Still another problem is that some funding contracts *require* principal investigators to patent any inventions and license them in certain ways. Thus, this kind of blanket license could potentially conflict with other PI's funding sources. In short, it seems there is a real danger that Microsoft's license would be unacceptable to many universities, which would prevent people in academia from releasing MARID-compliant software. * Trademark requirement I have two concerns about the requirement for a trademark. The patent license (sections 2.1 and 2.2) is only for "Licensed Implementations", which, according to section 1.2, must be "branded with a trademark owned or controlled by You." I notice that section 2.1, about object code, allows implementations to be distributed "directly or indirectly", while section 2.2 for source code only allows "distribution" without mention of indirect. Is this distinction intentional/meaningful? In particular, for GPLed code, someone who doesn't own the code can't distribute object code without also at least having the ability to distribute source. Thus, I'm worried that "indirect" distribution of GPLed code would not be possible. [Note: I gather there may be some specific incompatibilities with the GPL, but this question applies to any GPL-like license that requires source code availability.] Another problem is that it seems as though everyone along the chain requires a trademark. Suppose NYU had a trademark on Mail Avenger. If someone at another university made modifications to the software and wanted to redistribute them, it sounds like they could not do this unless they re-branded the software and got a new trademark--even if I want to allow people at other institutions to put out new versions of Mail Avenger. The license seems to require that each university executing the agreement have its own trademark under which the software is branded. I don't understand why consent of the trademark owner isn't good enough, but this seems like a very serious annoyance when collaborating across organizations only one of which can obviously own a particular trademark. Again, this is probably a more serious concern for academia than for industry. * Requirement that implementations conform to the specification This concern may be more specific to Mail Avenger, but nonetheless it seems like a potentially bad restriction. Mail Avenger's goal is to give individual users the maximum amount of control over what happens during SMTP sessions. Thus, while a traditional SMTP server might have a monolithic Sender ID implementation built in, Mail Avenger actually implements policies by reading scripts in users' $HOME/.avenger/ directories. These scripts can, for example, formulate arbitrary queries in the SPF language and implement either straight SPF or use SPF as a means of enforcing a different policy. If Sender ID were to become a standard, I would of course want to expose the various components, like, for instance, the query language and a $PRA variable that could be used for various purposes--for everything from regular Sender ID enforcement to RBL checking, SMTP callbacks, greylisting, or even SYN fingerprint validation against previous messages. Many potential uses of Sender ID's components, including the query language and PRA, would not be for the purposes of enforcing Sender ID, but rather for some other, related policy. In practice, giving users this kind of flexibility has proven extremely powerful in fighting spam. I'm concerned that: 1. This kind of toolkit-structured Sender ID implementation would not be covered by the license because of the ability to use encumbered components of Sender ID for other purposes. 2. If the actual sender ID enforcement is done by little config files or scripts in users' home directories, these scripts themselves might require the patent license and thus could not be easily shared and discussed amongst users. In general, ease of constructing spam-fighting tools is extremely important in the fight against spam. Thus, any licensing requirements that would rule-out highly extensible mail server designs would be unfortunate. * Effect on deployment The effectiveness of a technology like Sender ID will be proportional to its deployment. While it's good that Microsoft's patents can be licensed on pretty liberal terms, any need to sign contracts is still going pose an impediment to deployment. The burning question is exactly how serious the impediment will be--obviously there is a lot of disagreement on this point amongst members of the mailing list. However, at the very least, the fact that Sendmail's "base package" will not automatically support Sender ID will likely reduce deployment by a significant amount. In particular, given how tempers have flared on the list, it's hard to imagine there won't be at least one or two high-profile open-source OS distributions that don't include sender ID by default just on principle, because the maintainers object to this license. If our main goal is to stop mail forgery, then what we really need is a cost-benefit analysis. What is the cost of requiring a license for Sender ID compared to the benefit gained from incorporating the patented technology? Unfortunately, at this point the debate has centered only around the left side of the equation, and we have zero information about the right because Microsoft has not disclosed the nature of their pending patents. It would be a great gesture of good faith if Microsoft would disclose their patent applications so as to help guide the debate. For example, if there's some trivial modification that gets around the patents without reducing effectiveness, I don't see how anyone could argue we're better off incorporating the patented technology. On the other hand, if there are concrete benefits, then we can have a more concrete debate. In the absence of information on the scope of the patents, all we have information about is the scope of the license, namely that it applies to the core and pra drafts. Based on this, my personal opinion--colored, of course, by the license's effect on people in academia and my experience with the success of extensible designs in fighting spam--is that I would gladly give up the PRA algorithm and stick with something like SPFv1 if it eliminated the license headaches. David From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 23:26: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 XAA07387 for ; Thu, 26 Aug 2004 23:26: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 i7R39CXk066048; Thu, 26 Aug 2004 20:09:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R39CY4066047; Thu, 26 Aug 2004 20:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R39CAq066041 for ; Thu, 26 Aug 2004 20:09:12 -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 i7R39FY05193; Thu, 26 Aug 2004 20:09:15 -0700 Date: Thu, 26 Aug 2004 20:09:09 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <157921788.20040826200909@brandenburg.com> To: "Jim Lyon" CC: "Douglas Otis" , "Matthew Elvey" , "MXCOMP" Subject: message-based vs. channel-based In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAD7B@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAD7B@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, I think your note does an excellent job of distinguishing basic points and of doing basic comparison between one message-based scheme and a class of channel based schemes. (Caveat: As this note proceeds and I make comments that seem either critical or competitive, I must assure you that the above paragraph is quite serious. Your note divides things up in a way that makes it possible to have meaningful, substantial and detailed exploration of benefits and differences. This is goodness.) By way of making things more concrete we can turn the channel-based analysis into a specific reference. This will remove the use of 'might' from the discussion. Further, the per-message, versus per-MTA view of authorization is a fundamental distinction. I am hard-pressed to view either as being stronger or weaker. Each appears to have its own role. However that does leave me unclear about what you meant in your earlier message that HELO-based is "a whole lot weaker form of authentication." Thoughts about the appropriate role of each type of validation: Channel-based tells us about the aggregate message-sending behavior of a specific MTA. In a world of compromised personal computers, this sort of aggregate assessment can be very helpful for identifying "pipes" that are more or less dangerous. Message-based tells us about a particular author. This is clearly useful against phishing. To be useful against spam, the reputation of each author must be assessed. Note that per-message analysis does not permit the sort of aggregate analysis that lets one determine that an entire ISP's pool of systems is problematic. JL> Sender-ID: JL> Identity: The identity of a sending MTA is its IP address. But there is another identity, namely the identify of the Sender. And there is an inherent difficulty in using IP addresses, because they are so ephemeral, at least due to their being tied to topology. (I've noted before that it is very strange to see the IP and routing world moving away from using IP Addresses as identities, just as some of the email world is trying to move towards it.) JL> Authentication: There is no authentication other than that implicit in JL> the TCP/IP stack. Actually that appears to be quite a reasonable form of 'transactional' authentication, sufficient to the purpose of transit-time services like email. (It is not just that the IP Address is in the IP Source field, but that the SMTP session has a sequence of exchanges with that address.) On the other hand, I think no one would consider that authentication to be sufficient for financial transactions or anything else of major import. JL> Authorization: ...This authorization can only be bestowed by the JL> domain that the mail claims to come from. Right, the author authorizes the MTA. In particular, the author needs to register every MTA that might be evaluated on the path to the recipient. JL> EHLO-based schemes: I will, of course, suggest switching this section to refer to CSV, so that the use of 'might' goes away: JL> Identity: The identity of a sending MTA is its EHLO name. yup. JL> Authentication: Various scheme to determine whether the EHLO name that JL> an SMTP client sent is true. CSV does a forward DNS query and uses the A record to validate the name that is used for this IP Address. In terms of formal technical security strength, I think this is entirely on a par (neither better nor worse) than the IP-based approach that sender-id uses. There is a debate one should have about the potential benefits of using a domain name as the identifier, rather than using an IP Address. The CSV spec explores this and I've hinted at it, in the above comments about using an IP Address. The summary is that using the domain name can have vastly better administrative and scaling properties. JL> Authorization: [CSV uses] a scheme to determine whether the sending MTA JL> is authorized by its domain owner to be an SMTP client. There is no JL> authorization of individual messages. Given that it's channel-based, you are indeed correct. And by the way, note the potential scaling benefits. You do one validation per session, rather than one per message. In some scenarios, that is a huge savings. Even better, note the difference in registering the relatively small number of sending MTA domain names, versus the very large number of message authors. JL> The SenderID series of documents is based on an explicit decision to JL> pursue the first world-view; the fact that it doesn't do the second is JL> not a bug. And I certainly agree, except for the fact that sender-id does, in fact, try to valid both the message (sender) and the channel (MTA). d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 23:37: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 XAA08038 for ; Thu, 26 Aug 2004 23:37:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R3KXUF066801; Thu, 26 Aug 2004 20:20: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 i7R3KX7X066800; Thu, 26 Aug 2004 20:20:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R3KX09066777 for ; Thu, 26 Aug 2004 20:20:33 -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 CC93C40F7 for ; Thu, 26 Aug 2004 20:20:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <011e01c48b92$d2081e50$6c62fea9@ibmrkydk2ufvdd> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B69E443-F7D8-11D8-A96D-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Thu, 26 Aug 2004 20:20:55 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2004, at 2:13 PM, Mark Lentczner wrote: > See the protocol-03 draft for an example and discussion... Whoops! Typo! The currently published draft, draft-ietf-marid-protocol-02.txt has this example and discussion. - Mark From owner-ietf-mxcomp@mail.imc.org Thu Aug 26 23:57:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09267 for ; Thu, 26 Aug 2004 23:57:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R3UMNo067926; Thu, 26 Aug 2004 20:30: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 i7R3UMa0067924; Thu, 26 Aug 2004 20:30:22 -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 i7R3ULxt067918 for ; Thu, 26 Aug 2004 20:30:22 -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 1C0XRb-000E5Y-00 for ietf-mxcomp@imc.org; Fri, 27 Aug 2004 04:30:28 +0100 Message-ID: <111001c48be5$ebaa1360$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: TECH-OMISSION: Divergent assumptions about objectives Date: Fri, 27 Aug 2004 04:28:23 +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 think I can see a pattern developing in several of the technical threads. I appears that Sender-ID's (Microsoft's) primary, urgent concern is with Phishing. I would imagine that major banks etc. are, quite properly, 'encouraging' Microsoft to find a reliable way to show users that messages really are from the purportedly-responsible organization. Microsoft has, it appears, chosen to do this by testing the PRA for proof of authenticity (Sender-ID) and will then later find some way to display on the MTA some symbol of authenticity alongside the PRA (e.g. the HTTPS-like closed padlock which Margaret Olsen suggested). If I am right, then Microsoft is only interested in absolute proof of authenticity. It does not really need to distinguish the range of other test values, such as 'probably authentic', 'probably forged', 'proven to be forged', and it thinks it does not need to consider message entities other than the PRA (except in special cases). Now others, entering this WG with some knowledge of SPF, are perhaps approaching this differently. As the 'last call' process requires, we are looking only at the Sender-ID drafts on the table - we have no visibility of any 'greater plan'. Now when these people analyse the functionality provided by Sender-ID _in isolation_, they deduce that, like SPF, Sender-ID is intended to be a forgery detection system, i.e. that it is supposed to be able to say categorically 'this message is forged'. This functionality is urgently required by MTA operators for the management of threats other than Phishing. What I think I observe is several people, myself included, making constructive suggestions to improve the ability of Sender-ID to detect and handle forgeries, and to do so in an SMTP-friendly way. We then get frustrated when Sender-ID's supporters don't seem to be interested, or actively oppose what are believed to be viable, constructive suggestions made in good faith. Suppose my deduction is right - suppose the central objective of Sender-ID is only to recognise authentic messages. Suppose the greater scheme of which Sender-ID is a part has no need to distinguish the different degrees of 'not proven to be authentic'. Suppose, therefore, that the ability to _prove_ that a message was forged is not a core requirement of Sender-ID. If I am right, would it help to make harmonious technical progress in this WG if the -core draft were amended to reflect this significantly-different emphasis in the objectives of Sender-ID? If so, it's probably more appropriate for Microsoft to propose the change, but I will (as the process requires) if necessary. If I am wrong in my deduction, then we should be able to close this thread quite quickly; I'm not about to argue with Microsoft about what their objectives actually are or should be. ---------------- I have classed this as a TECH-OMISSION because its a case of inserting/ modifying a requirement so that it matches the actual functionality being specified; it closes a requirement-functionality gap which is what I interpret the spirit of TECH-OMISSION to be. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 01:33: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 BAA14947 for ; Fri, 27 Aug 2004 01:33: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 i7R5AnlK076738; Thu, 26 Aug 2004 22:10: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 i7R5AnXX076737; Thu, 26 Aug 2004 22:10:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R5Am05076730 for ; Thu, 26 Aug 2004 22:10:48 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7R5JDQe032403 for ; Thu, 26 Aug 2004 22:19:13 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7R5JDnp032399 for ; Thu, 26 Aug 2004 22:19:13 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 Aug 2004 22:19:13 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID WG Subject: DOC-BUG: section 2.1 of marid-protocol-02 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. In draft-ietf-marid-protocol-02.txt in section 2.1.7 last paragrapths read " Notice that the wildcard records must be repeated for twice for every name within the domain: Once for the name, and once to cover the tree under the the name. Use of wildcards is discouraged in general as they cause every name under the domain to exist and queries against arbitrary names will never return NXDOMAIN." I see multiple grammer errors in above paragraph as well as some other problems. In particular: a. " Notice that the wildcard records must be repated" does not sound right to me (butenglish is not my first language, I may well be wrong). I think changing this to just "Notice that wildcard records" would be better. Additionally extra " " before "Notice" should be removed. b. "repeated for twice for every name" is not correct, first "for" should be removed and this changed to "repeated twice for every name" c. The last paragraph refers to dns server returning NXDOMAIN as indication that no domain exist with DNS references in the document to RFC1035. In reality NXDOMAIN is (was?) bind-specific error contruct and not an error code used for this purpose in IETF DNS specifications. This error code should be referred to as "RCODE 3" (or RCODE=3) Please see last paragraph in the comments made by Paul Vixie on his view of using NXDOMAIN when referring to Verisign's wildcards dns abuse: http://www.cctec.com/maillists/nanog/historical/0310/msg00957.html Note that same also applies to other parts of the document, in particular I see NXDOMAIN used in section 3.4 next to last paragraph. Additionally in same section in last paragraph refers to server failure error code as "SERVFAIL". This is also BIND specific construct and reference should be referred to as "RCODE 2" (see RFC1035). At the same time I note that RFC2929 then set "NXDomain" as proper name of the DNS RCODE 3 and "ServFail" as proper name for RCODE 3 when registering them with IANA and this is now listed at http://www.iana.org/assignments/dns-parameters. But none of these documents are referenced from the protocol draft. I recommend that if use of NXDOMAIN and SERVFAIL is retained in the document, that names be replaced with "NXDomain" and "ServFail" with reference to either RFC2929 or to IANA dns parameters assignments url. Or alternatively the names "NXDOMAIN" and "SERVFAIL" can be removed and replaced with "RCODE 3" and "RCODE 2" with reference to RFC1035 2. In section 2.1 ("Publishing"), the paragraph reads: "The previous example might be published easily via this line in a domain file". "domain file" is a vague reference, please at the very least replace with "domain zone file". Futher the section 2.1 ends as "When published via TXT records it is still published directly at the domain name, even though other TXT records, for other purposes may be published there". I believe it should be added her also that use of the same record type for multiple puposes is discouraged.and wide use such practice poses a danger to dns system. 3. In section 2.1.1 "SPF DNS RR Type" paragraph says "Sender-ID compliant mail originating zones MUST publish SPF2 type records, and MAY publish TXT records that have identical content" I believe more emphasis is needed that TXT rect must be same as new DNS SPF type record and suggest changing this to: "Sender-ID compliant mail originating zones MUST publish SPF type records if such record type is supported and MAY publish TXT records. If both TXT and SPF type records are published for the same zone the content of these records MUST be identical." 4. In next paragraph in 2.1.1 it says "A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup TXT record at the same time, or wait for negative answer. SPF2 type SHOULD be used if available" Why does it specifically refer to "negative answer", what is so bad about "positive answer"? I think this all should rephrased to make it more clear: "A Sender-ID compliant MTA MUST look up SPF RR type. It MAY lookup TXT record at the same time or after receiving negative answer to SPF RR type query. If data from both SPF and TXT records is received then SPF RR type record data SHOULD be used. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 03:06:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04686 for ; Fri, 27 Aug 2004 03:06:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6ipxL088227; Thu, 26 Aug 2004 23:44: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 i7R6ipbt088226; Thu, 26 Aug 2004 23:44:51 -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 i7R6ipHs088219 for ; Thu, 26 Aug 2004 23:44:51 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040827064449.FBWL29920.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Fri, 27 Aug 2004 02:44:49 -0400 From: "John Glube" To: "'Rand Wacker'" Cc: Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Fri, 27 Aug 2004 02:44:24 -0400 Message-ID: <013901c48c01$4b7a03c0$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7R6ipHs088221 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Rand, >Hmm, in addition to working with a number of globally large >enterprise customers, Sendmail also represents a huge >number of those individual domain holders (I for one manage >a "vast number" of individual domains in my spare time ;) I >haven't seen much that presents a problem deploying to >sub-domains. In fact, our operational experience with >DomainKeys so far has shown using a whole separate >sub-domain namespace gives you a tremendous amount of >flexibility in both record depth and server deployment. I should have been clearer. Web hosting services offer sub domains. However, there is a threshold cost involved, which can sometimes be an incremental amount on a monthly basis. The catch? Pay the cost only to find the particular sender authentication scheme does not work when implemented on a large scale. This is not meant as a specific criticism of Sender-ID, but rather an expression of general concern. The real world concerns you are raising are extremely valid. Perhaps it is my innate sense of irony. Here we are, 4 days into last call, when someone like yourself comes in from the field and says hey guys "she just don't fit." :-) It just makes me a bit jittery. At the same time, given the time constraints everyone is working under, perhaps it is a function of the beast. >... the universal core concern for the large enterprises >I've talked to (the ones whose customers are targets of >phishing campaigns) are as follows: >- Firstly, to provide end-users the information to protect >themselves by authenticating something the end user will see These statements raise fundamental questions. It strikes me there are two underlying issues: * Implementation of one or more methodologies which can aid in thwarting volume senders of unwanted email from hiding identity. Here it would seem we require a solution which protects one or more delivery channels through authentication, (thwarting the hiding of identity) plus reputation (allowing the sorting of good from bad mail) and accreditation for those who would otherwise be grey listed. * Whether the correct response to phishing, which is spoofed domains, forged header and message content, along with the use of fake web sites is authenticating the domain in the message from line and requiring the upgrading of email client software across the board, so end user's can see the result. To respond to this specific form of crime, would it be more efficient and focused to allow the end user to authenticate the sender's message content through some form of light weight cryptographic scheme? >- Secondly, to ensure reliable delivery of their customer >relationship email This is a concern across the board, with the present state of email delivery, due in large part to coping with ever spiralling levels of unsolicited bulk mail. In making these comments, I am not attacking the Sender-ID design. It is as you point out a response in part to very specific complaints. I am simply suggesting the concern you raise of over-running of TXT data space in FQDN is valid. On balance, the use of sub-domains may well be a practical solution to the specific issue as raised. But, given some of the side effects to the vast numbers of others involved with email perhaps the issue highlights a more fundamental concern. Whether the financial institutions' design criteria, which I gather from your comments has stamped the creation of certain key aspects of Sender-ID is the right approach to dealing with the phishing problem? Answering this question may lead to a better answer to the key practical concerns you raise. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 03:38: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 DAA06314 for ; Fri, 27 Aug 2004 03:38: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 i7R7BXDm091305; Fri, 27 Aug 2004 00: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 i7R7BXFH091304; Fri, 27 Aug 2004 00:11:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R7BWGh091298 for ; Fri, 27 Aug 2004 00:11:33 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7R7JpfO018451 for ; Fri, 27 Aug 2004 00:19:51 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7R7JpEo018447 for ; Fri, 27 Aug 2004 00:19:51 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 27 Aug 2004 00:19:51 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID WG Subject: DOC-BUG (possibly TECH-OMISSION): ietf-marid-core section 5 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In section 5.1 "Neutral or None or PermError" the statement is "An SMTP server receiving one of these results SHOULD NOT reject the message for this reason along, but MAY subject the message to heightened scrutiny by other anti-spam measures" I object to using term "other anti-spam measures", this implies that MARID CORE itself described an anti-spam measure where as the purpose of MARID WG is not to create anti-spam mechanism but to fight the problem of phishing which is a result of insecurity in current email infrastructure. I recommend changing the sentence to just "by other measures" or possibly to "by other email security measures" Simularly to above in section 5.4 it has the same statement: "An SMTP server receiving this result SHOULD NOT reject the message for this reason along, but MAY subject the message to heightened scrutiny by other anti-spam measures" I have same objection and recomendation as with 5.1. Also since the statements in 5.1 and 5.4 are basicly the same, it might be easier to combine these sections leaving as separate paragraph about difference of SoftFail, i.e. change to something like: 5.1 Neutral, None, PermError or SoftFail An SMTP server receiving one of these results SHOULD NOT reject the message for this reason along, but MAY subject the message to heightened scrutiny by other email security measures, and MAY reject the message as a result of this heightened scrutiny. Such additional security measures may take into account that message for which the result is "SoftFail" is less likely to be authentic that message for which the result is "Neutral". --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 03:58:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07738 for ; Fri, 27 Aug 2004 03:58:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R7YpYh094023; Fri, 27 Aug 2004 00:34: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 i7R7Ypxg094022; Fri, 27 Aug 2004 00:34:51 -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 i7R7Yppu094016 for ; Fri, 27 Aug 2004 00:34:51 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i7R7YpMD020144 for ; Fri, 27 Aug 2004 00:34:51 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <93C5D480-F7FB-11D8-8AD0-000A95AC5778@isipp.com> Content-Transfer-Encoding: 7bit From: "Anne P. Mitchell, Esq." Subject: Re: acceptable licenses (Was: Can there be an early decision on t he SenderID license?) Date: Fri, 27 Aug 2004 00:34:49 -0700 To: "'IETF MARID WG'" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2004, at 7:06 AM, Hallam-Baker, Phillip wrote: > > Right now, we are supposed to be reviewing all of the documents. > > However, as demonstrated in the "DEPLOY/IPR: Fundamental > > Disagreements, or Get On With It" thread, there doesn't seem to be a > > rough consensus that the SenderID license is acceptable. (Actually, > > there appears to be a rough consensus that it isn't acceptable.) > > I have yet to see a statement that makes a valid legal argument > that the license terms prohibit open source distribution. > > The license terms are at least as open as the terms which the > IETF has accepted in the past. > > This is a quasi-judicial proceeding, we have to proceed on the > basis of established facts. About the only fact I see a consensus > on is that none of us are lawyers. Well, most of us aren't. I agree completely with Larry Rosen, and several others, that the entire scheme vis the license is problematic. The *reason* it is problematic is that while, yes, it allows unlimited use by *end users*, as soon as someone tries to modify it for their own purpose, and then share that modification with others for the good of and widespread adoption throughout the industry, there's a "gotcha". In fact, I would argue that the same concern applies to end-users - what if the end-user wants to tweak the code themselves? If they want to then share that modified implementation they could find themselves on the wrong end of an MS lawsuit. It's all about control. You can't really blame MS for wanting to retain this sort of control - but I would suggest that it's antithetical to the real goal here. An authentication system to be uniformly adopted across the industry is *not* the same as an authentication system to be uniformly adopted across the industry which is essentially *owned* by one very large ISP. Having an ISP - particularly one of the 800 pound gorillas - own the ultimate commercial (and that's what it is, commercial) rights to the one true authentication system is like having a large marketing company own the IP rights to the one spam filter in use across the industry. What happens when Earthlink comes up with a better way to both implement and check for Sender I.D., which ends up giving it a competitive edge over Hotmail and MSN in the spam performance arena? (And make no mistake about it - at this point in time, spam/anti-spam performance at national ISPs is very much all about a competitive marketing edge.) Remember, this is the same company that threatened Slashdot and demanded that they remove user postings because the users had quoted a *public* Microsoft document 'in violation of their copyright'. Of course, this is something which I and many others have been saying, and predicting, all along. That as soon as MS started courting Meng, it tolled the death-knell for the open-source potential of SPF, which is what made SPF so attractive in the first place. In my opinion what we need is a SenderID/SPF-clone which is truly open-source, and which doesn't itself violate the inevitable Microsoft IP claims. You can be reasonably sure that MS' plan all along was to rule this market, and that's exactly where they are headed, with the blessing of a surprising number of people. The race for a winning authentication protocol among the majors was never altruisitically about authentication first - it was always about market domination - and it was a shrewd, but blatant, move on MS' part to dance with Meng and end up subsuming SPF. Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy Professor of Law, Lincoln Law School of SJ Committee Member, Asilomar Microcomputer Workshop From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 05:14: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 FAA12447 for ; Fri, 27 Aug 2004 05:14: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 i7R8k7sn015623; Fri, 27 Aug 2004 01:46: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 i7R8k7oP015622; Fri, 27 Aug 2004 01:46:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from invasion.mail.pas.earthlink.net (invasion.mail.pas.earthlink.net [207.217.120.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8k63R015608 for ; Fri, 27 Aug 2004 01:46:06 -0700 (PDT) (envelope-from tripp@corp.earthlink.net) Received: from user-11favh8.dsl.mindspring.com ([66.245.126.40] helo=[192.168.0.2]) by invasion.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 4.34) id 1C0cN4-00073h-W0 for ietf-mxcomp@imc.org; Fri, 27 Aug 2004 01:46:07 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87321EEB-F805-11D8-A15B-000A95BDB38A@corp.earthlink.net> Content-Transfer-Encoding: 7bit From: Tripp Cox Subject: Re: acceptable licenses (Was: Can there be an early decision on t he SenderID license?) Date: Fri, 27 Aug 2004 04:46:03 -0400 To: "'IETF MARID WG'" X-Mailer: Apple Mail (2.619) X-ELNK-Trace: 3507b2fe2d9b3ca5cc16ce54e02836f094e34c6caf38b7b8f7df7400e34766b5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.126.40 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2004, at 10:06 AM, Hallam-Baker, Phillip wrote: > What was ASKED of Microsoft was to produce a license that made it > possible to create and distribute open source code. Now that this > has happened I beleive that the ground has been shifted. I do not > see this issue being approached from the make it work point of view. Others wishing to distribute an MUA implementation of Sender-ID may find themselves highly disinclined to go through the trouble to do so by the terms of the Microsoft license. [Absent reputation systems] If I follow the specification and only check the PRA, I can do little more than hint to the MUA user that the message might have some air of legitimacy. If I extend the spec a bit and also check rfc2821 mail from in an effort to reach a more firm verdict, then I have a "broken" implementation according to Jim Lyons. Why take the risk of Microsoft revoking the license at some future date and incorporate the technology into an installed base of millions of users? So I can highlight message summary lines white and yellow in the inbox view? So I can say "apparently sent on behalf of X?" It may not be worth it to many key constituents to make it work. From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 05:48: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 FAA14839 for ; Fri, 27 Aug 2004 05:48: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 i7R9OJ4v032099; Fri, 27 Aug 2004 02:24: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 i7R9OJSE032097; Fri, 27 Aug 2004 02:24:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail48.messagelabs.com (mail48.messagelabs.com [193.109.255.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R9OHjN032079 for ; Fri, 27 Aug 2004 02:24:18 -0700 (PDT) (envelope-from msergeant@startechgroup.co.uk) X-VirusChecked: Checked X-Env-Sender: msergeant@startechgroup.co.uk X-Msg-Ref: server-11.tower-48.messagelabs.com!1093598655!4674523 X-StarScan-Version: 5.2.10; banners=startechgroup.co.uk,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 32706 invoked from network); 27 Aug 2004 09:24:15 -0000 Received: from unallocated.star.net.uk (HELO MLABS006.messagelabs.com) (62.231.131.6) by server-11.tower-48.messagelabs.com with SMTP; 27 Aug 2004 09:24:15 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by MLABS006.messagelabs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 27 Aug 2004 10:24:15 +0100 Received: (qmail 27077 invoked from network); 26 Aug 2004 09:20:14 -0000 Received: from unknown (HELO ?192.168.1.2?) (10.191.100.9) by matt?dev.int.star.co.uk with SMTP; 26 Aug 2004 09:20:14 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Carl Hutzler , IETF-MXCOMP From: Matt Sergeant Subject: Re: AOL's stance on SenderID and IPR issues Date: Fri, 27 Aug 2004 10:24:15 +0100 To: "william(at)elan.net" X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 27 Aug 2004 09:24:15.0517 (UTC) FILETIME=[9F222CD0:01C48C17] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Aug 2004, at 02:14, william(at)elan.net wrote: > It is my understanding that Yahoo is one of the largest (if not the > largest) > companies using Qmail and there have been substantial discussions on > this > list in the last day that license terms may not compatible with that > at all. I don't think Yahoo uses qmail any more - they use a custom MTA that they wrote in-house. However we do, and are one of the larger installations of qmail (2500 servers). However as a commercial company, like AOL, we don't have a problem with the license. We can develop our own implementation and request a license from Microsoft to do so. The qmail license would only affect us if we wanted to distribute that code to others. However that doesn't imply we're entirely happy with the sender-id license. If the licensing block adoption then it is an issue, regardless of the legal status. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 06:12: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 GAA16130 for ; Fri, 27 Aug 2004 06:12: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 i7R9lIQN040316; Fri, 27 Aug 2004 02:47:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R9lIXD040315; Fri, 27 Aug 2004 02:47:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R9lGLU040237 for ; Fri, 27 Aug 2004 02:47:17 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7R9l8IA017924 for ; Fri, 27 Aug 2004 10:47:08 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7R9l8js017923; Fri, 27 Aug 2004 10:47:08 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) References: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> <1093539963.30660.28.camel@jmacdonald-work.e-dialog.com> From: Graham Murray Date: Fri, 27 Aug 2004 10:47:07 +0100 In-Reply-To: (Rand Wacker's message of "Thu, 26 Aug 2004 13:14:13 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Rand Wacker writes: > Add to this the fact that these corporations regularly outsource marketing > and other material delivery to third party firms. Since they want these > messages to be branded as coming from their primary domain, While this may be off-topic for this group, I believe that companies doing this are not helping themselves at all when it comes to protecting against phishing and other impersonation attacks. I know that most people do not look at headers, but some of us do. Because I am aware of phishing, when I receive an email which claims to come from a financial institution or e-commerce site etc, I give it far more scrutiny than I would most other emails. This includes looking at the headers. Without Sender-ID, PRA, or other authentication scheme (which is the status quo) it is almost impossible for the recipient to determine whether or not a particular mail is genuine when it is sent from a third party firm. So if they ensure that all emails to customers (and potential customers) are sent from their own servers they will make phishing detection and avoidance much simpler both pre- and post- introduction of MARID checks. From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 07:11: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 HAA19814 for ; Fri, 27 Aug 2004 07:11: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 i7RAigHi059820; Fri, 27 Aug 2004 03:44: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 i7RAignd059819; Fri, 27 Aug 2004 03:44:42 -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 i7RAigCe059793 for ; Fri, 27 Aug 2004 03:44:42 -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, 27 Aug 2004 06:44:40 -0400 id 00213535.412F1099.00005E8A Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <1860E822-F816-11D8-9196-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: Problematic issues with regard to last call Date: Fri, 27 Aug 2004 06:44:38 -0400 X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit MARID participants, There have been a few problematic statements during this last call period that need to be addressed. First, some of the issues raised are premised on the issue of scope... as in Sender ID does not do X when X is not something Sender ID ever intended to do. That whole argument could be applied to any MARID output and even to the MARID charter itself. While such opinions are valid and in most cases factual, they are misplaced at this time. Second, there have been a few messages soliciting polls and requesting adjusted timelines. We ask that participants refrain from deviating the working group from its last call period. While you may feel passionate about a certain issue, please be considerate of the process. The co-chairs are interested in reading thoughtful opinions and not just raised hands or parroted thought. Additionally, timelines have been set to accommodate individuals who may not be available at this week due to vacation, travel, or numerous other reasonable absences from an Internet connection. Finally, some participants have outright stated that they are interested only in the advancement of a competing specification to Sender ID while others have not said so much but have taken a similar tone. This is most offensive and counter to the notion of finding a consensus-based standard. Many individuals in this working group have worked very hard to find common ground, and this unilateralism is unfair to them. If it is your intent to be unwavering and steadfast in your opinion no matter the discourse of the issues, we ask that you disengage from this working group. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 07:19: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 HAA20327 for ; Fri, 27 Aug 2004 07:19: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 i7RAmFB2060961; Fri, 27 Aug 2004 03:48: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 i7RAmF80060960; Fri, 27 Aug 2004 03:48:15 -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 i7RAmFXP060953 for ; Fri, 27 Aug 2004 03:48:15 -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, 27 Aug 2004 06:48:14 -0400 id 00213535.412F116E.00005EA3 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: on the topic of IPR Date: Fri, 27 Aug 2004 06:48:11 -0400 X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It is one of the jobs of co-chairs to facilitate discussion of working group topics. Not that the issue of IPR is being debated lightly, however we would like to raise a few discussion points that may have been overlooked or given light treatment. - Many a message have been dedicated toward discussing the potential abuse Microsoft may undertake while armed with a patent. However, there has been little discussion regarding Microsoft's willingness and ability (via deep pockets) to fend off counter patent claims. Should Sender ID go forward with the acceptance of Microsoft's IPR, it leaves little doubt that another entity claiming rights to such technology will have to go through Microsoft to find remedy. However, if MARID were to produce another standard such as Classic SPF or even CSV, who will defend a legal claim against it? - Some of the participants have speculated openly that Microsoft's IPR claims might also cover the SPF syntax even though Microsoft has not specifically attributed their claim to draft-ietf-marid-protocol. Given that Microsoft's patent application and original IPR claim covered a Caller ID document which used XML and not SPF, is this a reasonable assumption? It should be noted that it was the MARID working group that persuaded Microsoft to use the SPF syntax. Microsoft's first choice was XML. - If it is reasonable to assume that Microsoft's patent application and claimed IPR can and/or do reach beyond draft-ietf-marid-core and draft-ietf-marid-pra, is it not the best course of action to take Microsoft's offer of a royalty-free, nondiscriminatory and reasonable license given that a rejection of Sender ID as a standard has no weight on the standing of their claim. In other words, if it is believed that their claim could cover other work product of MARID, then would not the best course of action be to secure the best-possible license? - On the issue of deployment, there have been many messages regarding the adoption of Sender ID (as a note, the chair's instructions specifically called for opinion about personal deployment and not speculation as to the actions of others). While many believe that Sender ID's encumbrances will slow adoption because it is not as friendly as desired toward open source, it has been noted that Qmail also has an equally or more unfriendly license toward open source yet is one of the most popularly used MTAs. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 07:45: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 HAA21787 for ; Fri, 27 Aug 2004 07:45: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 i7RBCA3l068535; Fri, 27 Aug 2004 04:12: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 i7RBCAtE068534; Fri, 27 Aug 2004 04:12:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBC8u5068522 for ; Fri, 27 Aug 2004 04:12:09 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1C0eeP-000Ncw-00; Fri, 27 Aug 2004 12:12:10 +0100 Message-ID: <121501c48c26$6bf12c30$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Cc: "Jim Lyon" , "Meng Weng Wong" Subject: TECH-OMISSION: Need to invoke 'deliver-or-report' obligation Date: Fri, 27 Aug 2004 12:10:01 +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 Proposed addition to -core-03 The section introduction has a new second paragraph and is now to start: vvvvvvvvvvvvvvvvvvvvvvvvv 5. Actions based on the decision When the Sender-ID test is used by an SMTP server as part of receiving a message, the server should take the actions described by this section. Implementations of Sender-ID MUST ensure that the SMTP obligation to 'deliver or report' [RFC2821] is upheld under all circumstances. The check_host function .... ^^^^^^^^^^^^^^^^^^^^^ and a normative reference to RFC2821 is to be added to 1.1 ================ Rationale It appears that WG members, associated with a potentially-significant implementor, are under the misapprehension that it is acceptable to silently discard messages. See, for example, the advice offered in http://www.imc.org/ietf-mxcomp/mail-archive/msg03577.html and a subsequent message from Jim Lyon in the same thread, commencing "Regarding silently discarding messages..." which has not yet reached the archives. It would therefore seem to be necessary for the IETF to require an explicit reference to this fundamental SMTP obligation. ================== Alternative resolution of issue It may perhaps be that the author(s) of the draft do, indeed, require, advise or permit the silent discard of messages under some circumstances. There is a precedence for the correct way to make such a significant proposal - the following draft [Zinn] http://www.watersprings.org/pub/id/draft-zinn-smtp-bounces-01.txt proposes permitting the silent discard of message when the Mail-From address (and only that address) has been proven to be forged. If the authors of Sender-ID permit or require the silent discarding of messages following the testing of entities other than Mail-From then I contend that they should: 1) Prepare and publish a draft, in the style of [Zinn], specifying the test conditions under which they advocate message discard, 2) Place that draft into the MARID WG, so that it can be assessed alongside its companion drafts, 3) Seek an opinion on the draft from whichever IETF activities are responsible for the integrity of SMTP as a whole, 4) Amend the Sender-ID drafts to make specific reference to this new draft wherever message-discard is to be invoked. ================= There is clearly currently to much ambiguity in / misunderstanding of / disregarding of SMTP basic obligations for the status-quo to be acceptable. I believe that one of the above alternatives has to be actioned by the authors of -core-03. Regards, Chris Haynes From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 08:02: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 IAA22991 for ; Fri, 27 Aug 2004 08:02: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 i7RBbXD1077264; Fri, 27 Aug 2004 04:37: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 i7RBbXKw077263; Fri, 27 Aug 2004 04:37:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBbWhn077251 for ; Fri, 27 Aug 2004 04:37:33 -0700 (PDT) (envelope-from SRS0=i7Q+fOj9=LR=asarian-host.net=admin@asarian-host.net) Comments: To protect the identity of the sender, certain header fields are either not shown, or masked. Anonymous email accounts can be requested by filling in the appropriate form at: https://asarian-host.net/cgi-bin/signup.cgi Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) by mail.asarian-host.net (8.13.1/8.13.1) with ESMTP id i7RBbX4W041307 for ; Fri, 27 Aug 2004 13:37:33 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: domain of admin@asarian-host.net designates sender IP as SASL permitted sender) Message-Id: <200408271137.I7RBBX2B041297@asarian-host.net> Date: Fri, 27 Aug 2004 11:37:33 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: Re: on the topic of IPR X-Trace: vZJrnKKKMOiEpspEe19PjdM0UrkOfdaYoPJ7qCW9WKfSktIMDX/EKpPb1TrrwYbKXAM57ejneG/PeTpxmKIWjQ== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "IETF MARID WG" References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Auth: Asarian-host PGP signature iQEVAwUAQS8c/TFqW1BleBN9AQHkngf/UWWVr5yYAnYkbgrwiKyPGDgS5yHdJk9K KlFQoVr5+4HuvbS/5FObuz8WYESiOPWflBcBdU9cXlVP+cMrTQ9W/430SRGWxErY Bvo17X9vx/2SsDARYlYJ+M9T1iUx6gncDC8R0udvOZ0J6t5FnW7dLYlq7CyUU4KM jJ5PCiiPl0g+r/W4QV+akPb1FJsiqABs+YS5xwtlSkDUDdyjqRj2F7JuBjs13O4H 6MQzlBf+TWYjJKgPe/+WTWKDpF8hoKL5YtH+Zx+ux8XS95iOBNXUKO2PbXxeOszr Qy4CJWJW2lD8iuWQsbKA7oVlHDaIY8eqVh2S27dw6AdA+Wge02WQUA== =y9ml Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > - Some of the participants have speculated openly that Microsoft's > IPR claims might also cover the SPF syntax even though Microsoft has > not specifically attributed their claim to draft-ietf-marid-protocol. I was one of those people who openly speculated about Microsoft usurping SPF. Only yesterday, Stephane Bortzmeyer said: "You can say that every SPF implementation (there are many, see http://spf.pobox.com/downloads.html) is an implementation of Sender-ID's -protocol." (I am not exactly sure how serious Stephane was, so I leave that in the middle). But I had just voiced, the other day, precisely this worry: that, ere long, Microsoft, integrating SPF checks with Sender ID, might come to look upon SPF (not perhaps its syntax, but its use in object-code), as part of Sender ID. Given statements like the above, I cannot say my concerns are alleviated. > Given that Microsoft's patent application and original IPR claim > covered a Caller ID document which used XML and not SPF, is this a > reasonable assumption? How realistic is this? IANAL, either. Which is why I would love to hear a lawyer say here, that such "usurpation" cannot possibly occur within the current license. This is an area, btw, where I will gladly stand corrected. ;) - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 08:29: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 IAA24871 for ; Fri, 27 Aug 2004 08:29: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 i7RC0SRk086155; Fri, 27 Aug 2004 05:00: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 i7RC0SrL086154; Fri, 27 Aug 2004 05:00: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 i7RC0SCC086135 for ; Fri, 27 Aug 2004 05:00:28 -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, 27 Aug 2004 08:00:27 -0400 id 002134FC.412F225B.00006385 In-Reply-To: <111001c48be5$ebaa1360$0200000a@ringo> References: <111001c48be5$ebaa1360$0200000a@ringo> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "IETF MARID WG" From: Andrew Newton Subject: Re: TECH-OMISSION: Divergent assumptions about objectives Date: Fri, 27 Aug 2004 08:00:24 -0400 To: "Chris Haynes" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2004, at 11:28 PM, Chris Haynes wrote: > I have classed this as a TECH-OMISSION because its a case of inserting/ > modifying a requirement so that it matches the actual functionality > being > specified; it closes a requirement-functionality gap which is what I > interpret > the spirit of TECH-OMISSION to be. Can you need to be more explicit about the change you desire? This helps with readability and tracking of the issues. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 08:29: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 IAA24889 for ; Fri, 27 Aug 2004 08:29: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 i7RC1IaX086486; Fri, 27 Aug 2004 05:01: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 i7RC1IFi086485; Fri, 27 Aug 2004 05:01:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC1H5Z086472 for ; Fri, 27 Aug 2004 05:01:17 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 08:01:18 -0400 Message-ID: <412F228E.4070007@hepcoe.com> Date: Fri, 27 Aug 2004 08:01:18 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: on the topic of IPR References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> In-Reply-To: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2004 12:01:18.0726 (UTC) FILETIME=[8FCDC260:01C48C2D] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > It is one of the jobs of co-chairs to facilitate discussion of working > group topics. Not that the issue of IPR is being debated lightly, > however we would like to raise a few discussion points that may have > been overlooked or given light treatment. > > - Many a message have been dedicated toward discussing the potential > abuse Microsoft may undertake while armed with a patent. However, > there has been little discussion regarding Microsoft's willingness and > ability (via deep pockets) to fend off counter patent claims. Should > Sender ID go forward with the acceptance of Microsoft's IPR, it leaves > little doubt that another entity claiming rights to such technology > will have to go through Microsoft to find remedy. However, if MARID > were to produce another standard such as Classic SPF or even CSV, who > will defend a legal claim against it? > This is fear-mongering, I'm afraid to say. It makes no sense to say "here we have some verifiably homegrown IP with no encumberances and here we have some encumbered IP. Let's use the encumbered IP rather than the unencumbered IP because otherwise we might get sued by parties unknown". In any case, the EFF and PubPat amongst others have come into being just for the purpose of defending the public at large against these types of attacks. > - Some of the participants have speculated openly that Microsoft's > IPR claims might also cover the SPF syntax even though Microsoft has > not specifically attributed their claim to draft-ietf-marid-protocol. > Given that Microsoft's patent application and original IPR claim > covered a Caller ID document which used XML and not SPF, is this a > reasonable assumption? It should be noted that it was the MARID > working group that persuaded Microsoft to use the SPF syntax. > Microsoft's first choice was XML. > > - If it is reasonable to assume that Microsoft's patent application > and claimed IPR can and/or do reach beyond draft-ietf-marid-core and > draft-ietf-marid-pra, is it not the best course of action to take > Microsoft's offer of a royalty-free, nondiscriminatory and reasonable > license given that a rejection of Sender ID as a standard has no > weight on the standing of their claim. In other words, if it is > believed that their claim could cover other work product of MARID, > then would not the best course of action be to secure the > best-possible license? > Perhaps, but you are going to have a lot of trouble convincing people that this is the best possible license that Microsoft could offer. It may be acceptable for large companies that are technology consumers, but it will remain unacceptable for many developers and smaller end users. It is too ambiguous, too obviously anti-open source and requires you to waive certain important legal rights in the event of a dispute. Your suggestion that we ought to just acquiese to MSFT because they might have us by the short and curlys is simply not credible. If MARID chooses ClassicSPF and Microsoft is granted patents that appear to cover this technology, we have plenty of prior art to invalidate such patents. > - On the issue of deployment, there have been many messages regarding > the adoption of Sender ID (as a note, the chair's instructions > specifically called for opinion about personal deployment and not > speculation as to the actions of others). While many believe that > Sender ID's encumbrances will slow adoption because it is not as > friendly as desired toward open source, it has been noted that Qmail > also has an equally or more unfriendly license toward open source yet > is one of the most popularly used MTAs. > Without speculation then, I personally will not deploy an encumbered Sender-ID in my company. > -andy > > From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 08:46: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 IAA26056 for ; Fri, 27 Aug 2004 08:46: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 i7RCMkkH093425; Fri, 27 Aug 2004 05: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 i7RCMkVP093424; Fri, 27 Aug 2004 05:22: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 i7RCMjv6093372 for ; Fri, 27 Aug 2004 05:22:45 -0700 (PDT) (envelope-from michel@bouissou.net) Received: from localhost (localhost [127.0.0.1]) by totor.bouissou.net (Postfix) with ESMTP id 45D072841E for ; Fri, 27 Aug 2004 14:22: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 25842-04 for ; Fri, 27 Aug 2004 14:22:35 +0200 (CEST) Received: by totor.bouissou.net (Postfix, from userid 48) id 47A972862F; Fri, 27 Aug 2004 14:22:35 +0200 (CEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user michel); by www.bouissou.net with HTTP; Fri, 27 Aug 2004 14:22:35 +0200 (CEST) Message-ID: <43266.127.0.0.1.1093609355.squirrel@127.0.0.1> In-Reply-To: <412F228E.4070007@hepcoe.com> References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> <412F228E.4070007@hepcoe.com> Date: Fri, 27 Aug 2004 14:22:35 +0200 (CEST) Subject: Re: on the topic of IPR From: "Michel Bouissou" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at bouissou.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Kevin Peuhkurinen a écrit : > > Andrew Newton wrote: >> >> - Many a message have been dedicated toward discussing the potential >> abuse Microsoft may undertake while armed with a patent. However, >> there has been little discussion regarding Microsoft's willingness and >> ability (via deep pockets) to fend off counter patent claims. Should >> Sender ID go forward with the acceptance of Microsoft's IPR, it leaves >> little doubt that another entity claiming rights to such technology >> will have to go through Microsoft to find remedy. However, if MARID >> were to produce another standard such as Classic SPF or even CSV, who >> will defend a legal claim against it? >> > This is fear-mongering, I'm afraid to say. It makes no sense to say > "here we have some verifiably homegrown IP with no encumberances and > here we have some encumbered IP. Let's use the encumbered IP rather > than the unencumbered IP because otherwise we might get sued by parties > unknown". In any case, the EFF and PubPat amongst others have come into > being just for the purpose of defending the public at large against > these types of attacks. It's an interesting new concept : Make sure we get eaten by the lion today, so we are sure we don't have any risk of being possibly attacked by a wolf at some unknown later time ;-) MS has publicly announced its intention of getting much more patents covering every possible area this year (if I remember well, the figure was something like 20,000 ?). This is no hidden agenda, this is public, published information. If they get as many patents, they will just turn computer science into a minefield where you can't walk without the risk of seing an unknown MS patent burst under your feet. That's great. So for sure, chosing as a standard an algorithm which is already covered by alledged IPR from a company which has a so good record of acting for the community good in a disinterested way, is the best choice we can make... -- Michel Bouissou OpenPGP ID 0xDDE8AC6E From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 09:18: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 JAA27830 for ; Fri, 27 Aug 2004 09:18: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 i7RCrkpa001623; Fri, 27 Aug 2004 05:53: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 i7RCrkhZ001622; Fri, 27 Aug 2004 05:53:46 -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 i7RCrkWV001615 for ; Fri, 27 Aug 2004 05:53:46 -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, 27 Aug 2004 08:53:47 -0400 id 0019769C.412F2EDC.0000676F In-Reply-To: <412F228E.4070007@hepcoe.com> References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> <412F228E.4070007@hepcoe.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <220736D9-F828-11D8-9196-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: on the topic of IPR Date: Fri, 27 Aug 2004 08:53:46 -0400 To: Kevin Peuhkurinen X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 8:01 AM, Kevin Peuhkurinen wrote: > It makes no sense to say "here we have some verifiably homegrown IP > with no encumberances and here we have some encumbered IP. Let's use > the encumbered IP rather than the unencumbered IP because otherwise we > might get sued by parties unknown". Is there a connection between "verifiably homegrown" and patent claims? You are correct that the parties are unknown. If this were an arcane subject area, it is most likely that they would remain unknown and probably non-existent. However e-mail and electronic messaging and anti-spam are hot areas of intellectual property. I did take a stroll through the USPTO database and there are numerous, numerous patents in this area. And these do not include the pending patents that cannot be seen. Also, if company XYZ came forward tomorrow and claimed covering IPR, should we ignore them? -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 09:43:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29142 for ; Fri, 27 Aug 2004 09:43:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDHmmt008213; Fri, 27 Aug 2004 06:17: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 i7RDHmoA008212; Fri, 27 Aug 2004 06:17:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDHjwa008183 for ; Fri, 27 Aug 2004 06:17:47 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 27 Aug 2004 09:17:42 -0400 id 002E0A23.412F3476.00004B76 From: David Blacka Organization: VeriSign, Inc. To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Fri, 27 Aug 2004 09:17:13 -0400 User-Agent: KMail/1.6.2 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: <200408270917.13412.davidb@verisignlabs.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday 26 August 2004 7:07 pm, william(at)elan.net wrote: > In case we decide to have main record be located within subdomain prefix > depending on the identity, then in order to achieve same effect with > wildcards, we'd still have to place the record in root of the domain, i.e. > a._marid_pra.example.com. IN TXT "v=spf1 ip4:192.168.0.0/16 ~all" > *.example.com. IN TXT "v=spf1 ip4:10.0.0.0/8 ~all" You seem to be discussing a plan that I, at least, have not seen before. All of the discussion that I have seen has been about actual *prefixes*, which isn't what you are showing here. However, you are illustrating an important point about naming and wildcards which holds true even if your examples seem a bit odd to me. IF scope is part of the prefix scheme (i.e., _pra._marid.a.example.com IN TXT "spf2.0/..."), that scope MUST also be present in the RDATA of the record: _pra._marid.a.example.com IN TXT "spf2.0/pra ...". Any information important to the interpretation of the record must not solely rest within the name, because of this wildcard issue. This is a general problem with DNS record subtyping and wildcards. To put this another way: clients, when querying for a TXT record using a prefix scheme MAY get back TXT records for different protocols and scopes, and must be able to pick the correct record from the set. > In my view this makes wildcards are bad choice for achieving scoping and > identity separation. That is unless we decide that we don't need to support > wildcards at all and in that case to avoid problems (as some will still > do it seeing how its possiblems), the document would have to specifically > say that you CAN NOT use wildcards or CAN NOT place records in anything > but the specified scope/identity prefix. What you are seeing is that prefixes (or subdomains, whatever) are a bad choice for *solely* dealing with scoping and identity separation. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 10:06: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 KAA00592 for ; Fri, 27 Aug 2004 10:06: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 i7RDhZaw015386; Fri, 27 Aug 2004 06:43: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 i7RDhZ1f015385; Fri, 27 Aug 2004 06:43:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDhYdD015368 for ; Fri, 27 Aug 2004 06:43:34 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-089-478.area3.spcsdns.net ([68.245.92.43]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0h0s-0004LX-SB; Fri, 27 Aug 2004 09:43:32 -0400 Message-ID: <412F3A71.3010302@solidmatrix.com> Date: Fri, 27 Aug 2004 09:43:13 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Andrew Newton CC: IETF MARID WG Subject: Re: on the topic of IPR References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> In-Reply-To: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > It is one of the jobs of co-chairs to facilitate discussion of working > group topics. Not that the issue of IPR is being debated lightly, > however we would like to raise a few discussion points that may have > been overlooked or given light treatment. > Andy, Perhaps you can explain to us how chairs are planning on deciding on the IPR issues, and what information should the WG members be providing? Should input of non-members such as ISPs be solicited? Are we taking RFC 3669 into account, especially the part about inability to have consensus on IPR issues? > - Many a message have been dedicated toward discussing the potential > abuse Microsoft may undertake while armed with a patent. However, there > has been little discussion regarding Microsoft's willingness and ability > (via deep pockets) to fend off counter patent claims. Should Sender ID > go forward with the acceptance of Microsoft's IPR, it leaves little > doubt that another entity claiming rights to such technology will have > to go through Microsoft to find remedy. However, if MARID were to > produce another standard such as Classic SPF or even CSV, who will > defend a legal claim against it? The problem that this will only happen if they get sued. For example, there are a bunch of patent holders currently suing various companies such as the JPEG patent, video streaming patent (Acacia), etc. We don't see Microsoft counter suing while they may have patents of their own (especially in regards to video). So relying on them to sue any potential counterclaimaints is a non-issue since they will not do so until provoked. In regards to possibilities of someone for SPF, that is always open. However, this is a normal risk that any standard faces. In addition, IMHO the reciprocal license only helps against companies that will use Sender-ID. Many patent trolls are simply shell companies that hold IPR and have no products, thus no helping with the license. Of course, I am not a lawyer, but the lawyers present can provide their take on that. > > - Some of the participants have speculated openly that Microsoft's IPR > claims might also cover the SPF syntax even though Microsoft has not > specifically attributed their claim to draft-ietf-marid-protocol. Given > that Microsoft's patent application and original IPR claim covered a > Caller ID document which used XML and not SPF, is this a reasonable > assumption? It should be noted that it was the MARID working group that > persuaded Microsoft to use the SPF syntax. Microsoft's first choice was > XML. > In my role as an ASRG co-chair, I formally submitted a request to the Microsoft's legal department on March 1st, 2004 asking whether their IPR claims extend to all the drafts that were the output of the ASRG and input to the MARID WG including RMX, DMP, SPF, MTA MARK, etc. I received a response from the legal department that my message was received. I discussed this in person with Harry Katz and George Webb at a conference, and I followed up by sending another email message to the legal department. My messages were acknowledged but no response, negative or positive, was ever received. It has been six months, and the lack of a simple "no" response, makes me suspicious. This also points to how slow the legal department is and that relying on them as the FAQ suggests might not be a good idea. On the other hand, Bob Atkinson who is the author of Caller ID showed up in the ASRG list in May of 2003 discussing RMX (http://www1.ietf.org/mail-archive/web/asrg/current/msg04333.html). Based on the content of those messages as well as other information, it seems to me that whatever IPR is being claimed cannot be older than that date. At that time the RMX draft was already published. Therefore, it would seem logical that PRA or XML might be the IPR in question. However, the problem with patents is once granted they are assumed valid until proven otherwise. So even if a patent somehow is granted on other aspects of Sender-ID by whomever, it will cost money and effort to disprove it. > - If it is reasonable to assume that Microsoft's patent application and > claimed IPR can and/or do reach beyond draft-ietf-marid-core and > draft-ietf-marid-pra, is it not the best course of action to take > Microsoft's offer of a royalty-free, nondiscriminatory and reasonable > license given that a rejection of Sender ID as a standard has no weight > on the standing of their claim. In other words, if it is believed that > their claim could cover other work product of MARID, then would not the > best course of action be to secure the best-possible license? > That I will grant you. > - On the issue of deployment, there have been many messages regarding > the adoption of Sender ID (as a note, the chair's instructions > specifically called for opinion about personal deployment and not > speculation as to the actions of others). While many believe that > Sender ID's encumbrances will slow adoption because it is not as > friendly as desired toward open source, it has been noted that Qmail > also has an equally or more unfriendly license toward open source yet is > one of the most popularly used MTAs. I am sorry Andy, but you are comparing apples and oranges. The main problem with this specific patent license is the fact that a signed agreement is required. DJB to my knowledge does not require that. The legal issues surrounding this patent license, as well as fear of letting a potential competitor know about your activities, privacy issues, revockability, etc. are all related specifically to this requirement. It is unfair to say that Qmail's license is more or equally restrictive since the comparison is not taking this specific point into account. Considering that the four open source MTAs (postfix, exim, qmail and sendmail) together constitute a majority of Internet MTAs, it is vital that a license on any email related technology takes the majority of deployed MTAs into account. And since lawyers have stated that this license is possibly incompatible with the licenses under which some of these are distributed, that might be detrimental to the overall deployment. Additionally, while I do not want to start war mongering against Microsoft, nevertheless Microsoft develops email software, and competes more heavily with open source software than most other companies, especially when marketing. Therefore, it is natural to assume that many parties would be naturally suspicious of Microsoft's intentions, especially in the light of the fact that this license may be incompatible with open source licenses. Therefore, people including my own company, would think twice before signing this license, especially when open source software is used. In closing, a quote from RFC 3669 (section 5.3): "The issue is not whether a particular piece of technology is IPR-impacted -- we use IPR-impacted technology every minute. The question is how much the IPR protection will limit the technology's usefulness in building a robust, highly useful Internet." Yakov From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 10:15: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 KAA01648 for ; Fri, 27 Aug 2004 10:15: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 i7RDqM8m017208; Fri, 27 Aug 2004 06:52: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 i7RDqML1017207; Fri, 27 Aug 2004 06:52:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDqMap017197 for ; Fri, 27 Aug 2004 06:52:22 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7RDqOcC027038 for ; Fri, 27 Aug 2004 06:52:24 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 27 Aug 2004 06:52:24 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MARID WG Subject: RE: on the topic of IPR Date: Fri, 27 Aug 2004 06:52: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: > I was one of those people who openly speculated about > Microsoft usurping SPF. From a PR standpoint I somehow doubt that Microsoft is going to be known primarily for having created SenderID in ten years time. There is a PR story here and it is a pretty good one, large corporation teams up with the leader of a grass roots effort to kill spam, IETF acts quickly to save the Internet. Now that story is not a 100% complete version of events, but it is something that the press can explain and can use to promote Sender-ID and get it deployed. And everyone comes out a hero - including the media. What is more everyone comes off as bigger heros than they do if they take the go it alone route. There is a lot to be said for co-opting an organization with a billion dollar marketing and publicity budget. Some of you will remember a project I worked on called the Web. The Web did not win the network hypertext game because it was the best system or had the best clients. There were many competitors. At one point the Web team all went up the road to Neuchattel and saw a demo of Hyper-G and came away asking what we could do to keep up. The Web won because it had smarter marketechture. I didn't spend two months selling the Web to the Clinton-Gore people on a whim, we knew that the Whitehouse was going online and whoever set the Whitehouse spec would set the industry spec. Tim's role in the Web was essentially the same as Meng's role setting up the SPF group or Linus with Linux. Keeping a bunch of techies together focused on a project is hard, much harder in fact than the technical issues. Sender-ID needs a powerful PR engine to draft behind. The IETF does not have one, at least not yet. Part of the idea here is to prove that the IETF is not as irrelevant and hopeless as its critics believe. To obtain a WS-Security license all you have to do is to fill in a Web form. Sure I do not like to have to do this just to visit the Washington Post or New York Times, but I am prepared to put up with a minor piece of inconvenience. I want Microsoft to be placed squarely in the firing line of all and any patent trolls that come after us. I have never had any difficulty with a piece of declared IPR, its the undeclared IPR owned by a law firm we should be worrying about. From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 10:18: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 KAA02102 for ; Fri, 27 Aug 2004 10:18:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDucFh017982; Fri, 27 Aug 2004 06:56: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 i7RDucx0017981; Fri, 27 Aug 2004 06:56:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDubDX017973 for ; Fri, 27 Aug 2004 06:56:37 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7RE51Rm027721; Fri, 27 Aug 2004 07:05:01 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7RE515V027718; Fri, 27 Aug 2004 07:05:01 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 27 Aug 2004 07:05:01 -0700 (PDT) From: "william(at)elan.net" To: David Blacka cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <200408270917.13412.davidb@verisignlabs.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, 27 Aug 2004, David Blacka wrote: > On Thursday 26 August 2004 7:07 pm, william(at)elan.net wrote: > > > In case we decide to have main record be located within subdomain prefix > > depending on the identity, then in order to achieve same effect with > > wildcards, we'd still have to place the record in root of the domain, i.e. > > a._marid_pra.example.com. IN TXT "v=spf1 ip4:192.168.0.0/16 ~all" > > *.example.com. IN TXT "v=spf1 ip4:10.0.0.0/8 ~all" > > You seem to be discussing a plan that I, at least, have not seen before. All > of the discussion that I have seen has been about actual *prefixes*, which > isn't what you are showing here. My mistake, that example was supposed to be _marid_pra.a.example.com. IN TXT "v=spf1 ip4:192.168.0.0/16 ~all" *.example.com. IN TXT "v=spf1 ip4:10.0.0.0/8 ~all" > To put this another way: clients, when querying for a TXT record using a > prefix scheme MAY get back TXT records for different protocols and scopes, > and must be able to pick the correct record from the set. Yes, exactly. > > In my view this makes wildcards are bad choice for achieving scoping and ^-- another typo, should have been subdomain/prefix > > identity separation. That is unless we decide that we don't need to support > > wildcards at all and in that case to avoid problems (as some will still > > do it seeing how its possible), the document would have to specifically > > say that you CAN NOT use wildcards or CAN NOT place records in anything > > but the specified scope/identity prefix. > > What you are seeing is that prefixes (or subdomains, whatever) are a bad > choice for *solely* dealing with scoping and identity separation. Basicly I'm saying that we can not rely on using prefixes for scoping separation unless we're certain that no wildcard records would exist (which is probably an impossible assumption) or otherwise we have a problem with different scoping records that use wildcards and we can not distinguish between. And since we can not achieve scoping by using prefix/subdomain system on its own, we have to include scoping identifier in the data part. But then we might as well just rely on the data part and create appropriate and extendeable scoping system there. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 10:18:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02117 for ; Fri, 27 Aug 2004 10:18: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 i7RDtQfx017784; Fri, 27 Aug 2004 06:55: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 i7RDtPcM017783; Fri, 27 Aug 2004 06:55:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDtOTW017770 for ; Fri, 27 Aug 2004 06:55:25 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 09:55:24 -0400 Message-ID: <412F3D4C.8090108@hepcoe.com> Date: Fri, 27 Aug 2004 09:55:24 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: on the topic of IPR References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> <412F228E.4070007@hepcoe.com> <220736D9-F828-11D8-9196-000A95B3BA44@hxr.us> In-Reply-To: <220736D9-F828-11D8-9196-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2004 13:55:24.0601 (UTC) FILETIME=[80436290:01C48C3D] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > On Aug 27, 2004, at 8:01 AM, Kevin Peuhkurinen wrote: > >> It makes no sense to say "here we have some verifiably homegrown IP >> with no encumberances and here we have some encumbered IP. Let's >> use the encumbered IP rather than the unencumbered IP because >> otherwise we might get sued by parties unknown". > > > Is there a connection between "verifiably homegrown" and patent claims? > Only in that by having "verifiably homegrown" technology posted publicly on the Internet, it would bolster our (hypothetical) case to get a patent claim dismissed. See below. > You are correct that the parties are unknown. If this were an arcane > subject area, it is most likely that they would remain unknown and > probably non-existent. However e-mail and electronic messaging and > anti-spam are hot areas of intellectual property. I did take a stroll > through the USPTO database and there are numerous, numerous patents in > this area. And these do not include the pending patents that cannot > be seen. > > Also, if company XYZ came forward tomorrow and claimed covering IPR, > should we ignore them? > I don't think it is valid to decide not to use a particular technology just because one day a patent claim may be made against it, at least as long as we are confident that there is no existing patents that cover it. As well, I don't think we could rely on IPR holders to necessarily sue Microsoft first. If the Eolas patent gets revoked, other IPR holders may decide that going after MSFT is too risky and may instead strong arm smaller developers and distributors into paying ongoing royalties instead. In any case, all of this is pure speculation on both of our parts. There is no company XYZ. If they showed up tomorrow and claimed IPR of course we couldn't ignore them, but until they do, they are purely hypothetical. What is fact is that we have been offered an IPR license which is plainly unacceptable to a large percentage of people here. I don't think you can argue around that by saying that if we don't accept it, something worse may come along later. > From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 10:29: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 KAA03179 for ; Fri, 27 Aug 2004 10:29: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 i7RE8DTe020560; Fri, 27 Aug 2004 07:08: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 i7RE8D8J020559; Fri, 27 Aug 2004 07:08:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RE8D7T020538 for ; Fri, 27 Aug 2004 07:08:13 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 27 Aug 2004 10:08:10 -0400 id 002E0A23.412F404A.000051CB From: David Blacka Organization: VeriSign, Inc. To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Fri, 27 Aug 2004 10:07:41 -0400 User-Agent: KMail/1.6.2 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: <200408271007.41617.davidb@verisignlabs.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday 27 August 2004 10:05 am, william(at)elan.net wrote: > On Fri, 27 Aug 2004, David Blacka wrote: > > What you are seeing is that prefixes (or subdomains, whatever) are a bad > > choice for *solely* dealing with scoping and identity separation. > > Basicly I'm saying that we can not rely on using prefixes for scoping > separation unless we're certain that no wildcard records would exist > (which is probably an impossible assumption) or otherwise we have a > problem with different scoping records that use wildcards and we can not > distinguish between. And since we can not achieve scoping by using > prefix/subdomain system on its own, we have to include scoping identifier > in the data part. But then we might as well just rely on the data part and > create appropriate and extendeable scoping system there. The motivation for using prefixes was (I thought) to ameliorate the response size issue when Sender-ID is deployed alongside SPFv1 (or other unrelated TXT records). Which it appears to do in all cases except the use of wildcards. The fact the the prefix technique does not work in all cases does not make it useless in my mind. So I agree with your statement except for the last sentence. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 11:07:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07491 for ; Fri, 27 Aug 2004 11:07:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REjjXk031943; Fri, 27 Aug 2004 07:45: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 i7REjjT5031942; Fri, 27 Aug 2004 07:45:45 -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 i7REjiUw031897 for ; Fri, 27 Aug 2004 07:45:44 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 66368 invoked by uid 1013); 27 Aug 2004 14:45:34 -0000 Date: Fri, 27 Aug 2004 16:45:34 +0200 From: Markus Stumpf To: Chris Haynes Cc: IETF MARID WG Subject: Re: TECH-OMISSION: Divergent assumptions about objectives Message-ID: <20040827144534.GF30023@Space.Net> References: <111001c48be5$ebaa1360$0200000a@ringo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <111001c48be5$ebaa1360$0200000a@ringo> 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 Fri, Aug 27, 2004 at 04:28:23AM +0100, Chris Haynes wrote: > I would imagine that major banks etc. are, quite properly, 'encouraging' > Microsoft to find a reliable way to show users that messages really are from the > purportedly-responsible organization. http://weblog.infoworld.com/udell/2004/03/23.html \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 Fri Aug 27 11:11: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 LAA07986 for ; Fri, 27 Aug 2004 11:11: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 i7REpTk5032528; Fri, 27 Aug 2004 07:51: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 i7REpTkB032527; Fri, 27 Aug 2004 07:51:29 -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 i7REpRme032514 for ; Fri, 27 Aug 2004 07:51:28 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 68596 invoked by uid 1013); 27 Aug 2004 14:51:29 -0000 Date: Fri, 27 Aug 2004 16:51:29 +0200 From: Markus Stumpf To: "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: Re: on the topic of IPR Message-ID: <20040827145129.GG30023@Space.Net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 27, 2004 at 06:52:15AM -0700, Hallam-Baker, Phillip wrote: > From a PR standpoint I somehow doubt that Microsoft is going to > be known primarily for having created SenderID in ten years time. Hmmm ... from my memory (backuped by the list archives and news articles in the Internet) Microsoft created Caller-Id. Sender-Id is the work of the IETF MARID group and not Microsoft. It is very funny ro read even in this list and in news articles that Microsoft created Sender-Id, which is simply wrong. Also in the patent claims Microsoft talks about Sender-Id as their invention. Sender-Id is *at best* a derivate work which borrows some ideas of Caller-Id. \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 Fri Aug 27 11:35: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 LAA10074 for ; Fri, 27 Aug 2004 11:35: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 i7RFBA36034173; Fri, 27 Aug 2004 08:11: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 i7RFBAKb034172; Fri, 27 Aug 2004 08:11: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 i7RFBAZq034166 for ; Fri, 27 Aug 2004 08:11:10 -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 i7RFBCY06370; Fri, 27 Aug 2004 08:11:12 -0700 Date: Fri, 27 Aug 2004 08:11:07 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <3910195605.20040827081107@brandenburg.com> To: Andrew Newton CC: IETF MARID WG Subject: Re: on the topic of IPR In-Reply-To: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> References: <970CDC76-F816-11D8-9196-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> - Many a message have been dedicated toward discussing the potential AN> abuse Microsoft may undertake while armed with a patent. However, AN> there has been little discussion regarding Microsoft's willingness and AN> ability (via deep pockets) to fend off counter patent claims. Should AN> Sender ID go forward with the acceptance of Microsoft's IPR, it leaves AN> little doubt that another entity claiming rights to such technology AN> will have to go through Microsoft to find remedy. However, if MARID AN> were to produce another standard such as Classic SPF or even CSV, who AN> will defend a legal claim against it? My primary reactions to this paragraph and the comments in response to it is that it is distracting and that this group is not particularly competent to pursue it. (The idea that we should be more comfortable with knowing of an encumbrance and that it has deep pockets to defend it, than with proposals that have unknown encumbrance and no known pockets to defend it, strikes me as clever but pretty bizarre. Think of the implications for all other IETF work...) As has been noted, the fact that something is not currently identified as being encumbered does not mean that something won't surface later. (That's why they are called submarine patents.) I am used to seeing IETF working groups deal with what is in front of them. I am used to seeing IETF working groups get thoroughly bogged down, when they try to explore abstract hypotheticals, particularly when they involve social issues, such as the law. When companies assert IPR for work in the IETF, I am used to seeing rather simple questions pursued: Are the terms for use of the IPR acceptable to the community and does the community think it likely that the company will act in good faith? I have mostly been finding the extensive debate about 'the open source' requirements to be a bit odd, in terms of the IETF requirements. Useful input, perhaps, but hardly definitive. Microsoft has iterated their IPR documents. The changes have been significant. If anything, I find it reassuring that they are clear about their limits and that those limits seem to fall within the range of limits this community has accepted from others. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 12:06: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 MAA12322 for ; Fri, 27 Aug 2004 12:06: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 i7RFgDqo037504; Fri, 27 Aug 2004 08:42:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RFgDIP037503; Fri, 27 Aug 2004 08:42:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RFgCVE037479 for ; Fri, 27 Aug 2004 08:42:12 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 15:42:07 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: RE: TECH OMISSION: Stronger checks against email forgery Date: Fri, 27 Aug 2004 09:42:07 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAC52@df-fido-msg.exchange.corp.microsoft.com> Importance: Normal X-OriginalArrivalTime: 27 Aug 2004 15:42:07.0456 (UTC) FILETIME=[68A98600:01C48C4C] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jim Lyon wrote: >2. bounce address tells you who wants to know if the message isn't >delivered. It's also irrelevant when deciding whether the MTA is >authorized to act of behalf of the name mentioned in the message he's >sending. The (2821 MAIL FROM) bounce address is irrelevant? This seems absurd considering how many bounces (containing spam and viruses) I get for messages I never sent. They are a *means* (not just a result) of delivering messages, and exploited widely. Several viruses and spammers intentionally use the method of bouncing to get their messages around filters and blacklists. And (even worse), the volume and content of bounce-related messages I currently receive overwhelm my ability to detect when an honest bounce occurs. Just a couple days ago, I found that a certain ISP has been incorrectly blacklisting one of my MTA's IP addresses for weeks, but it wasn't noticed because the DSNs were buried with all the spam/virus DSNs. It appears that the bounce address attack scenarios against SenderID that I and others (Shevek and Mark Shewmaker to name a few) brought to the attention of this list have been ignored. Instead of modifying SenderID to solve these problems, the problem is now "irrelevant". How convenient. The MAIL FROM bounce address IS relevant. SenderID doesn't protect the bounce address adequately, and it amazes me that people are arguing over the IPR of a technology that is so obviously flawed in this respect. Preventing forgery involves several levels: First, protect the transfer agents: turn off open relaying, use AUTH, maybe CSV Second, protect the envelope: via technologies like SPF or RMX Finally, protect the message and header: via crypto signing like SMIME or DomainKeys The first levels are the least expensive to perform but provide the least protection. The last levels are the most expensive, and work best if the earlier levels are already implemented. Because SenderID tries to cheat the last two steps, it uses envelope checks on the message header and appears to protect neither. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 12:18:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13030 for ; Fri, 27 Aug 2004 12:18: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 i7RFsriW038456; Fri, 27 Aug 2004 08:54:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RFsrmF038455; Fri, 27 Aug 2004 08:54:53 -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 i7RFsqAW038445 for ; Fri, 27 Aug 2004 08:54:52 -0700 (PDT) (envelope-from kent@raven.songbird.com) Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7RFstY09229 for ; Fri, 27 Aug 2004 08:54:55 -0700 Received: from raven.songbird.com (localhost [127.0.0.1]) by raven.songbird.com (8.12.11/8.12.10) with ESMTP id i7RFstAK014938 for ; Fri, 27 Aug 2004 08:54:55 -0700 Received: (from kent@localhost) by raven.songbird.com (8.12.11/8.12.11/Submit) id i7RFstP8014937 for ietf-mxcomp@imc.org; Fri, 27 Aug 2004 08:54:55 -0700 Date: Fri, 27 Aug 2004 08:54:55 -0700 From: kent crispin To: IETF MARID WG Subject: Re: on the topic of IPR Message-ID: <20040827155455.GR6771@raven.songbird.com> Mail-Followup-To: IETF MARID WG 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: On Fri, Aug 27, 2004 at 06:52:15AM -0700, Hallam-Baker, Phillip wrote: > From a PR standpoint I somehow doubt that Microsoft is going to > be known primarily for having created SenderID in ten years time. > > There is a PR story here and it is a pretty good one, large > corporation teams up with the leader of a grass roots effort > to kill spam, IETF acts quickly to save the Internet. There are numerous possible PR stories here. Another example might be "IETF grants major competitive advantage to Large Corporation". Or perhaps "IETF makes stand against open source software". Stories like these are just as likely -- we've already seen some, in fact. > Now that story is not a 100% complete version of events, but > it is something that the press can explain and can use to > promote Sender-ID and get it deployed. I'm not sure how much effect the press will actually have on the deployment. > What is more everyone comes off as bigger heros than they do > if they take the go it alone route. Being aclaimed a hero in the press doesn't motivate me, to tell you the truth. If Sender-ID were compelling technology that would clearly work, it might be worth it. But it's not at all clear that it will actually accomplish what it claims. > There is a lot to be said for co-opting an organization with > a billion dollar marketing and publicity budget. From another point of view: There is something to be said for co-opting a well-known standards organization to get its name behind your trivial technology. [...] > Sender-ID needs a powerful PR engine to draft behind. The IETF > does not have one, at least not yet. Part of the idea here is > to prove that the IETF is not as irrelevant and hopeless as > its critics believe. I can't help but think that the IETF racing to approve a standard because of its PR value is actually more damaging. Speaking just for myself, of course... -- Kent Crispin kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.com From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 12:42: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 MAA14967 for ; Fri, 27 Aug 2004 12:42: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 i7RGJ6YW040582; Fri, 27 Aug 2004 09:19: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 i7RGJ66T040581; Fri, 27 Aug 2004 09:19:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGJ54Y040575 for ; Fri, 27 Aug 2004 09:19:05 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7RGRVfp006378 for ; Fri, 27 Aug 2004 09:27:31 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7RGRV6v006374 for ; Fri, 27 Aug 2004 09:27:31 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 27 Aug 2004 09:27:31 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID WG Subject: TECH ERROR: ietf-marid-core - problems with MUA determenining PRA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In section 2.1 it is written that: (*1*) "As seen from the question, this mechanism applies to unrelated parties: it is useful at the point where a message passes across the Internet from one organization to another. It is beyond the scope of this document to describe authentication mechanisms that can be deployed within an organization." Clearly the distinction is made that the mechanisms of MARID athentication and determining PRA should only be performed on the network boundaries during SMTP transmission between different ISPs and not within the same network. But previously in section 1 it states that: (*2*) "This document describes a mechanism such that receiving MTAs, MDAs and/or MUAs can recognize mail in the above category and take appropriate action. For example, an MTA might refuse to accept a message, an MDA might discard a message rather than placing it into a mailbox, and an MUA might render that message in some distinctive fashion" It is notable that MUAs and MDAs are mentioned here as devices that would and should be involved in MARID authentication system and could potentially filter the bad messages. While not totally true in all cases, in majority of situations MUA can be said to be located within same organization or network as location of user mailbox (which is where MDA delivers the message) as such the previous mail delivery preceeding MUA would be within same organozation. Similarly MDA may also not be on network boundary but maybe futher steps away from incoming mail server gateway for that organization. So we are expecting devices not located on the network boundary to perform MARID authentication and filtering which directly contradicts previously mentioned section (*1*). The same section 2.1 futher (right after *1*) states that: (*3*) "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. In simple cases, this is who the mail is from. 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." It is unclear from the document if in case of MUA or MDA (if it is not located on the network boundary) if the "MOST RECENT introduction of a message into the mail delivery system" refers to the server immediatly proceeding in email path (the mailbox location server in case of MUA or gateway mail server in case of MDA) or the outgoing mail server of the network that proceeded this (which by the text of ietf-marid-core document would be the only step in email transmission that protocol should be trying to secure). I'm going to assume that since the ip address of the connection is within same network we can not be talking about authentication server that is outside and several hops away and that MDAs are expected to do MARID authentication ONLY IF it sits on network boundary and message is coming from outside the current network. In such a case, this should be explicitely stated to avoid any confusion. However this brings us back to MUA which is receiving the message from server within same network and which does not participate in SMTP transmission at all and clearly can not see ip address of SMTP client or see parameters of email envelope including new SUBMITER parameter described in ietf-marid-submitter draft. So MUA is somehow expected to be able to identify PRA that was used in "MOST RECENT introduction of a message into the mail delivery system" and somehow expected to identify ip address of the smtp client at that time. The problems can possibly be resolved by having MUA lookup client ip address in the Received header, but to my knowledge Received header has not been standartized and there is no requirement for SMTP server to insert into it ip address of the client (although many do). Additionally Received headers are regularly forged and relying on it might allow for a way to assert certain PRA as correct (as would be seen by MUAs and thus by end-users) when in fact its not. Going futher in the document I see another mention about what MUA should do: (*4*) "When displaying a received message, an MUA SHOULD display the purported responsible address as defined by this document whenever that address differs from the RFC 2822 From address. This display SHOULD be in addition to the RFC 2822 From address." (*5*) "When a received message contains multiple headers that might be used for the purported responsible address determination, an MUA should consider displaying all of them. That is, if a message contains several Resent-From's, a Sender and a From, an MUA should consider displaying all of them." First of I immediatly note that PRA is now defined in different draft and referenced in first paragraph should be to that draft instead of "this document". The PRA draft has very specific rules on how to determine PRA. Those rules should in theory lead to finding the same PRA that would have been used by last SMTP server that checked it. But we don't actually know if such SMTP server ever did check PRA nor do we know ip address of the SMTP client that such SMTP server should have verified by means of CallerID algorithm to be able to confirm that message is "safe". Additionally I note going back to the beginning (see *1*) that purpose of the SenderID is to authenticate servers within different organization but the PRA seen by MUA might well be based on the server information within same organization if it had several servers on the receiving side For example if when email was received by gateway server and was forwarded to another server and only then to MDA, intermediate servers might have added their own "Resent-From" header (within same organization network) and this would alter PRA as seen by MUA and this new PRA no longer represents address of who was responsible for transmitting email to the current network which as per *1* is what we should be focusing on. The above two problems means that PRA displaed to the user in MUA as proposed by the draft can not be relied to have been verified, nor can it be certainly established that it represents an address of the outside organization responsible at some point for delivery of email. This means this PRA displayed to end-user has minimum value (no more so then unverified "From:" header) and likely would onlyconfuse such end-users (in particular if recomendation in *5* is followed and many different "Resent-From" and "Sender" addresses are all displayed to end-users). I note that this is a very fundamental issue. The whole purpose of Caller-ID was to authenticate address as it is seen by end-user in MUA. But if it turns out that MUA can not be certain that address it is displaying has been authenticated or not, then what value does invention of this new address field has and that of entire algorithm? --------------------------------- As to the way around the above problems, I remind that original SPF has new SPF-Received header which is used so that server doing authentication could log ip address of the client it authenticated, what was the email address it authenticated as well as results (pass, fail, neutral, etc...). Its possible that the way around is to use the same mechanism and require that MUAs display PRA field only if it can find it in the top-most "MARID Received" header and only if MUA can be certain that such header has been added by MTA that is on the same network as MUA itself. Also large portions of the draft that are dealing with MUAs and MDAs doing authentication and filtering should be rewritten. It should be made clear that authentication and message rejection based on PRA can only reliably be done during SMTP email transmission (authenticating connecting SMTP client) and not by any device afterwards. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 12:47: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 MAA15300 for ; Fri, 27 Aug 2004 12:47:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGRKim041215; Fri, 27 Aug 2004 09: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 i7RGRKC2041214; Fri, 27 Aug 2004 09:27:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGRIfC041202 for ; Fri, 27 Aug 2004 09:27:19 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 16:27:17 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: FW: on the topic of IPR Date: Fri, 27 Aug 2004 10:27:16 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-OriginalArrivalTime: 27 Aug 2004 16:27:17.0340 (UTC) FILETIME=[B7E101C0:01C48C52] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Kevin Peuhkurinen wrote: > It makes no sense to say "here we have some verifiably homegrown IP > with no encumberances and here we have some encumbered IP. Let's use > the encumbered IP rather than the unencumbered IP because otherwise we > might get sued by parties unknown". Andrew Newton wrote: >Is there a connection between "verifiably homegrown" and patent claims? > >You are correct that the parties are unknown. If this were an arcane >subject area, it is most likely that they would remain unknown and >probably non-existent. However e-mail and electronic messaging and >anti-spam are hot areas of intellectual property. I did take a stroll >through the USPTO database and there are numerous, numerous patents in >this area. And these do not include the pending patents that cannot be >seen. > >Also, if company XYZ came forward tomorrow and claimed covering IPR, >should we ignore them? Ok, so now we have the *FEAR* of existing patents, the *UNCERTAINTY* of future patents, and the *DOUBT* that the IETF and free/open source communities could defend against the possible onslaught of submarine patents. Sounds to me like a good reason to go with Microsoft. We all know they have our best welfare at heart, and they will protect us against this FUD. We have at least one technology (SPF) which is in the public domain, is superior at solving the problem this working group was chartered to solve, and is widely deployed and tested on all the major MTAs. So, why are we spinning our wheels with an privately owned IP which is encumbered by an onerous license, doesn't appear to solve the problem, and has never been deployed or tested on any MTA? Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 13:28: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 NAA17820 for ; Fri, 27 Aug 2004 13:28: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 i7RH5q7J044478; Fri, 27 Aug 2004 10:05: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 i7RH5qNc044477; Fri, 27 Aug 2004 10:05:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RH5qKW044471 for ; Fri, 27 Aug 2004 10:05:52 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 13:05:55 -0400 Message-ID: <412F69F2.9070403@hepcoe.com> Date: Fri, 27 Aug 2004 13:05:54 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Exim, GPL, and IPR Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Aug 2004 17:05:55.0027 (UTC) FILETIME=[1D53FA30:01C48C58] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I submit, for your consideration, the following: The Microsoft IPR license is incompatible with the GPL. This is not disputed by Microsoft and has been attested to by Eben Moglen. This means that GPL'ed software will not be able to include Sender-ID code. Exim is software that is released under the GPL. So how important is Exim? A quick search reveals that, among many many others, the following ISPs use Exim: earthlink.net, inter.net, csolve.net, parasun.net look.ca, global.net.uk, xmission.net demon.net, shore.net, pol.co.uk t-online.net, freenet.de, uk2.net direct.ca, kundenserver.de, powercom.net psi.net, atlantech.net , net4india.com uksolutions.net, zen.co.uk, liquenox.net blueyonder.net, rcn.net, mec.net Also, among many others, the following educational facilities use Exim: Youngstown State University, Imperial College London, University of Central Florida Cambridge University, Loughborough University, MIT Cranfield University, University of Bath, Harvard University University of Manchester, Oxford University, University of Texas University of Utah, University of East Anglia, University of Hawai‘i University College London, University of Essex, University of Houston University of Sheffield, Lander University, California State University, University of California, University of Northern Iowa, University of Toronto University of Oregon, University of Illinois, Florida State University As Sender-ID relies on rapid adoption, and there are so many major ISPs and Universities that will not be able to adopt it without changing their MTA, I just don't see how anyone could endorse Sender-ID. The GPL issue is going to hamstring widespread adoption. Kevin From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 13:40:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18558 for ; Fri, 27 Aug 2004 13:40: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 i7RHIJhX045278; Fri, 27 Aug 2004 10:18:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RHIJec045277; Fri, 27 Aug 2004 10:18:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHIH1x045267 for ; Fri, 27 Aug 2004 10:18:18 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7RHH9t0002304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Aug 2004 13:17:12 -0400 Subject: Re: on the topic of IPR From: Paul Iadonisi To: IETF MARID WG In-Reply-To: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1093626986.7023.22.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 27 Aug 2004 13:16:26 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-27 at 06:48, Andrew Newton wrote: [snip] > - If it is reasonable to assume that Microsoft's patent application > and claimed IPR can and/or do reach beyond draft-ietf-marid-core and > draft-ietf-marid-pra, is it not the best course of action to take > Microsoft's offer of a royalty-free, nondiscriminatory and reasonable > license given that a rejection of Sender ID as a standard has no weight > on the standing of their claim. In other words, if it is believed that > their claim could cover other work product of MARID, then would not the > best course of action be to secure the best-possible license? To the above, absolutely not. If, in fact, the IPR claims extend beyond what the holder has contributed, then I don't know how anyone can continue to say that the IPR holder has done us any favors. Patenting someone else's work should not be rewarded in any way. I know a lot of work has gone into these drafts. But too often I find in other venues that people are simply unwilling to give up on a design, a product, an elegant hack, whatever, because it took so much effort to reach that point. Even it is clear that that is what should be done. Starting over is not fun. But if it is determined that the IPR hinders adoption seriously -- and I gave a specific example of how would hinder my own adoption -- then it is serious enough that it needs to either be dropped, or the IPR holder needs to be persuaded to come up with a better license. Or in this case, both: drop it for now, and reconsider it later if the IPR holder comes up with a better license. One that satisfies both proprietary and FOSS licensed products. We now have two expert opinions from prominent lawyers in the FOSS arena that state clearly that this license is not satisfactory. > - On the issue of deployment, there have been many messages regarding > the adoption of Sender ID (as a note, the chair's instructions > specifically called for opinion about personal deployment and not > speculation as to the actions of others). While many believe that > Sender ID's encumbrances will slow adoption because it is not as > friendly as desired toward open source, it has been noted that Qmail > also has an equally or more unfriendly license toward open source yet > is one of the most popularly used MTAs. This discussion has confused me. Qmail is not a standard. Refusing to use qmail because of the license (my primary reason) does not make one a second class internet citizen of sorts. There are many other SMTP implementations out there licensed under more favorable terms such as the GPL and BSD licenses. But a patent license is different. *Every* implementation of Sender-ID needs to execute a license. Because this is on a standards track, every SMTP server will need to implement Sender-ID. That in turn will require Exim, Courier-MTA, and PowerMail to either change their licenses (an entirely unacceptable solution for most) or become second class citizens because they cannot implement Sender-ID. === On the issue of the IPR holder coming to the defense of those who implement Sender-ID, the FOSS community doesn't need it, or I would guess, even want it. What needs to happen is for efforts like that of the Public Patent Foundation and others like it to get more broad support. But that's a topic for another forum. I'm also boggled that you are endorsing the kind of vagueness that many of us are trying to get some clarification on. If the IPR holders claims extend beyond -core and -pra, then we want answers. We don't want so-called 'favorable' license terms 'just in case'. That sounds like it comes from another, unnamed software vendor who still thinks the the Linux using world should take out a license with them 'just in case'. It borders on extortion. Software patents cause enough problems. Lets not make it worse by endorsing the licensing of unspecified technology that someone *might* have IPR claims over. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 13:44: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 NAA18902 for ; Fri, 27 Aug 2004 13:44: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 i7RHH5JM045215; Fri, 27 Aug 2004 10:17: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 i7RHH57W045214; Fri, 27 Aug 2004 10:17:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHH5fu045207 for ; Fri, 27 Aug 2004 10:17:05 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 27 Aug 2004 13:17:06 -0400 id 001976BC.412F6C92.000001DD In-Reply-To: <412F3A71.3010302@solidmatrix.com> References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> <412F3A71.3010302@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: on the topic of IPR Date: Fri, 27 Aug 2004 13:17:05 -0400 To: Yakov Shafranovich X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 9:43 AM, Yakov Shafranovich wrote: > Perhaps you can explain to us how chairs are planning on deciding on > the IPR issues, and what information should the WG members be > providing? While there is no formula, input such as yours is definitely an example others should follow. > Should input of non-members such as ISPs be solicited? That is fine, but they should speak for themselves. > Are we taking RFC 3669 into account, especially the part about > inability to have consensus on IPR issues? I do not understand the question. However, RFC 3669 is an excellent document and everybody should read it. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 13:54: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 NAA19450 for ; Fri, 27 Aug 2004 13:54:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHTV00046099; Fri, 27 Aug 2004 10:29: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 i7RHTVMC046098; Fri, 27 Aug 2004 10:29:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHTUtK046092 for ; Fri, 27 Aug 2004 10:29:30 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 13:29:33 -0400 Message-ID: <412F6F7D.6070101@hepcoe.com> Date: Fri, 27 Aug 2004 13:29:33 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" , IETF MARID WG Subject: Re: on the topic of IPR References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2004 17:29:33.0899 (UTC) FILETIME=[6B0AA9B0:01C48C5B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: >The Web won because it had smarter marketechture. I didn't >spend two months selling the Web to the Clinton-Gore people >on a whim, we knew that the Whitehouse was going online and >whoever set the Whitehouse spec would set the industry spec. > > > It's certainly true that superior marketing often allows inferior technology to triumph over rivals. I can think of one company that has proven that time and time again. However, I don't see how that really applies to this situation, unless you believe that if MARID adopts ClassicSPF over Sender-ID that Microsoft would ignore the IETF and push Sender-ID anyway, which would be a real shame. Has MS given any inclination that they will respect MARID regardless of what it produces? >... >I want Microsoft to be placed squarely in the firing line of >all and any patent trolls that come after us. I have never >had any difficulty with a piece of declared IPR, its the >undeclared IPR owned by a law firm we should be worrying about. > > > > Again with the fear. If we cower from adopting a great technology based solely on fear of some future threat, then the IP terrorists have already won. From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 14:10: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 OAA20490 for ; Fri, 27 Aug 2004 14:10: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 i7RHg958046926; Fri, 27 Aug 2004 10:42: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 i7RHg9xY046925; Fri, 27 Aug 2004 10:42: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 i7RHg8fT046917 for ; Fri, 27 Aug 2004 10:42:09 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 29655 invoked from network); 27 Aug 2004 17:43:56 -0000 Received: from unknown (HELO ?192.168.254.133?) (208.198.98.24) by ns1.hoster907.com with SMTP; 27 Aug 2004 17:43:56 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <93C5D480-F7FB-11D8-8AD0-000A95AC5778@isipp.com> References: <93C5D480-F7FB-11D8-8AD0-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6B8BC87E-F850-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit From: Margaret Olson Subject: Re: acceptable licenses (Was: Can there be an early decision on t he SenderID license?) Date: Fri, 27 Aug 2004 13:42:09 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 3:34 AM, Anne P. Mitchell, Esq. wrote: > I agree completely with Larry Rosen, and several others, that the > entire scheme vis the license is problematic. The *reason* it is > problematic is that while, yes, it allows unlimited use by *end > users*, as soon as someone tries to modify it for their own purpose, > and then share that modification with others for the good of and > widespread adoption throughout the industry, there's a "gotcha". In > fact, I would argue that the same concern applies to end-users - what > if the end-user wants to tweak the code themselves? If they want to > then share that modified implementation they could find themselves on > the wrong end of an MS lawsuit. It's all about control. You can't > really blame MS for wanting to retain this sort of control - but I > would suggest that it's antithetical to the real goal here. An > authentication system to be uniformly adopted across the industry is > *not* the same as an authentication system to be uniformly adopted > across the industry which is essentially *owned* by one very large > ISP. Having an ISP - particularly one of the 800 pound gorillas - own > the ultimate commercial (and that's what it is, commercial) rights to > the one true authentication system is like having a large marketing > company own the IP rights to the one spam filter in use across the > industry. > > What happens when Earthlink comes up with a better way to both > implement and check for Sender I.D., which ends up giving it a > competitive edge over Hotmail and MSN in the spam performance arena? > (And make no mistake about it - at this point in time, spam/anti-spam > performance at national ISPs is very much all about a competitive > marketing edge.) Remember, this is the same company that threatened > Slashdot and demanded that they remove user postings because the users > had quoted a *public* Microsoft document 'in violation of their > copyright'. > > Of course, this is something which I and many others have been saying, > and predicting, all along. That as soon as MS started courting Meng, > it tolled the death-knell for the open-source potential of SPF, which > is what made SPF so attractive in the first place. > > In my opinion what we need is a SenderID/SPF-clone which is truly > open-source, and which doesn't itself violate the inevitable Microsoft > IP claims. You can be reasonably sure that MS' plan all along was to > rule this market, and that's exactly where they are headed, with the > blessing of a surprising number of people. The race for a winning > authentication protocol among the majors was never altruisitically > about authentication first - it was always about market domination - > and it was a shrewd, but blatant, move on MS' part to dance with Meng > and end up subsuming SPF. > My problem with this line of reasoning is that any spam reduction mechanism is going to have IPR claims - by either the genuine inventors or someone else. There are multiple patent claims on challenge response. I am not comfortable with the idea that we reject a technology because the IPR holder has deep pockets. As far as I can tell, that the IPR is held by Microsoft remains the primary objection, and I can't see that as a valid objection. I would also argue that there is a control advantage to making Sender ID an IETF standard. It makes it much harder for Microsoft (or anyone else, for that matter) to make arbitrary revisions. Whether or not this matters depends on whether you think it will get widespread adoption. I think it will, and that most of us are going to wind up dealing with it regardless of the IETF decision. Do we prefer an IETF standard or a de-facto standard? Of course, if adoption is widespread and rapid enough it will be difficult for anyone to change regardless of the size of the gorillas. Margaret. From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 14:21: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 OAA21294 for ; Fri, 27 Aug 2004 14:21: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 i7RI1gsd047811; Fri, 27 Aug 2004 11:01: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 i7RI1gGQ047810; Fri, 27 Aug 2004 11:01:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RI1feS047796 for ; Fri, 27 Aug 2004 11:01:41 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-072-158.area3.spcsdns.net ([68.245.24.199]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C0l2i-0000wq-5L; Fri, 27 Aug 2004 14:01:43 -0400 Message-ID: <412F76F6.5040406@solidmatrix.com> Date: Fri, 27 Aug 2004 14:01:26 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: IETF MARID WG Subject: Re: on the topic of IPR References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > >>I was one of those people who openly speculated about >>Microsoft usurping SPF. > >>From a PR standpoint I somehow doubt that Microsoft is going to > be known primarily for having created SenderID in ten years time. > As Markus Stumpf pointed out, Microsoft created Caller-ID, while Sender-ID is the product of this group. Also, Caller-ID itself is based on the SPF which is based on RMX and DMP plus discussions in the ASRG, which in turn are based on the ideas of Paul Vixie, and others. But I am digressing. > There is a PR story here and it is a pretty good one, large > corporation teams up with the leader of a grass roots effort > to kill spam, IETF acts quickly to save the Internet. > > Now that story is not a 100% complete version of events, but > it is something that the press can explain and can use to > promote Sender-ID and get it deployed. And everyone comes out > a hero - including the media. > > What is more everyone comes off as bigger heros than they do > if they take the go it alone route. > In the context of what we are trying to determine, this is important as far as it can help in deployment. PR by itself might not matter, but if it leads to faster deployment, then it is a large plus. If large ISPs commit to deployment, thats another plus also. > > To obtain a WS-Security license all you have to do is to fill > in a Web form. Sure I do not like to have to do this just to > visit the Washington Post or New York Times, but I am prepared > to put up with a minor piece of inconvenience. > There is a crucial difference here. WS-Security, and many other standards out there are not nearly as prevalent and largely used as email standards are. The only things that have similar market effects is the Eolas patent and the TCP/IP security IPR issues with Cisco. The problem is that the amount of people needed to be convinced, and the amount of people bothered by this minor inconvenience, as well as the possible problems integrating this into open source MTAs which run majority of the Internet's email, is a by far much larger than most similar occurances to date. The question we should be asking is whether this inconvenience big enough to cause problems with deployment. As RFC 3669 puts it: "... terms can make a technology unusable even if it is perfect otherwise" > I want Microsoft to be placed squarely in the firing line of > all and any patent trolls that come after us. I have never > had any difficulty with a piece of declared IPR, its the > undeclared IPR owned by a law firm we should be worrying about. > I really don't understand this logic nor do I understand the logic of why this license is being insisted on. Eolas went after Microsoft not because of a patent that Microsoft had, but rather because they made a web browser. Simply developing Exchange and Hotmail, in lieu of any patents will make Microsoft a large and juicy target for IPR. Therefore, what has placed Microsoft in the firing line is their involvement in email, not their patents. Even if they would not have filed a patent application, some troll patenting RMX or SPF, would have a field day anyway. Additionally, IMHO the reciprocal license will not help either, since a lot of the patent trolls maybe law firms or not even in the email business (for example, Eolas does not make web browsers). The reciprocal license does not protect Microsoft from claims of some law firm or shell company that comes and sues for patent infringement. Therefore, saying that the reason for requiring the license is to protect from patent trolls, as Harry said during the meeting in San Diego, is illogical. It would be helpful if Microsoft can elaborate as to why they are insisting on such license. Therefore, I don't understand why Microsoft is insisting on such license. Considering that it may seriously hinder deployment as several people have testified, it would make more sense that a license without a requirement to sign an agreement is issued. If the patent trolls will come, the license will not stop them anyway but the patent might. This way Microsoft can have its cake and eat it to. Yakov From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 14:27:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21672 for ; Fri, 27 Aug 2004 14:27:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RI6VSu048103; Fri, 27 Aug 2004 11:06: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 i7RI6VWJ048102; Fri, 27 Aug 2004 11:06:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RI6VMU048075 for ; Fri, 27 Aug 2004 11:06:31 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id E4D7A414CA for ; Fri, 27 Aug 2004 11:06:30 -0700 (PDT) Subject: TECH-ERROR: Misuse of DNS Records From: Douglas Otis To: MARID Content-Type: text/plain; charset=iso-8859-13 Message-Id: <1093629989.5542.9.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 27 Aug 2004 11:06:29 -0700 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Overview: The Protocol draft mandates a minimum of 10 DNS text script macro evaluations. These scripts may reference any number of A, AAAA, MX, PTR, TXT, and SPF2 resource record types. The many functions implemented by these scripts include error message construction, mailbox local-part address evaluation, label construction, among others, to provide features well beyond the basic assessment of the PRA mailbox domain. The scripting definitions also mandate bypassing extended functions and features beyond what is defined for the record revision. Should the number of scripts linking to other scripts exceed a majority, the total number of scripts becomes unbounded. Linked text scripts to separately administered domains runs a risk of the aggregate increasing unexpectedly beyond a total allowed. The Protocol draft also allows for ´open-ended¡ definitions by appending notation such as ´+all¡ or ´?all¡ to allow a differentiation of messages inside a prescribed mail channel from those outside. This notation requests messages outside the prescribed channel be accepted ´as if¡ they were inside, or accepted ´as if¡ there were no records available, respectably. This differentiation assumes messages are not being relayed on the outbound path through shared MTAs, but this is not clarified in the draft. This notation allows for a common use where the entire record set must be evaluated, to arrive at the result. The Protocol draft does not prevent use of wildcards. One motivation for the use of wildcards would be to mirror a similar technique used for MX records. The other motivation would be to provide an evaluation of ´-all¡ for all undefined sub-domains, possibly to differentiate results from records that provided ´?all¡ results. A common ploy used by spammers is to include several randomly generated sub-domains that reference a wildcard DNS record. Should a domain use wildcard records and offer ´open-ended¡ results by appending ´?all¡, as example, then references to this record will always result in a ´neutral¡ result, but each new reference to what amounts in the access of the same record will invoke new query wasting the DNS cache, and consuming time that may have been saved, had the record not employed a wildcard technique. Problem: The draft also allows truncation of the DNS query process at 20 seconds per script for an aggregate minimum of 200 seconds allotted for this process. The resulting DNS lookups to resolve the content of the text script could invoke a sequence of dozens of record lookups that may also link to other text script records. The normal timeout for initial DNS queries is 5 seconds. Each timeout then invokes an doubling (exponential increase) in the timeout period. It is not unusual for there to be a 5% packet loss rate for intensive DNS use. A 20 second limit may not allow a recovery following any packet loss and could lead to a reduction of the communication integrity. The amount of DNS traffic could be relatively high, even assuming a 80% cache hit rate should these records grow to even half of the allowed size. With a higher UDP prevalence, the packet loss rate will increase as UDP does not offer congestion avoidance other than by means of exponential back-off. The draft however allows these DNS lookups to be truncated, where there may still be packets in transit and where the back-off period has not been achieved. This means there is NO congestion avoidance as a result of this technique. This condition could become progressively worse as features are added to these scripts growing their size and complexity. The expectations of the DNS cache being a salvation may be overestimated, especially with bad behaviors of spammers that may attempt to exploit these records. The complexity of these records, the large sequential lookups, and the indeterminate labels and record types may invite unexpected avenues for DNS hijacking found through either cache poisoning or by spoofing. There should be some warning about sourcing DNS from random ports. Should the DNS be allotted full back-off periods, the current record allowances may require hours to resolve. There is an alternative that does not suffer from most of these risks but can provide the basic features of prescribing the mail channel as defined in the MPR draft. This approach could also avoid the IPR problems as well and was provided to serve as an illustrative example of the potential solutions for problems facing the implementation of Sender-ID. Solution: http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt -Doug From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 14:29:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21848 for ; Fri, 27 Aug 2004 14:29:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RI74D2048148; Fri, 27 Aug 2004 11:07:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RI74rv048147; Fri, 27 Aug 2004 11:07: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 i7RI74Gp048138 for ; Fri, 27 Aug 2004 11:07: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; Fri, 27 Aug 2004 14:07:08 -0400 id 001976BC.412F784C.000006C1 In-Reply-To: <1093626986.7023.22.camel@va.local.linuxlobbyist.org> References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> <1093626986.7023.22.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: on the topic of IPR Date: Fri, 27 Aug 2004 14:07:07 -0400 To: Paul Iadonisi X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 1:16 PM, Paul Iadonisi wrote: > I'm also boggled that you are endorsing the kind of vagueness that > many of us are trying to get some clarification on. I am not endorsing anything. Please reread the very first paragraph of my message. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 14:33: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 OAA22152 for ; Fri, 27 Aug 2004 14:33: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 i7RIAPFa048350; Fri, 27 Aug 2004 11:10:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RIAPcu048349; Fri, 27 Aug 2004 11:10:25 -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 i7RIAPmu048342 for ; Fri, 27 Aug 2004 11:10:25 -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 i7RI9oJe001304 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 Aug 2004 11:09:51 -0700 Date: Fri, 27 Aug 2004 11:09:50 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Jeff Macdonald cc: John Glube , ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <1093554409.30660.86.camel@jmacdonald-work.e-dialog.com> Message-ID: References: <00ff01c48b40$637de7a0$6c62fea9@ibmrkydk2ufvdd> <1093539963.30660.28.camel@jmacdonald-work.e-dialog.com> <1093554409.30660.86.camel@jmacdonald-work.e-dialog.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 Aug 2004, Jeff Macdonald wrote: > > How would this differ from their spfv1 record? Well, since most > > outsourced mailings use an ESP-controlled MAIL FROM address (for bounce > > handling purposes), the spfv1 record would not necessarily include those > > additional ESP references. > > I think you meant the Bank's IPs listed (SPF2) in the Bank's primary > domain won't/shouldn't be listed in the ESP's spf records. However, > since the MAIL FROM is in the ESP's domain space, is this not a separate > DNS record anyway? Well, I meant that since the ESP-delivered messages would use a bank labelled From: but an ESP labelled MAILFROM, then the *banks* spfv1 records would not need to include the ESP relay IP addresses. The banks' spfv2 record *would* however need to include the ESP relay IP addresses. > See my confusion? If MAIL FROM and Header FROM are different in the > domain portion that should mean that different DNS records need to be > looked up. I realize with Sender-ID doubles the amount of data. The SPF > and SPF2 records would indeed be different. Sorry, this doesn't parse. > However, help me understand how the content of a SPF/SPF2 record could > be different if the MAIL FROM and the PRA have the same domain portion. If the MAIL FROM and the PRA have the same domain portion then you are right, the spfv1 and spfv2 records would definitly be the same. But what I am telling you is that for a lot of these examples, the domain of the MAIL FROM is /not/ the same as the domain of the PRA for the same inidividual message. -Rand From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 14:33: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 OAA22175 for ; Fri, 27 Aug 2004 14:33: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 i7RICKcq048454; Fri, 27 Aug 2004 11:12: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 i7RICKE6048453; Fri, 27 Aug 2004 11:12:20 -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 i7RICKOR048446 for ; Fri, 27 Aug 2004 11:12:20 -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 i7RICN7u002098 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 Aug 2004 11:12:23 -0700 Date: Fri, 27 Aug 2004 11:12:23 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: Jim Lyon cc: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAD36@df-fido-msg.exchange.corp.microsoft.com> Message-ID: References: <81AC085044D04B429F5FB883D94FA1AF8FAD36@df-fido-msg.exchange.corp.microsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I definitely accept Mark and Jim's workaround for publishing parallel big records, but I still think that it is a bad engineering decision to continue publishing records that we know will evolve into a finite TXT dataspace. Just because SPF Classic decided to bogart the TXT space at doesn't mean we have to make the same mistake. I am, as always, ready to go with what the group ultimately decides. -Rand On Thu, 26 Aug 2004, Jim Lyon wrote: > > In this thread, Rand points out that complicated domains may wish to > publish both SPF1 and SPF2 records, and that this effectively cuts their > maximum record size in half (if they want to fit into a DNS UDP packet, > which they do). He also points out than these are exactly the domains > that may be pushing the DNS UDP size limits. > > While this is an issue, there's a trivially easy workaround: For your > domain, publish very short SPF1 and SPF2 records, that just contain > "REDIRECT=subdomain". If your SPF1 and SPF2 data are identical, they > can both refer to the same subdomain; if your SPF1 and SPF2 data differ, > they can refer to different subdomains. > > Problem solved. > > > But wait, I hear critics cry: Doesn't that double the number of lookups > someone has to do? > > Yes, it does. But the large, complicated domains that have this issue > are almost exactly the ones that send lots of legitimate mail. As such, > their records will usually already be in your resolver's DNS cache. > (Said differently, it doesn't matter how complicated AOL's records are, > because your DNS cache will only fetch them once a week.) > > > -- Jim Lyon > > From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 14: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 OAA24090 for ; Fri, 27 Aug 2004 14: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 i7RIQGlb049178; Fri, 27 Aug 2004 11:26:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RIQGf3049177; Fri, 27 Aug 2004 11:26:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from vodka.at-once.com (vodka.at-once.com [207.162.212.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIQGxi049164 for ; Fri, 27 Aug 2004 11:26:16 -0700 (PDT) (envelope-from ryan@nwgeeks.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vodka.at-once.com (8.12.11/8.12.11) with ESMTP id i7RIQCWO006907; Fri, 27 Aug 2004 11:26:12 -0700 Subject: Re: acceptable licenses (Was: Can there be an early decision on t he SenderID license?) From: Ryan Ordway To: Margaret Olson Cc: IETF MARID WG In-Reply-To: <6B8BC87E-F850-11D8-BD7E-000A95BC6A7E@margaretolson.com> References: <93C5D480-F7FB-11D8-8AD0-000A95AC5778@isipp.com> <6B8BC87E-F850-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Type: text/plain Organization: Northwest Geeks! Message-Id: <1093631171.6468.13.camel@vodka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 27 Aug 2004 11:26:12 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-27 at 10:42, Margaret Olson wrote: > On Aug 27, 2004, at 3:34 AM, Anne P. Mitchell, Esq. wrote: > > I agree completely with Larry Rosen, and several others, that the > > entire scheme vis the license is problematic. The *reason* it is > > problematic is that while, yes, it allows unlimited use by *end > > users*, as soon as someone tries to modify it for their own purpose, > > and then share that modification with others for the good of and > > widespread adoption throughout the industry, there's a "gotcha". In > > fact, I would argue that the same concern applies to end-users - what > > if the end-user wants to tweak the code themselves? If they want to > > then share that modified implementation they could find themselves on > > the wrong end of an MS lawsuit. It's all about control. You can't > > really blame MS for wanting to retain this sort of control - but I > > would suggest that it's antithetical to the real goal here. An > > authentication system to be uniformly adopted across the industry is > > *not* the same as an authentication system to be uniformly adopted > > across the industry which is essentially *owned* by one very large > > ISP. Having an ISP - particularly one of the 800 pound gorillas - own > > the ultimate commercial (and that's what it is, commercial) rights to > > the one true authentication system is like having a large marketing > > company own the IP rights to the one spam filter in use across the > > industry. > > > > What happens when Earthlink comes up with a better way to both > > implement and check for Sender I.D., which ends up giving it a > > competitive edge over Hotmail and MSN in the spam performance arena? > > (And make no mistake about it - at this point in time, spam/anti-spam > > performance at national ISPs is very much all about a competitive > > marketing edge.) Remember, this is the same company that threatened > > Slashdot and demanded that they remove user postings because the users > > had quoted a *public* Microsoft document 'in violation of their > > copyright'. > > > > Of course, this is something which I and many others have been saying, > > and predicting, all along. That as soon as MS started courting Meng, > > it tolled the death-knell for the open-source potential of SPF, which > > is what made SPF so attractive in the first place. > > > > In my opinion what we need is a SenderID/SPF-clone which is truly > > open-source, and which doesn't itself violate the inevitable Microsoft > > IP claims. You can be reasonably sure that MS' plan all along was to > > rule this market, and that's exactly where they are headed, with the > > blessing of a surprising number of people. The race for a winning > > authentication protocol among the majors was never altruisitically > > about authentication first - it was always about market domination - > > and it was a shrewd, but blatant, move on MS' part to dance with Meng > > and end up subsuming SPF. > > > My problem with this line of reasoning is that any spam reduction > mechanism is going to have IPR claims - by either the genuine inventors > or someone else. There are multiple patent claims on challenge > response. I am not comfortable with the idea that we reject a > technology because the IPR holder has deep pockets. As far as I can > tell, that the IPR is held by Microsoft remains the primary objection, > and I can't see that as a valid objection. If you note the subject of this thread, it's acceptable licenses, not acceptable corporate benefactors. My objection has nothing to do with Microsoft and everything to do with the terms of the license. The majority of other objections I have heard have stated this as well. You are right that there are some people who simply object to Microsoft's part in SenderID in general, but I believe these people to be the minority. If Microsoft were to drop certain restrictions within the license, restrictions which have been voiced many times already so I won't waste energy restating them again, I would have no objections to continuing. Ryan -- HELO, my name is root... you have SIGKILLed my father... prepare to vi! From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 14:46: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 OAA24119 for ; Fri, 27 Aug 2004 14:46:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIRBYl049222; Fri, 27 Aug 2004 11:27:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RIRBle049221; Fri, 27 Aug 2004 11:27:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIRA6o049214 for ; Fri, 27 Aug 2004 11:27:10 -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 i7RIREWb005405 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Aug 2004 11:27:14 -0700 Date: Fri, 27 Aug 2004 11:27:14 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: ietf-mxcomp@imc.org Subject: RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <013901c48c01$4b7a03c0$6c62fea9@ibmrkydk2ufvdd> Message-ID: References: <013901c48c01$4b7a03c0$6c62fea9@ibmrkydk2ufvdd> 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, 27 Aug 2004, John Glube wrote: > I should have been clearer. Web hosting services offer sub > domains. However, there is a threshold cost involved, which > can sometimes be an incremental amount on a monthly basis. We're arguing about a theoretical incremental cost for someone to publish a subdomain record through their ISP? If that ISP provides email service they are going to figure out they have to just do this for their customers, in a sub-domain or not in a sub-domain, otherwise those customers are going to another ISP that does. The incremental cost of publishing a record in a sub-domain is inconsequential when compared with publishing a new data record and re-tooling the SMTP infrastructure to determine where mail should actually be coming from. > Perhaps it is my innate sense of irony. Here we are, 4 days > into last call, when someone like yourself comes in from > the field and says hey guys "she just don't fit." :-) I brought up the point at IETF when the proposal to split was made, then shopped it around with a few of our major customers over the past couple of weeks, and here I am with more details. > Whether the financial institutions' design criteria, which > I gather from your comments has stamped the creation of > certain key aspects of Sender-ID is the right approach to > dealing with the phishing problem? Yes, they feel that Sender ID is a useful band-aid for the immediate problems, and recognize the need to develop a more robust solution (ie cryptographic). *Any* IP based authentication solution is going to have limitations, primarily that they can only authenticate the most recent hop that a message takes. For these large customers I'm talking to, a large portion (usually more than 50%) of their emails go precisely one hop from the sender relay to one of either AOL, Yahoo, or Hotmail. And unknown but expectedly large portion of the other mails go one hop as well, but its impossible to tell how many others may be forwarded. So, for a large portion of the customers these senders are trying to send authenticated emails to, Sender ID will help. There is going to be friction in getting mid-points for forwarding solutions upgraded to add Resent-From and Resent-Sender headers, but those changes are much less invasive than SRS rewriting. Who knows, we may skip the whole upgrade-the-middle-part and move straight to deployment of end-to-end crypto auth, Sendmail is working hard on that as well. But in the short term, Sender ID offers as many good benefits as any IP-based message authentication scheme can. -Rand From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 14: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 OAA24605 for ; Fri, 27 Aug 2004 14:54:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIWug7049841; Fri, 27 Aug 2004 11:32: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 i7RIWu00049840; Fri, 27 Aug 2004 11:32:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIWtjM049828 for ; Fri, 27 Aug 2004 11:32:55 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7RIVonK005022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Aug 2004 14:31:51 -0400 Subject: Re: on the topic of IPR From: Paul Iadonisi To: IETF MARID WG In-Reply-To: References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> <1093626986.7023.22.camel@va.local.linuxlobbyist.org> Content-Type: text/plain Message-Id: <1093631468.7023.26.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 27 Aug 2004 14:31:08 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-27 at 14:07, Andrew Newton wrote: > On Aug 27, 2004, at 1:16 PM, Paul Iadonisi wrote: > > > I'm also boggled that you are endorsing the kind of vagueness that > > many of us are trying to get some clarification on. > > I am not endorsing anything. Please reread the very first paragraph of > my message. Point taken. No offense was intended. The rest of my post still applies, of course. I should rephrase the above roughly as 'I would be boggled by anyone endorsing the kind of vagueness...' -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 15:29: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 PAA28546 for ; Fri, 27 Aug 2004 15:29: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 i7RJ7U7K052311; Fri, 27 Aug 2004 12:07: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 i7RJ7U9C052310; Fri, 27 Aug 2004 12:07:30 -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 i7RJ7TJ1052303 for ; Fri, 27 Aug 2004 12:07:29 -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 i7RJ7W17014185 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 Aug 2004 12:07:32 -0700 Date: Fri, 27 Aug 2004 12:07:32 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: "william(at)elan.net" cc: IETF MARID WG Subject: Re: TECH-ERROR: Duplication of version number as part of the name for SPF2 dns record (this is possibly TECH-OMISSION) 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, 26 Aug 2004, william(at)elan.net wrote: > To fix it is recomended that all references to SPF dns record type and > examples be changed from "SPF2" to just "SPF" with note in the text that > such dns type records should confront to SPF2.0 or later records. So above > example would change to: > > example.com. IN SPF "spf2.0/pra +mx +a:colo.examp.e.com/28 -all" This would have the potential of creating *exactly* the same dataspace problems as stuffing all the different versions in a TXT record, and would IMO be a bad engineering decision. -Rand From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 15:31: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 PAA28744 for ; Fri, 27 Aug 2004 15:31: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 i7RJ5t1S052209; Fri, 27 Aug 2004 12:05:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RJ5tmP052208; Fri, 27 Aug 2004 12:05:55 -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 i7RJ5r7C052202 for ; Fri, 27 Aug 2004 12:05:54 -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 i7RJ5sFW014004 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Aug 2004 12:05:54 -0700 Date: Fri, 27 Aug 2004 12:05:54 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: IETF-MXCOMP Subject: Re: AOL's stance on SenderID and IPR issues 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, 26 Aug 2004, william(at)elan.net wrote: > I'd like to also hear how this license would impact Yahoo. As Matt and others point out, this is irrelevant, as the license does not impact end-users of the code, only people who will redistribute it (which qmail doesn't allow anyways ;) -Rand From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 16:25:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05113 for ; Fri, 27 Aug 2004 16:24:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RK6BmH056897; Fri, 27 Aug 2004 13:06: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 i7RK6BDU056896; Fri, 27 Aug 2004 13:06:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RK69Zn056885 for ; Fri, 27 Aug 2004 13:06:10 -0700 (PDT) (envelope-from george@m5p.com) Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by mailhost.m5p.com (8.12.11/8.12.11) with ESMTP id i7RK670N008975 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Aug 2004 13:06:08 -0700 (PDT) Received: (from defang@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7RK1jtW008938 for ; Fri, 27 Aug 2004 13:01:45 -0700 (PDT) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (MIMEDefang) with ESMTP id i7RK1jAH008937; Fri, 27 Aug 2004 13:01:45 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7RK1jmf050380; Fri, 27 Aug 2004 13:01:45 -0700 (PDT) Date: Fri, 27 Aug 2004 13:01:45 -0700 (PDT) From: George Mitchell Message-Id: <200408272001.i7RK1jmf050380@m5p.com> To: andy@hxr.us, ietf-mxcomp@imc.org Subject: Re: on the topic of IPR In-Reply-To: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It is one of the jobs of co-chairs to facilitate discussion of working > group topics. Not that the issue of IPR is being debated lightly, > however we would like to raise a few discussion points that may have > been overlooked or given light treatment. > > - Many a message have been dedicated toward discussing the potential > abuse Microsoft may undertake while armed with a patent. However, > there has been little discussion regarding Microsoft's willingness and > ability (via deep pockets) to fend off counter patent claims. Should > Sender ID go forward with the acceptance of Microsoft's IPR, it leaves > little doubt that another entity claiming rights to such technology > will have to go through Microsoft to find remedy. However, if MARID > were to produce another standard such as Classic SPF or even CSV, who > will defend a legal claim against it? In other words, better the devil we know? I don't think so. Should IETF completely abandon standards which are not covered by patents simply out of fear that they will give rise to lawsuits? > [...] > > - If it is reasonable to assume that Microsoft's patent application > and claimed IPR can and/or do reach beyond draft-ietf-marid-core and > draft-ietf-marid-pra, is it not the best course of action to take > Microsoft's offer of a royalty-free, nondiscriminatory and reasonable > license given that a rejection of Sender ID as a standard has no weight > on the standing of their claim. In other words, if it is believed that > their claim could cover other work product of MARID, then would not the > best course of action be to secure the best-possible license? Sure. Just as soon as you tell me exactly what we're licensing. Why should we have to buy a pig in a poke? > - On the issue of deployment, there have been many messages regarding > the adoption of Sender ID (as a note, the chair's instructions > specifically called for opinion about personal deployment and not > speculation as to the actions of others). While many believe that > Sender ID's encumbrances will slow adoption because it is not as > friendly as desired toward open source, it has been noted that Qmail > also has an equally or more unfriendly license toward open source yet > is one of the most popularly used MTAs. "But he did it first!" > -andy -- George Mitchell From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 16:25: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 QAA05128 for ; Fri, 27 Aug 2004 16:25: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 i7RK5aeg056849; Fri, 27 Aug 2004 13:05: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 i7RK5anW056848; Fri, 27 Aug 2004 13:05:36 -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 i7RK5Zgs056837 for ; Fri, 27 Aug 2004 13:05:36 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 82658 invoked from network); 27 Aug 2004 20:05:37 -0000 Received: from pcp01845373pcs.bowie01.md.comcast.net (HELO wsd865gbf) (68.48.133.222) by relay.pair.com with SMTP; 27 Aug 2004 20:05:37 -0000 X-pair-Authenticated: 68.48.133.222 From: "Scott Kitterman" To: "IETF MARID WG" Subject: RE: on the topic of IPR Date: Fri, 27 Aug 2004 16:05:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Andrew Newton > Sent: Friday, August 27, 2004 6:48 AM > To: IETF MARID WG > Subject: on the topic of IPR > > - On the issue of deployment, there have been many messages regarding > the adoption of Sender ID (as a note, the chair's instructions > specifically called for opinion about personal deployment and not > speculation as to the actions of others). Speaking as just one small domain owner, I've been lurking on this list for months and posting on just a few issues that I felt were particularly important for someone in my position. Since I don't run my own MTA, the license terms do not directly affect me. However, it is critical in my mind that the product of the MARID group be open to all major MTAs. If some are excluded, it's not worth my time and effort to try and understand and keep up with a technology that is only even potentially effective with a fraction (even if a large fraction) of the MTAs we may send mail to. It would not matter to me if an open source friendly license were to prevent or severely burden implementation in a proprietary product or the reverse. As long as the MARID solution is not open to the full spectrum of developers (And I think that is clearly the case currently), I will not be publishing SPF2 (or whatever they end up being called) records for my domains. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 16:25: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 QAA05136 for ; Fri, 27 Aug 2004 16:25: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 i7RK1DQV056631; Fri, 27 Aug 2004 13: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 i7RK1DSI056630; Fri, 27 Aug 2004 13:01:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RK1CMT056623 for ; Fri, 27 Aug 2004 13:01:12 -0700 (PDT) (envelope-from george@m5p.com) Received: from m5p.com (mailhost.m5p.com [10.100.0.247]) by mailhost.m5p.com (8.12.11/8.12.11) with ESMTP id i7RK1702008909 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Aug 2004 13:01:10 -0700 (PDT) Received: (from defang@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7RJvmU1008861 for ; Fri, 27 Aug 2004 12:57:48 -0700 (PDT) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (MIMEDefang) with ESMTP id i7RJvmWC008860; Fri, 27 Aug 2004 12:57:48 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.12.11/8.12.11/Submit) id i7RJvlSe050319; Fri, 27 Aug 2004 12:57:47 -0700 (PDT) Date: Fri, 27 Aug 2004 12:57:47 -0700 (PDT) From: George Mitchell Message-Id: <200408271957.i7RJvlSe050319@m5p.com> To: andy@hxr.us, ietf-mxcomp@imc.org Subject: Re: Problematic issues with regard to last call In-Reply-To: <1860E822-F816-11D8-9196-000A95B3BA44@hxr.us> X-Scanned-By: MIMEDefang 2.43 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [...] If it is your intent to be unwavering and steadfast in > your opinion no matter the discourse of the issues, we ask that you > disengage from this working group. Well, golly, I think this might refer to me. It might refer to a number of people who object to the license agreement under discussion. Certainly if all of us leave, that will resolve the lack of consensus on the licensing issue. Is that what you are requesting? -- George Mitchell From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 16:29: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 QAA05961 for ; Fri, 27 Aug 2004 16:29: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 i7RK8gAc057075; Fri, 27 Aug 2004 13:08: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 i7RK8gT1057074; Fri, 27 Aug 2004 13:08:42 -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 i7RK8gSb057064 for ; Fri, 27 Aug 2004 13:08:42 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 27 Aug 2004 16:08:44 -0400 id 00197678.412F94CC.000011D8 In-Reply-To: <1093631468.7023.26.camel@va.local.linuxlobbyist.org> References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> <1093626986.7023.22.camel@va.local.linuxlobbyist.org> <1093631468.7023.26.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: on the topic of IPR Date: Fri, 27 Aug 2004 16:08:43 -0400 To: Paul Iadonisi X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 2:31 PM, Paul Iadonisi wrote: > No offense was intended. None taken. I just want it to be clear. And I didn't intend to offend you if I did. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 16: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 QAA08359 for ; Fri, 27 Aug 2004 16: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 i7RKL4nT058340; Fri, 27 Aug 2004 13:21: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 i7RKL4oI058339; Fri, 27 Aug 2004 13:21:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKL3YT058325 for ; Fri, 27 Aug 2004 13:21:03 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7RKJxtE007659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Aug 2004 16:19:59 -0400 Subject: Re: acceptable licenses (Was: Can there be an early decision on t he SenderID license?) From: Paul Iadonisi To: IETF MARID WG In-Reply-To: <6B8BC87E-F850-11D8-BD7E-000A95BC6A7E@margaretolson.com> References: <93C5D480-F7FB-11D8-8AD0-000A95AC5778@isipp.com> <6B8BC87E-F850-11D8-BD7E-000A95BC6A7E@margaretolson.com> Content-Type: text/plain Message-Id: <1093637956.7023.57.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 27 Aug 2004 16:19:16 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-27 at 13:42, Margaret Olson wrote: [snip] > My problem with this line of reasoning is that any spam reduction > mechanism is going to have IPR claims - by either the genuine inventors > or someone else. I think you will find that most anyone in the IT business would agree that *any* technology fits this description. But we can only deal with what we know. I'm a strong proponent of fixing the patent system to the point of eliminating *software* patents entirely. That is the *only* way do deal with submarine patents, IPR pooling companies, and other abuses of the patents system. But that's a battle to be fought elsewhere. In this case, we have known claims. Or *somewhat* known, since the IPR holder has not stated *exactly what* technology its claims are over. That in and of itself is enough reason to scuttle Sender-ID, or at least put it on hold until the issue can be resolved. I wouldn't say this except there are apparently a lot of *technical* issues people have brought up *and* there are also non-IPR-encumbered alternatives. > There are multiple patent claims on challenge > response. I am not comfortable with the idea that we reject a > technology because the IPR holder has deep pockets. Few, if any who are opposed to this license have suggest we reject it because 'the IPR holder has deep pockets.' Sure, the deep pockets have been mentioned, but not in any way as a primary motivator for rejecting the license. > As far as I can > tell, that the IPR is held by Microsoft remains the primary objection, > and I can't see that as a valid objection. Nice job setting up straw man. This is patently (no pun intended) false. Please cite in any of these last call posts on the IPR issue where the primary objection has to do with Microsoft. And please include multiple examples to support your assertion that it is the *primary* objection. I don't care if it's "Do No Harm" Google, or Eben Moglen himself. It's the license *terms* that people are talking about here. > I would also argue that there is a control advantage to making Sender > ID an IETF standard. It makes it much harder for Microsoft (or anyone > else, for that matter) to make arbitrary revisions. This *sounds* like you are advocating giving IETF *legal* teeth. Whether or not that is your intent, I don't know, but if it is, I think it's misguided and also not a good thing to work towards (giving the IETF legal teeth, that is). It's the IPR holder who would have the legal teeth here. I don't mind if the IETF says to me that I cannot implement Sender-ID and *call* it Sender-ID in my GPLed MTA unless I follow the spec strictly. Trademark law could possibly help with that (but I won't go down that road). But I do mind if ANY organization motivated by profit, and especially when this organization is a *competitor*, dictates what I can do with my GPLed MTA, including either changing my license or drawing up some burdensome -- really, contradictory -- exception to it (i.e.: This software is convered by the GNU General Public License with the exception that you need to get a license from Microsoft to modify and/or distribute any changes). > Whether or not this > matters depends on whether you think it will get widespread adoption. I > think it will, and that most of us are going to wind up dealing with it > regardless of the IETF decision. Do we prefer an IETF standard or a > de-facto standard? I would think that most on this list prefer an IETF standard, of course. But you are depicted a false dichotomy here. If the IETF does not adopt Sender-ID, you seem to be assuming that there are no other choices. The IETF, though still having its critics, still has a lot of weight when it puts it imprimatur of "RFC" on a standard. =-=- Aside: We now have three legal opinions that this patent license is not compatible with the GPL or even the DFSG, OSI, and FSF meta-definitions of FOSS licenses. And zero legal opinions (as far as I've seen) that say otherwise. If that's the tally, I hope we can put that argument to rest. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 16:40: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 QAA08405 for ; Fri, 27 Aug 2004 16:40: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 i7RKH0qE057504; Fri, 27 Aug 2004 13:17: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 i7RKH0QT057503; Fri, 27 Aug 2004 13:17:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKH0en057497 for ; Fri, 27 Aug 2004 13:17:00 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 27 Aug 2004 16:17:04 -0400 id 00197678.412F96C1.000012D6 In-Reply-To: <200408271957.i7RJvlSe050319@m5p.com> References: <200408271957.i7RJvlSe050319@m5p.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0F8849C2-F866-11D8-9196-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: Andrew Newton Subject: Re: Problematic issues with regard to last call Date: Fri, 27 Aug 2004 16:17:03 -0400 To: George Mitchell X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 3:57 PM, George Mitchell wrote: > Well, golly, I think this might refer to me. It might refer to a > number of people who object to the license agreement under discussion. > Certainly if all of us leave, that will resolve the lack of consensus > on the licensing issue. Is that what you are requesting? I can see how you would be upset given that you took my statement out of context. -andy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 16: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 QAA09647 for ; Fri, 27 Aug 2004 16:53: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 i7RKUr9k059088; Fri, 27 Aug 2004 13:30:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RKUr5u059087; Fri, 27 Aug 2004 13:30:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKUqNV059073 for ; Fri, 27 Aug 2004 13:30:53 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7RKTms8007908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Aug 2004 16:29:49 -0400 Subject: Re: Problematic issues with regard to last call From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: <200408271957.i7RJvlSe050319@m5p.com> References: <200408271957.i7RJvlSe050319@m5p.com> Content-Type: text/plain Message-Id: <1093638545.7023.64.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 27 Aug 2004 16:29:06 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-27 at 15:57, George Mitchell wrote: > > [...] If it is your intent to be unwavering and steadfast in > > your opinion no matter the discourse of the issues, we ask that you > > disengage from this working group. > > Well, golly, I think this might refer to me. It might refer to a > number of people who object to the license agreement under discussion. > Certainly if all of us leave, that will resolve the lack of consensus > on the licensing issue. Is that what you are requesting? Well, that's not how I took it. I think it's referring more to post of the sort that say 'give me SPF-Classic/SRS or give me death'. I don't think my own posts fall into that category, but I could be wrong. I suggested it as an alternative, but only to point out that we DO have alternatives here and that the IPR issues with Sender-ID are sufficiently show stopper to step back not submit it at this time. Even if *nothing* is submitted at this time, that would be fine with me, but it's just too soon for Sender-ID, given that the patent licenses was only published at the beginning of Last Call. Aside to Andrew Newton: no, I took no offense to your correction of my statement about 'endorsing the kind of vagueness...'. No problem. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 17: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 RAA10695 for ; Fri, 27 Aug 2004 17:02:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKhF6X059975; Fri, 27 Aug 2004 13:43: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 i7RKhFIH059974; Fri, 27 Aug 2004 13:43:15 -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 i7RKhEjR059964 for ; Fri, 27 Aug 2004 13:43:14 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [66.80.0.6] (dhcp-6.danastreet.live.com [66.80.0.6]) by mail.glyphic.com (Postfix) with ESMTP id 5CED040EE for ; Fri, 27 Aug 2004 13:43:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1093629989.5542.9.camel@ddev.mail-abuse.org> References: <1093629989.5542.9.camel@ddev.mail-abuse.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: From: Mark Lentczner Subject: Re: TECH-ERROR: Misuse of DNS Records Date: Fri, 27 Aug 2004 13:43:35 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RKhEjR059969 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I think your message contains two distinct issues: On Aug 27, 2004, at 11:06 AM, Douglas Otis wrote: > The Protocol draft mandates a minimum of 10 DNS text script macro > evaluations. These scripts may reference any number of A, AAAA, MX, > PTR, > TXT, and SPF2 resource record types. ... This seems to be a concern that the type of processing limits in the draft are unsuitable for keeping the amount of DNS traffic down to a reasonable level. Several other people (Wayne in particular) have suggested other types of processing limits for the draft that would more precisely limit DNS queries. Do you have a particular proposal in mind? > The Protocol draft also allows for “open-ended” definitions by > appending > notation such as “+all” or “?all” I think you are concerned here that the draft allows domains to publish what you would argue are unsafe and detrimental records. Do you have a specific proposal for changing the draft to address this issue? > Solution: > http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt If your concerns are truly TECH-ERROR concerns with the protocol draft, please suggest specific ways to fix them. If your concern is that the draft is so broken that the working group should abandon it and proceed with discussing your draft, then that is much more than a TECH-ERROR issue. Perhaps it is a DEPLOY level issue, or perhaps a meta-level issue to be brought up with the working group chairs. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 17:14:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11546 for ; Fri, 27 Aug 2004 17:14: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 i7RKsjxb060715; Fri, 27 Aug 2004 13:54: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 i7RKsjsG060714; Fri, 27 Aug 2004 13:54:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baltazar.webjorn.org (baltazar.webjorn.org [192.121.126.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKsiL5060705 for ; Fri, 27 Aug 2004 13:54:44 -0700 (PDT) (envelope-from mattias@webjorn.org) Received: (qmail 2504 invoked from network); 27 Aug 2004 20:54:41 -0000 Received: from ns.webjorn.org (HELO ns) ([192.121.126.21]) (envelope-sender ) by baltazar.webjorn.org (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Aug 2004 20:54:41 -0000 Date: Fri, 27 Aug 2004 22:54:41 +0200 (CEST) From: =?ISO-8859-1?Q?Mattias_Webj=F6rn_Eriksson?= X-X-Sender: materi@ns.webjorn.org Reply-To: mattias@webjorn.org To: Margaret Olson cc: IETF MARID WG Subject: Re: acceptable licenses (Was: Can there be an early decision on t he SenderID license?) In-Reply-To: <6B8BC87E-F850-11D8-BD7E-000A95BC6A7E@margaretolson.com> Message-ID: References: <93C5D480-F7FB-11D8-8AD0-000A95AC5778@isipp.com> <6B8BC87E-F850-11D8-BD7E-000A95BC6A7E@margaretolson.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-126398554-1093640081=:27319" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-126398554-1093640081=:27319 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Fredagen, den 27 aug 2004, skrev Margaret Olson: > > > My problem with this line of reasoning is that any spam reduction mechani= sm=20 > is going to have IPR claims - by either the genuine inventors or someone= =20 > else. There are multiple patent claims on challenge response. I am not=20 > comfortable with the idea that we reject a technology because the IPR hol= der=20 > has deep pockets. I have not seen any one on this list mention that as an argument against=20 Sender ID, have you? > As far as I can tell, that the IPR is held by Microsoft=20 > remains the primary objection, and I can't see that as a valid objection. Of course it is. Poeple including some laywers states that this license is incompatible=20 with many other licenses. This is of great concern as it affects deployment. > > I would also argue that there is a control advantage to making Sender ID = an=20 > IETF standard. It makes it much harder for Microsoft (or anyone else, for= =20 > that matter) to make arbitrary revisions. Whether or not this matters dep= ends=20 > on whether you think it will get widespread adoption. I think it will, an= d=20 > that most of us are going to wind up dealing with it regardless of the IE= TF=20 > decision. Do we prefer an IETF standard or a de-facto standard? Of course= , if=20 > adoption is widespread and rapid enough it will be difficult for anyone t= o=20 > change regardless of the size of the gorillas. > > Margaret. > > =09Med v=E4nliga h=E4lsningar =09Mattias W E ---559023410-126398554-1093640081=:27319-- From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 17:20: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 RAA12039 for ; Fri, 27 Aug 2004 17:20: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 i7RKueTm060825; Fri, 27 Aug 2004 13:56: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 i7RKueNH060824; Fri, 27 Aug 2004 13:56:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKudG2060816 for ; Fri, 27 Aug 2004 13:56:39 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7RKtaFQ008939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Aug 2004 16:55:36 -0400 Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ From: Paul Iadonisi To: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1093640093.7023.71.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 27 Aug 2004 16:54:53 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-25 at 21:48, wayne wrote: [snip] > It isn't at all clear to me that a patch can be a "Licensed Product" > and thus allowing the person applying the patch to the qmail > source to be covered by the "End User" aspects of the SenderID > license. Even if a patch could be a product, aren't you > creating a new product when you apply the patch? This follows right along with my explanation that, at least with the GPL, there is no distinction between end user and intermediate developer (see http://www.imc.org/ietf-mxcomp/mail-archive/msg03589.html). I think that any license that makes this distinction will be a problem for the GPL and possibly lots of other FOSS licenses. And even some non-FOSS license (by FSF, OSI, or DFSG definitions), like the qmail license. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 17:45:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13570 for ; Fri, 27 Aug 2004 17:45:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLLwgK062663; Fri, 27 Aug 2004 14:21: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 i7RLLw0q062662; Fri, 27 Aug 2004 14:21: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 (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLLwgZ062655 for ; Fri, 27 Aug 2004 14:21:58 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 27 Aug 2004 14:22:02 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Aug 2004 14:22:03 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 14:22:02 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 14:22:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH OMISSION: Stronger checks against email forgery Date: Fri, 27 Aug 2004 14:22:02 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAFC7@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: TECH OMISSION: Stronger checks against email forgery Thread-Index: AcSLuDaruoFMb5k0Q42SYBbXsl74ugAwp9xA From: "Jim Lyon" To: "Douglas Otis" Cc: "John Glube" , "IETF MARID WG" X-OriginalArrivalTime: 27 Aug 2004 21:22:02.0234 (UTC) FILETIME=[E4E5ADA0:01C48C7B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RLLwgZ062656 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, August 26, 2004 at 3:01 PM, Doug Otis argues: (via my summary / paraphrase) > That spammers will create messages that forge domains whose SenderId records include "+all". Yes, they will. And those domains will get a (richly deserved) bad reputation, and most people will refuse to accept mail from them. > That other (unspecified) factors will cause many legitimate domains to publish records with "+all". I don't believe it. I certainly haven't seen anyone on this list claim that they intend to publish a "+all". > That SenderID will cause the normal, person-to-person email message to use something other than PRA == 2822 From == bounce address. I don't believe this either. Is there any support for this proposition? If SenderID forces a change, then what will it change to? > That all problems are solved if we merely implement draft-otis-marid-mpr-00. I (and many others on the group) disagree, for reasons stated many times previously. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 17:51: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 RAA13850 for ; Fri, 27 Aug 2004 17:51: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 i7RLVXXf063274; Fri, 27 Aug 2004 14:31: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 i7RLVXM5063273; Fri, 27 Aug 2004 14:31:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLVX9P063267 for ; Fri, 27 Aug 2004 14:31:33 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 27 Aug 2004 14:31:37 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Aug 2004 14:31:38 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 14:31:37 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 14:31:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH OMISSION: Stronger checks against email forgery Date: Fri, 27 Aug 2004 14:31:37 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAFD1@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: TECH OMISSION: Stronger checks against email forgery Thread-Index: AcSMTlWy3B0vsERySJu/gXd8PMgmtgALZ+Yg From: "Jim Lyon" To: "Michael R. Brumm" , "IETF MARID WG" X-OriginalArrivalTime: 27 Aug 2004 21:31:36.0996 (UTC) FILETIME=[3B7B6640:01C48C7D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RLVX9P063268 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Friday, August 27, 2004 at 8:42 AM, Michael R. Brumm argues: (again by my summary / paraphrase) > That he receives lots of bounces containing spam where the spammer intended him to read the bounce (as opposed to his receipt being collateral damage). If that's true (and it hasn't been my experience), then he should install SES or some other unilateral scheme of getting rid of bogus bounces. This will be 100% effective, instead of relying on the rest of the internet to figure out which bounces are unwanted. > That he gets so many bogus bounces that he has erroneously overlooked legitimate bounces. Same answer as above. > That the bounce address is strongly relevant in determining mail authenticity. I continue to disagree. There are too many scenarios where the bounce address is uncorrelated with the MTA that's delivering a message; this means that any scheme that attempts to reject mail based on those two inputs (bounce address and IP addr of sending MTA) will have too many false rejections. > That the right taxonomy for authenticating mail is protect the MTAs, protect the envelope, protect the content. For all the reasons discussed here over the lifetime of the group, I disagree. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 17:55: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 RAA13993 for ; Fri, 27 Aug 2004 17:55:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLXUi9063673; Fri, 27 Aug 2004 14:33:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RLXU1T063672; Fri, 27 Aug 2004 14:33:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLXUji063650 for ; Fri, 27 Aug 2004 14:33:30 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [66.80.0.6] (dhcp-6.danastreet.live.com [66.80.0.6]) by mail.glyphic.com (Postfix) with ESMTP id 115FF40E3 for ; Fri, 27 Aug 2004 14:33:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: DOC-BUG: section 2.1 of marid-protocol-02 Date: Fri, 27 Aug 2004 14:33:47 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 26, 2004, at 10:19 PM, william(at)elan.net wrote: > a. " Notice that the wildcard records must be repated" does not sound > right > to me (butenglish is not my first language, I may well be wrong). I believe that it is correct and your revision is not precise enough. > Additionally extra " " before "Notice" should be removed. Fixed. > b. first "for" should be removed Fixed. > c. The last paragraph refers to dns server returning NXDOMAIN > ... > At the same time I note that RFC2929 then set "NXDomain" as proper > name of the DNS RCODE 3... I will look into the using the proper names for the DNS status codes. > But none of these documents are referenced from the protocol draft. I'm not sure a normative reference is needed. Will depend on my research for the above. > 2. In section 2.1 ("Publishing"), the paragraph reads: > ... > "domain file" is a vague reference, please at the very least replace > with "domain zone file". Fixed. > Futher the section 2.1 ends as > ... > I believe it should be added her also that use of the same record > type > for multiple puposes is discouraged.and wide use such practice poses > a danger to dns system. I do not think the protocol document is the correct place to be teaching best practices or making statements about DNS as a whole. > 3. In section 2.1.1 "SPF DNS RR Type" paragraph says > "Sender-ID compliant mail originating zones MUST publish SPF2 type > records, and MAY publish TXT records that have identical content" > ... > 4. In next paragraph in 2.1.1 it says > "A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup > TXT record at the same time, or wait for negative answer. SPF2 type > SHOULD be used if available" There is already a lengthly thread on these paragraphs. Please see the discussion starting at: http://www.imc.org/ietf-mxcomp/mail-archive/msg03491.html There are technical issues being discussed that should be resolved before we word-smith it. - Mark From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 18: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 SAA14728 for ; Fri, 27 Aug 2004 18:07: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 i7RLmH6s065056; Fri, 27 Aug 2004 14:48: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 i7RLmHda065055; Fri, 27 Aug 2004 14:48:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLmHZY065049 for ; Fri, 27 Aug 2004 14:48:17 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 27 Aug 2004 14:48:22 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Aug 2004 14:48:23 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 14:48:21 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 14:48:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages Date: Fri, 27 Aug 2004 14:48:21 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages Thread-Index: AcSLxEv7jyJpMLHUSqGr1aLa1/F2uwAudNQA From: "Jim Lyon" To: "Mark Shewmaker" , "MARID" X-OriginalArrivalTime: 27 Aug 2004 21:48:21.0635 (UTC) FILETIME=[924B2530:01C48C7F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RLmHZY065050 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, August 26, 2004 at 4:20 PM, Mark Shewmaker wrote (regarding the need to generate a DSN if 7 conditions hold): > Perhaps it's a corner case in legitimate mail, but legitimate mail is > not my main concern; I'm more worried about from the standpoint of it > opening up an exploitable vulnerability, and two problems that can > result from spammers exploiting that vulnerability: > > 1. Spammers will get their bounce message spams to a bunch of victims, > using the exploited machine. (Any individual victim's machine could > of course avoid this threat by implementing SES.) > > 2. The exploited machine will become known as a source of bounce spam, > and be added to domain-based blocklists. > > (1) is bad in and of itself, but (2) means that if someone doesn't like > you or your machine, that they'll be able to get you black-listed. I think that the Internet community (not just the MARID group) needs to hold a larger discussion on exactly when one should or should not generate a DSN, and on what culpability one incurs by generating a DSN for a forged message. Unless and until that discussion occurs, I would suggest: 1. Employ SES or equivalent at your own site, to avoid suffer from received bogus bounces. 2. Reputation systems are probably on shaky ground black-listing sites because of generated DSNs. 3. Sites should use their own judgment in whether to generate a DSN or silently discard messages that they believe are forged. Each of these is (at least arguably) in the self-interest of the party that makes the decision. > The only way to solve this problem would be to allow for an override of > the must-accept-100-recipients requirement in RFC 2821. True. This would help, and is probably a good idea. But it's outside the scope of MARID. > You can't completely avoid this problem through the addition of > classic-SPF test, and you can't completely avoid it with SES, (though > the recipients could.) Agreed. > And that was the point of my email that you responded to: The only way > to completely avoid this blow back vulnerability that shows up in the > no-SUBMITTER case, (other than silently dropping the email), is to give > a transient "too many recipients" error upon the first recipient with a > differing PRA white-list, if you haven't verified that the Return Path > is legitimate. Yes, I understand now. And it demonstrates that SUBMITTER has some usefulness other than just as an optimization. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 18:09: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 SAA14884 for ; Fri, 27 Aug 2004 18:09: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 i7RLqqPC065308; Fri, 27 Aug 2004 14:52: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 i7RLqqTp065307; Fri, 27 Aug 2004 14:52:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLqqiW065301 for ; Fri, 27 Aug 2004 14:52:52 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 27 Aug 2004 14:52:57 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Aug 2004 14:52:58 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 14:52:56 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 14:52:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY - IP, HELO & touch count. DOC-BUG too. Date: Fri, 27 Aug 2004 14:52:56 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY - IP, HELO & touch count. DOC-BUG too. Thread-Index: AcSLyiLqoLZAsJr/Q8WPt4XeBXXUYAAtaIDw From: "Jim Lyon" To: "Douglas Otis" Cc: "Matthew Elvey" , "MXCOMP" X-OriginalArrivalTime: 27 Aug 2004 21:52:56.0449 (UTC) FILETIME=[36186F10:01C48C80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RLqqiW065302 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, August 26, 2004 at 5:07 PM, Douglas Otis wrote: > The Identity being authorized is the PRA Mailbox Domain by way of > reference to a Mail Channel prescription of IP addresses. No, please try reading it again. The identity being authorized is the sending MTA's IP address. The action being authorized is to send a message on behalf of the PRA. The organization doing the authorization is the domain of the PRA. > (... yet another advertisement for CSV ...) Ignored as not relevant. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 18:27: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 SAA16568 for ; Fri, 27 Aug 2004 18:27: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 i7RM5Kox066119; Fri, 27 Aug 2004 15:05: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 i7RM5KQd066118; Fri, 27 Aug 2004 15:05:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RM5Jpe066112 for ; Fri, 27 Aug 2004 15:05:19 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7RMDmhM031611; Fri, 27 Aug 2004 15:13:48 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7RMDmAv031607; Fri, 27 Aug 2004 15:13:48 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 27 Aug 2004 15:13:48 -0700 (PDT) From: "william(at)elan.net" To: Rand Wacker cc: IETF MARID WG Subject: Re: TECH-ERROR: Duplication of version number as part of the name for SPF2 dns record (this is possibly TECH-OMISSION) 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, 27 Aug 2004, Rand Wacker wrote: > On Thu, 26 Aug 2004, william(at)elan.net wrote: > > > To fix it is recomended that all references to SPF dns record type and > > examples be changed from "SPF2" to just "SPF" with note in the text that > > such dns type records should confront to SPF2.0 or later records. So above > > example would change to: > > > > example.com. IN SPF "spf2.0/pra +mx +a:colo.examp.e.com/28 -all" > > This would have the potential of creating *exactly* the same dataspace > problems as stuffing all the different versions in a TXT record, and would > IMO be a bad engineering decision. I disagree. First of this field is the same no matter how its called, so potential is exactly the same. Second, I do not believe version number identifier belongs in the dns type name, this is exactly the bad engineering decision. But if you want to put it then, then you should remove it from the data portion field and get rid of dupliction. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 18:34: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 SAA16950 for ; Fri, 27 Aug 2004 18:34: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 i7RMADuY066642; Fri, 27 Aug 2004 15:10:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RMADSS066641; Fri, 27 Aug 2004 15:10:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RMACm6066631 for ; Fri, 27 Aug 2004 15:10:12 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 27 Aug 2004 18:10:12 -0400 id 002F40A8.412FB144.00001E36 From: David Blacka Organization: VeriSign, Inc. To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: DNS Record Types Date: Fri, 27 Aug 2004 18:09:43 -0400 User-Agent: KMail/1.6.2 References: <81AC085044D04B429F5FB883D94FA1AF8FAD6B@df-fido-msg.exchange.corp.microsoft.com> <92686983.20040826161050@brandenburg.com> In-Reply-To: <92686983.20040826161050@brandenburg.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408271809.43267.davidb@verisignlabs.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday 26 August 2004 7:10 pm, Dave Crocker wrote: > Jim, > > JL> 1. Microsoft DNS server (all currently deployed versions) cannot > publish ... > JL> 2. The DNS resolver APIs on all Microsoft OS's don't let you query for > > I did recall that there were problems on the client side. > > So the thought is to make the record available, but realize that it will > only get queried as clients get more capable. > > In any event, having a specification that contains no "MUST" strikes me > as odd, since there is no identifiable core of functionality that is > guaranteed to be implemented. Such a guarantee is usually the basis for > IETF protocols being assured to work. Why not: SHOULD publish SPF2 MAY publish TXT MUST publish at least one of the two. -- David Blacka Sr. Engineer VeriSign Applied Research From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 18:47: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 SAA17784 for ; Fri, 27 Aug 2004 18:47: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 i7RMQEhq067400; Fri, 27 Aug 2004 15:26: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 i7RMQE0t067399; Fri, 27 Aug 2004 15:26:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RMQEqW067393 for ; Fri, 27 Aug 2004 15:26:14 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 27 Aug 2004 15:26:19 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Aug 2004 15:26:15 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 15:26:19 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 15:26:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages Date: Fri, 27 Aug 2004 15:26:19 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FB000@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: Legal liability for creating bounces from forged messages Thread-Index: AcSL2fGpb4z9YEkBSNeGqISXrcUd6wAp3SUg From: "Jim Lyon" To: "Chris Haynes" Cc: "IETF MARID WG" X-OriginalArrivalTime: 27 Aug 2004 22:26:18.0603 (UTC) FILETIME=[DF78E3B0:01C48C84] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RMQEqW067394 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, August 26, 2004 at 7:01 PM, Chris Haynes wrote about whether the RFC's and ID's really do or do not give one the legal authority to silently discard forged email. I offered a reading of the docs that supports the case for silent discards. Chris offers a reading of the same docs that supports the case against forged email. I agree that both readings are plausible. My point is that it is wrong to state that there is no support whatsoever for the idea of silent discards. There is, but it depends on how one reads arguably ambiguous documents. (This is how lawyers make a living.) Even though the standards are ambiguous, there is ample precedent for the action. I can demonstrate (on the basis of only 2 ISPs) that more than 10% of all email sent today is silently discarded. Nevertheless, this has strayed a long way from MARID's charter. It does, however, point to a need for more clarity in one's responsibilities in this area. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 18: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 SAA18196 for ; Fri, 27 Aug 2004 18:57:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RMdUoC068198; Fri, 27 Aug 2004 15:39: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 i7RMdU5O068197; Fri, 27 Aug 2004 15:39:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RMdUTG068191 for ; Fri, 27 Aug 2004 15:39:30 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 27 Aug 2004 15:39:32 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Aug 2004 15:39:28 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 15:39:31 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 15:39:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DOC-BUG (possibly TECH-OMISSION): ietf-marid-core section 5 Date: Fri, 27 Aug 2004 15:39:32 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FB00B@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DOC-BUG (possibly TECH-OMISSION): ietf-marid-core section 5 Thread-Index: AcSMBwilcYpLM2wERRO6cR0epfxasgAf5DUA From: "Jim Lyon" To: "william\(at\)elan.net" , "IETF MARID WG" X-OriginalArrivalTime: 27 Aug 2004 22:39:31.0430 (UTC) FILETIME=[B808B060:01C48C86] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RMdUTG068192 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I concur with William's requests, but don't think that these alone constitute a reason for another version of the draft. Should a revision occur, I'll be happy to incorporate William's suggestions. -- Jim Lyon -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of william(at)elan.net Sent: Friday, August 27, 2004 12:20 AM To: IETF MARID WG Subject: DOC-BUG (possibly TECH-OMISSION): ietf-marid-core section 5 In section 5.1 "Neutral or None or PermError" the statement is "An SMTP server receiving one of these results SHOULD NOT reject the message for this reason along, but MAY subject the message to heightened scrutiny by other anti-spam measures" I object to using term "other anti-spam measures", this implies that MARID CORE itself described an anti-spam measure where as the purpose of MARID WG is not to create anti-spam mechanism but to fight the problem of phishing which is a result of insecurity in current email infrastructure. I recommend changing the sentence to just "by other measures" or possibly to "by other email security measures" Simularly to above in section 5.4 it has the same statement: "An SMTP server receiving this result SHOULD NOT reject the message for this reason along, but MAY subject the message to heightened scrutiny by other anti-spam measures" I have same objection and recomendation as with 5.1. Also since the statements in 5.1 and 5.4 are basicly the same, it might be easier to combine these sections leaving as separate paragraph about difference of SoftFail, i.e. change to something like: 5.1 Neutral, None, PermError or SoftFail An SMTP server receiving one of these results SHOULD NOT reject the message for this reason along, but MAY subject the message to heightened scrutiny by other email security measures, and MAY reject the message as a result of this heightened scrutiny. Such additional security measures may take into account that message for which the result is "SoftFail" is less likely to be authentic that message for which the result is "Neutral". --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 19:35: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 TAA21029 for ; Fri, 27 Aug 2004 19:35:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RNDFLn070346; Fri, 27 Aug 2004 16:13: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 i7RNDFfr070345; Fri, 27 Aug 2004 16:13:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RNDDUv070339 for ; Fri, 27 Aug 2004 16:13:14 -0700 (PDT) (envelope-from roy+dated+1096240390.4d1d9f@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7RNGrDt037099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Aug 2004 23:16:59 GMT (envelope-from roy+dated+1096240390.4d1d9f@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7RNDAjf077947 for ; Sat, 28 Aug 2004 00:13:10 +0100 (BST) (envelope-from roy+dated+1096240390.4d1d9f@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7RNDAtN077946 for ietf-mxcomp@imc.org; Sat, 28 Aug 2004 00:13:10 +0100 (BST) (envelope-from roy+dated+1096240390.4d1d9f@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 28 Aug 2004 00:13:08 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16687.49156.392378.192142@giles.gnomon.org.uk> Date: Sat, 28 Aug 2004 00:13:08 +0100 To: Rand Wacker Cc: "william(at)elan.net" , IETF MARID WG Subject: Re: TECH-ERROR: Duplication of version number as part of the name for SPF2 dns record (this is possibly TECH-OMISSION) In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Rand" == Rand Wacker writes: >> To fix it is recomended that all references to SPF dns record >> type and examples be changed from "SPF2" to just "SPF" with >> note in the text that such dns type records should confront to >> SPF2.0 or later records. So above example would change to: >> >> example.com. IN SPF "spf2.0/pra +mx +a:colo.examp.e.com/28 >> -all" Rand> This would have the potential of creating *exactly* the same Rand> dataspace problems as stuffing all the different versions in Rand> a TXT record, and would IMO be a bad engineering decision. Possibly. I think that the engineering decision as to whether version 3 should use the same typecode or a new one should be left up to the designers of version 3 -- there is little point in debating it now, given we have no idea what version 3 might be. But given this is going to be the first SPF-syntax record to be defined, I'm in favour of just calling it SPF. If version 3 wants to use it, they can. If they want a new typecode, they can define SPF3. Calling it SPF2 doesn't prevent version 3 from using it, but it will make the naming look a bit silly if the designers of version 3 make that decision. -roy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 19:37: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 TAA21114 for ; Fri, 27 Aug 2004 19:37: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 i7RNFU2w070562; Fri, 27 Aug 2004 16:15: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 i7RNFUV2070561; Fri, 27 Aug 2004 16:15: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 i7RNFTSR070542 for ; Fri, 27 Aug 2004 16:15:30 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 490AAE056E; Fri, 27 Aug 2004 19:15:31 -0400 (EDT) Date: Fri, 27 Aug 2004 19:15:31 -0400 From: John Leslie To: Jim Lyon Cc: Douglas Otis , Matthew Elvey , MXCOMP Subject: Reputation services for SenderID Message-ID: <20040827231531.GI465@verdi> References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jim Lyon wrote: > On Thursday, August 26, 2004 at 5:07 PM, Douglas Otis wrote: > >> The Identity being authorized is the PRA Mailbox Domain by way of >> reference to a Mail Channel prescription of IP addresses. > > No, please try reading it again. The identity being authorized is the > sending MTA's IP address. The action being authorized is to send a > message on behalf of the PRA. The organization doing the authorization > is the domain of the PRA. Jim is exactly right. The SPF2 record specifically authorizes a list of IPs to send mail on behalf of the domain part of the PRA. CSV, on the other hand, authorizes a specific host-name to send mail as directed by the domain which that host-name belongs. Actually, these two functions are remarkably similar: both are optimized to validate the last hop before the recipient domain; neither validates a field ordinarily seen by the recipient of the email. Why are we arguing which way is better? Doug and I both came into this WG concerned about reputation services. We both looked at the SPF record format and despaired of designing a system of reputation services which could say whether a SPF domain is worth trusting. We backed away from that and looked at a hop-by-hop reputation service. This we believed was practical. Our design can be found in the CSV documents. I've been mostly quiet during the SenderID discussions, feeling I don't have much to add. Doug has put forth ideas as they occur to him; sometimes passing them by me first, sometimes not. I wish people were more receptive to his ideas; but that's not the purpose of this email. As the discussion has progressed, I've learned how similar to CSV SenderID actually is. I now believe a system of reputation services could be designed for it. But I'm not sure anyone would like it. We start by agreeing that the exact domain-part of the PRA is the unit to be accredited; and presume some (unspecified) DNS lookup for reputation information. We then evaluate the list of IPs authorized by the SPF2 record, and run them against known IP blacklists; accumulating a score based on weighting the reputation of those blacklists for spam identified, false negatives, and false positives. Now the part you probably won't like: we must assign low weighting to blacklists with high false negatives, while we can't assign low weighting to blacklists with moderate false positives. Worst of all, we can't assign any positive score to IP addresses not on any blacklist. Thus, in essence, we'll be producing ratings _highly_ correlated with the number of IP addresses authorized by the SPF2 record, and even for domains which only authorize a very few IP addresses, we'll have no practical way (except manual processing of requests) to correct outdated blacklist listings. We can, of course, include the suggested-service features of the CSV proposal, but the reputations of suggested services would have to be pretty-darn-good to outweigh the algorithm listed above. Can anybody design a better system of reputation services for SenderID? -- John Leslie From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 19:40: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 TAA21193 for ; Fri, 27 Aug 2004 19:40: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 i7RNIqW5070803; Fri, 27 Aug 2004 16:18: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 i7RNIqQv070802; Fri, 27 Aug 2004 16:18:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RNIpHJ070795 for ; Fri, 27 Aug 2004 16:18:51 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 27 Aug 2004 16:16:31 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Aug 2004 16:16:22 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 16:16:30 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 16:16:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7384.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: DNS Record Types Date: Fri, 27 Aug 2004 16:16:30 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF8FB034@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: DEPLOY: DNS Record Types Thread-Index: AcSMhHXi4RK6VwafSX2q92A1qU21fAABtzKw From: "Jim Lyon" To: "David Blacka" , X-OriginalArrivalTime: 27 Aug 2004 23:16:19.0121 (UTC) FILETIME=[DBEB9A10:01C48C8B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RNIqHJ070797 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Friday, August 27, 2004 at 3:10 PM, David Blacka writes: > Why not: > SHOULD publish SPF2 > MAY publish TXT > MUST publish at least one of the two. Because if you publish an SPF2 record without a TXT record, those of us who can't query for an SPF2 record will conclude that you didn't publish anything. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 20:06:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22227 for ; Fri, 27 Aug 2004 20:06:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RNhfbJ072273; Fri, 27 Aug 2004 16:43: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 i7RNhfb1072272; Fri, 27 Aug 2004 16:43:41 -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 i7RNhes7072260 for ; Fri, 27 Aug 2004 16:43:40 -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; 27 Aug 2004 16:50:45 +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 i7RNha2O010876; Fri, 27 Aug 2004 16:43:37 -0700 (PDT) Received: from fenton-w2k01.cisco.com (dhcp-128-107-163-65.cisco.com [128.107.163.65]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7RNkRkZ021385; Fri, 27 Aug 2004 16:46:29 -0700 Message-Id: <4.3.2.7.2.20040827163853.02ff1700@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Aug 2004 16:43:36 -0700 To: John Leslie , Jim Lyon From: Jim Fenton Subject: Re: Reputation services for SenderID Cc: Douglas Otis , Matthew Elvey , MXCOMP In-Reply-To: <20040827231531.GI465@verdi> References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.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:"1093650389.791180"; x:"432000"; a:"rsa-sha1"; b:"0:1815"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"R1NY+7vseNfX820b4yMwH4pKjVC66J5yCNwtJUE8XNdXlp1pnvDBISgtpRWtH" "MYpMD4mJ6VCvSYMWIgCdPaZrOupfbgUqx+EAl1IO9fOsDyEyB1GvXlPAcowo7" "6cMLBafuRdRzGSLsaN0F80zI26LqOjAMEUBnBLCVJbKCBiaec="; c:"Date: Fri, 27 Aug 2004 16:43:36 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: Reputation services for SenderID" 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: I'm hesitant to discuss this on the list right now, during last call, but briefly: You seem to be describing the problems associated with arriving at a reputation for the domain-part of a PRA, given that you have a reputation database that's keyed by MTA address. But wouldn't it be possible to create a reputation database based on the domain-part of the PRA itself? I don't think this is by any means a trivial task, though. -Jim At 07:15 PM 8/27/2004 -0400, John Leslie wrote: > We start by agreeing that the exact domain-part of the PRA is the >unit to be accredited; and presume some (unspecified) DNS lookup for >reputation information. > > We then evaluate the list of IPs authorized by the SPF2 record, >and run them against known IP blacklists; accumulating a score based >on weighting the reputation of those blacklists for spam identified, >false negatives, and false positives. > > Now the part you probably won't like: we must assign low weighting >to blacklists with high false negatives, while we can't assign low >weighting to blacklists with moderate false positives. Worst of all, >we can't assign any positive score to IP addresses not on any blacklist. > > Thus, in essence, we'll be producing ratings _highly_ correlated >with the number of IP addresses authorized by the SPF2 record, and >even for domains which only authorize a very few IP addresses, we'll >have no practical way (except manual processing of requests) to >correct outdated blacklist listings. > > We can, of course, include the suggested-service features of the >CSV proposal, but the reputations of suggested services would have >to be pretty-darn-good to outweigh the algorithm listed above. > > Can anybody design a better system of reputation services for >SenderID? From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 20: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 UAA22249 for ; Fri, 27 Aug 2004 20: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 i7RNhHsC072250; Fri, 27 Aug 2004 16:43:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RNhHCq072249; Fri, 27 Aug 2004 16:43:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RNhHv3072242 for ; Fri, 27 Aug 2004 16:43:17 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7RNhH77032072 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 27 Aug 2004 19:43:18 -0400 Subject: RE: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages From: Mark Shewmaker To: MARID Cc: Jim Lyon In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1093650303.3782.3839.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 27 Aug 2004 19:45:03 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Fri, 27 Aug 2004 19:43:20 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-27 at 17:48, Jim Lyon wrote: > On Thursday, August 26, 2004 at 4:20 PM, Mark Shewmaker wrote (regarding > the need to generate a DSN if 7 conditions hold): > > > The only way to solve this problem would be to allow for an override > > of the must-accept-100-recipients requirement in RFC 2821. > > True. This would help, and is probably a good idea. But it's outside the > scope of MARID. If we can't solve the problem within the scope of MARID, that would leave us with requiring complying implementations to open themselves to what I consider a security hole. However, I just realized that I made a mistake that's caused me to frame the issue incorrectly, and this leads to a solution that I hope is within the scope of MARID. Here is my original objection, shortened considerably, written such that it includes my mistake: 1. RFC 2821 says we must accept-and-deliver, reject, or send DSNs. 2. RFC 2821 also says we need to accept at least 100 recipients. But if we accept recipients with differing white lists, and we obey (1) and (2) above, we expose ourselves to a vulnerability in the 7-conditions case The only solutions to that are to violate either (1) or (2). I don't like the notion of violating (1), as I consider it lying/deceitful behavior, so I would prefer to violate (2). So I would like something in SenderID that says it's okay to violate (2) in this case. My error was that requirement (2) isn't what I thought and stated above. Quoting RFC2821: |recipients buffer | The minimum total number of recipients that must be buffered is | 100 recipients. Rejection of messages (for excessive recipients) | with fewer than 100 RCPT commands is a violation of this | specification. But we wouldn't be rejecting messages because there are excessive recipients, we'd really be rejecting them because they are, well, incompatible recipients. A fine distinction, perhaps, but I take it to mean that we can reject at the first recipient with a differing white list, and not only would we not be in violation of RFC 2821, we'd not have to have Sender ID overrule this section of RFC 2821 either. Just instead of claiming the reason being a "too many recipients" error, claim something more appropriate to for a recipient filtering incompatibility problem, maybe a 4.7.0 perhaps. (I'm not sure what would be the most appropriate response code.) So, is that suggestion something that could be included within SenderID, perhaps in a security-considerations section? Or perhaps a best-current-practices document? Otherwise we're effectively suggesting that folks open themselves up to an avoidable vulnerability without pointing out how it's avoidable. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 20:22: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 UAA23432 for ; Fri, 27 Aug 2004 20:22: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 i7S01E5U073424; Fri, 27 Aug 2004 17:01: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 i7S01EDO073423; Fri, 27 Aug 2004 17:01:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.courier-mta.com (mail.courier-mta.com [216.254.115.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S01DPS073417 for ; Fri, 27 Aug 2004 17:01:13 -0700 (PDT) (envelope-from mrsam@courier-mta.com) Received: from localhost (localhost [127.0.0.1]) (uid 8) by commodore.email-scan.com with local; Fri, 27 Aug 2004 20:01:16 -0400 id 000000000015766A.00000000412FCB4C.0000169E X-IMAP-Sender: mrsam@courier-mta.com Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Sam Varshavchik To: IETF MARID WG Cc: courier-users@lists.sourceforge.net, courier-announce@lists.sourceforge.net X-PGP-KEY: http://www.courier-mta.org/KEYS.bin Subject: DEPLOY: SPF/Sender ID support in Courier. Date: Fri, 27 Aug 2004 20:01:16 -0400 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-21385-1093651276-0012"; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. --=_mimegpg-commodore.email-scan.com-21385-1093651276-0012 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Please watch your followups, as this message is sent to multiple lists. The purpose of this message is to clarify my plans for any deployment of the Sender-ID specification in Courier (http://www.courier-mta.org). Microsoft has made certain patent claims on the Sender-ID specification. Microsoft has issued the IPR disclosures and royalty free license required by the IETF. It appears that IETF's contemporary policies do not prevent the sponsor/advocates from including patented IP material into standards-track specifications, without even requiring the sponsor to actually enumerate and identify their intellectual property; a mere claim of the existence of some nebulous IP rights is sufficient, which can be revealed at any point in the future, at the sponsor's discretion. The current development version of Courier implements the original SPF-classic specification, that predates Sender-ID. This will be rolled into a forthcoming release. I'm quite pleased with the results so far -- there are a lot of classic SPF records in existence, as witnessed by my mail logs :-) It will not be possible for me to implement Sender ID in Courier. Courier is licensed under the GPL. The FSF already flatly stated that Microsoft's IP license is not GPL compatible. I reviewed the most recent version of Microsoft's proposed IP license, and I've reached the same conclusion. For this reason Sender ID cannot be implemented in Courier; Courier's implementation will be limited to the unencumbered SPF-classic. -- Sam Varshavchik http://www.courier-mta.org --=_mimegpg-commodore.email-scan.com-21385-1093651276-0012 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBL8tMx9p3GYHlUOIRAmIqAJ9CthWPa/xOYVYG14xn/30R7POpFgCdHeLm 1YNzBWV/fyKFRIY1rjSiun4= =OlGd -----END PGP SIGNATURE----- --=_mimegpg-commodore.email-scan.com-21385-1093651276-0012-- From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 20:30: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 UAA23812 for ; Fri, 27 Aug 2004 20:30:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S09gYN074492; Fri, 27 Aug 2004 17:09: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 i7S09gKa074491; Fri, 27 Aug 2004 17:09:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S09gge074289 for ; Fri, 27 Aug 2004 17:09:42 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i7S08g3V022007; Fri, 27 Aug 2004 17:08:42 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id B83BC84F866; Fri, 27 Aug 2004 17:08:42 -0700 (PDT) Date: Fri, 27 Aug 2004 17:08:42 -0700 From: "Mark C. Langston" To: Jim Fenton Cc: John Leslie , MXCOMP Subject: Re: Reputation services for SenderID Message-ID: <20040828000842.GL36586@bitshift.org> References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> <4.3.2.7.2.20040827163853.02ff1700@mira-sjc5-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20040827163853.02ff1700@mira-sjc5-1.cisco.com> User-Agent: Mutt/1.4.1i X-Uptime: 5:00PM up 74 days, 1:07, 6 users, load averages: 0.04, 0.04, 0.01 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 27, 2004 at 04:43:36PM -0700, Jim Fenton wrote: > > I'm hesitant to discuss this on the list right now, during last call, > but briefly: > > You seem to be describing the problems associated with arriving at a > reputation for the domain-part of a PRA, given that you have a > reputation database that's keyed by MTA address. But wouldn't it be > possible to create a reputation database based on the domain-part of > the PRA itself? > The GOSSiP Project (http://sufficiently-advanced.net/ ) could handle this, I believe. Right now, it's using as an identity the RHS from RFC2821 MAIL FROM: and the sender's IP address as reported by the MTA. However, this same approach could be used for any arbitrary identity scheme. All that would be necessary would be agreeing to the structure of an ID to use for submission of PRA data to a GOSSiP node. In fact, the current GOSSiP id approach and a method of tracking PRA reputation within GOSSiP could be used simultaneously. We're about a week or two away from a limited test release, and are aiming for an initial public release sometime in November. -- Mark C. Langston GOSSiP Project Sr. Unix SysAdmin mark@bitshift.org http://sufficiently-advanced.net mark@seti.org Systems & Network Admin Distributed SETI Institute http://bitshift.org E-mail Reputation http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 21:19: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 VAA26258 for ; Fri, 27 Aug 2004 21:19: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 i7S0rpLa077371; Fri, 27 Aug 2004 17:53:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S0rpt6077370; Fri, 27 Aug 2004 17:53:51 -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 i7S0roP4077364 for ; Fri, 27 Aug 2004 17:53:50 -0700 (PDT) (envelope-from roy+dated+1096246428.a307c5@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7S0vX77048357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 28 Aug 2004 00:57:39 GMT (envelope-from roy+dated+1096246428.a307c5@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7S0rnRg000716 for ; Sat, 28 Aug 2004 01:53:49 +0100 (BST) (envelope-from roy+dated+1096246428.a307c5@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7S0rm5u000715 for ietf-mxcomp@imc.org; Sat, 28 Aug 2004 01:53:48 +0100 (BST) (envelope-from roy+dated+1096246428.a307c5@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 28 Aug 2004 01:53:48 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16687.55196.229533.14444@giles.gnomon.org.uk> Date: Sat, 28 Aug 2004 01:53:48 +0100 To: ietf-mxcomp@imc.org Subject: DEPLOY: Sender ID license is acceptable 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 In summary, I believe that the Sender ID license, whilst somewhat burdonsome to distributors of code, poses no major difficulties with the GPL or other major open source licenses, and offers significant benefits to both the open source community and the industry as a whole. I support the drafts being advanced in their current form (subject to editorial nits and minor technical corrections). There may be scope for further discussion between the open source community and Microsoft, and there is nothing to prevent Microsoft offering an alternative patent license in the future as a result of the outcome of that discussion. But I see nothing in the current license that would justify rejecting or delaying the drafts that are before us. This is a defensive patent license. It's purpose is to prevent other people suing not just Microsoft, but all of us. Microsoft have drafted it in a way to protect the community as a whole -- and not just themselves -- from patent claims of third parties, and for this they should be commended. I suspect that anyone who believes Microsoft have some plot to try to monopolize Sender ID hasn't actually read and understood the license. It's a pain you have to sign it, but somehow I don't think that a shrink-wrap reciprocal patent grant would hold water in any jurisdiction. Justification: (Disclaimer: IANAL, and I'm way behind in reading the list given its recent volume, so some of this may have been covered before) GPL is a copyright license, the Sender ID licence is a patent license. As such there is fairly limited scope for them to be incompatible (in the traditional sense of incompatibility of software licenses). The only circumstance that I'm aware of in which a patent claim (and its licensing terms) can be incompatible with the GPL is that the GPL prevents a distributor of the code from placing additional restrictions on the recipients. Eben Moglen has made it clear in the past that his (and the FSF's) position is that asserting patent claims with a restrictive license in his opinion constitutes placing additional restrictions for the purposes of the GPL. But the point is that this makes the Sender ID license incompatible with the GPL for Microsoft only. Microsoft will (by this interpretation of the GPL) be unable to redistribute other people's GPL'd code that incorporates the Sender ID invention, since Microsoft, by means of their patent claims, are placing restrictions (additional to the GPL) on what the recipient may do with it. I suspect Microsoft can live with that :-) On the other hand, if _I_ redistribute GPL'd code that incorporates the Sender ID invention, I haven't violated the GPL, since _I_ have placed no additional restrictions on what the recipient can do. This applies whether or not I have signed the Sender ID license. The Sender ID license doesn't require me to place additional restrictions on the recipients; it simply requires me to inform the recipients of the restrictions that Microsoft (might be) placing on them. Granted, the requirement to execute a license agreement is burdonsome, but it's not the end of the world. Probably many distributors of software will fail to do so, out of oversight more than anything else. If they don't execute an agreement, what will happen? How is their situation worse than with anything else they distribute? There could be unknown patent claims on anything. In the case of the Sender ID license, the probability of Microsoft choosing to sue a distributor who didn't execute a license is probably small. If Microsoft did sue, the chances of them winning any damages would be slight, given they would not have suffered any financial losses (since the license is royalty free anyway), unless the distributor also had a patent on some aspect of Sender ID. In reality, if Microsoft were to take any action at all, it would probably be to contact the distributor and insist that they sign the patent license. I'm not in any way advocating distributing Sender ID implementations without executing an agreement with Microsoft, or suggesting this would be a sensible course of action. But I suspect that the risks to a distributor who does so are actually much smaller than the risks that they take with most of the other software they distribute. As for the compatibility issue, I think it all boils down to what you meen by 'compatible'. This is very different from the problem of compatibility between open source copyright licenses. There is a very real problem that given a work A with a copyright licence L_A and a work B with a copyright license L_B, if you create AB, which is a derived work of both A and B, there exists _no_ license under which you can legally distribute AB without violating either L_A or L_B (or both). The Sender ID license, being a patent license, doesn't create this kind of difficulty. It may be incompatible with the principle of open source and free software license in some peoples eyes, but I don't see that it poses significant problems to open/free software. Even if I'm mistaken on this last point, most (all?) of the major MTAs support a plug-in architecture (and those that don't could grow one if need be). There's nothing to stop Sender ID plug-ins being distributed as separate packages if (for some reason) it can't be incorporated into the core distribution. I'd also point out that this license is actually rather good for the community as a whole (both open source and commercial). The reciprocal license grant provision requires any other patent holders to grant a patent license not just to Microsoft, but to everyone else as well. At a time when the open source community is becoming increasingly concerned about the possibility of patent suits against them, I would suggest that this license gains the open source community far more that it loses. -roy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 21:25:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26567 for ; Fri, 27 Aug 2004 21:25:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S16FfV078080; Fri, 27 Aug 2004 18:06:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S16FhA078079; Fri, 27 Aug 2004 18:06:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S16EWv078072 for ; Fri, 27 Aug 2004 18:06:14 -0700 (PDT) (envelope-from roy+dated+1096247173.1ffdb1@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7S19von049552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 28 Aug 2004 01:10:03 GMT (envelope-from roy+dated+1096247173.1ffdb1@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7S16DE8000826 for ; Sat, 28 Aug 2004 02:06:13 +0100 (BST) (envelope-from roy+dated+1096247173.1ffdb1@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7S16DFj000825 for ietf-mxcomp@imc.org; Sat, 28 Aug 2004 02:06:13 +0100 (BST) (envelope-from roy+dated+1096247173.1ffdb1@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 28 Aug 2004 02:06:12 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16687.55940.84075.510780@giles.gnomon.org.uk> Date: Sat, 28 Aug 2004 02:06:12 +0100 To: Sam Varshavchik Cc: IETF MARID WG Subject: DEPLOY: SPF/Sender ID support in Courier. In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [Distribution trimmed] >>>>> "Sam" == Sam Varshavchik writes: Sam> It appears that IETF's contemporary policies do not prevent Sam> the sponsor/advocates from including patented IP material Sam> into standards-track specifications, without even requiring Sam> the sponsor to actually enumerate and identify their Sam> intellectual property How is this worse that if Microsoft hadn't been involved in the MARID group and the WG had come up with a similar proposal independently. In that case you wouldn't have even known about the patent claims, but it wouldn't have made them less relevent. Sam> It will not be possible for me to implement Sender ID in Sam> Courier. Courier is licensed under the GPL. The FSF already Sam> flatly stated that Microsoft's IP license is not GPL Sam> compatible. That would be unforunate, and I think also misguided. The licenses may well be technically incompatible, but that effects no-one but Microsoft. You, as the distributor of courier, will only be distributing code under the GPL. You will _not_ be granting rights under the Sender ID patent grant, and more to the point you will not (I assume) be making any patent claims on Sender ID. The only entity that _might_ have to worry about the compatibility of the licenses is Microsoft, and given they don't tend to distribute much third-party GPL'd code, I suspect they can live with that. IANAL, I could be wrong, but I don't think I am. See also my recent post to the MARID list on this subject. -roy From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 21:25: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 VAA26574 for ; Fri, 27 Aug 2004 21:25: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 i7S13gug077970; Fri, 27 Aug 2004 18:03: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 i7S13gh6077969; Fri, 27 Aug 2004 18:03: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 i7S13f6m077963 for ; Fri, 27 Aug 2004 18:03:41 -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 CE5C8414ED; Fri, 27 Aug 2004 18:03:47 -0700 (PDT) Received: from 69.36.229.218 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Fri, 27 Aug 2004 18:03:47 -0700 (PDT) Message-ID: <60954.69.36.229.218.1093655027.squirrel@harry.mail-abuse.org> In-Reply-To: <4.3.2.7.2.20040827163853.02ff1700@mira-sjc5-1.cisco.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com><81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> <4.3.2.7.2.20040827163853.02ff1700@mira-sjc5-1.cisco.com> Date: Fri, 27 Aug 2004 18:03:47 -0700 (PDT) Subject: Re: Reputation services for SenderID From: "Douglas Otis" To: "Jim Fenton" Cc: "John Leslie" , "Jim Lyon" , "Douglas Otis" , "Matthew Elvey" , "MXCOMP" 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 The significant problem I see with depending upon the authorized PRA Mailbox Domain for assessing complaints is that this identity has not been authenticated. What the PRA Mailbox Domain provides is whatever can be deduced about the message emerging from an otherwise anonymous MTA where only the IP address is certain. If one were to expect that when a PRA Mailbox Domain is using an MTA with a decidedly blacklisted IP address, then by extension all the published MTA addresses for this PRA Mailbox Domain should be blacklisted. That would be a fatal conclusion. It would be difficult to conclude anything about the message content which formed the premise for the PRA Mailbox Domain while the trustworthiness of the MTA remains unknown. Is this domain using an "open-ended" list? Is this a shared MTA? Is the recipient's mail relay secure. Has all the MTA servers performed the required PRA Mailbox Domain to Mail Channel prescription checks? It gets ugly. There will be an endless array of fingers pointing in every direction, but the domain being harmed by the reputation assertion will be pointing their finger at the reputation service. There is far too much uncertainty in this for any assertions to be applied with respect to a Mailbox Domain against a Mail Channel prescription other than to say the message is authorized or not. It would even be dangerous to treat "authorized" as having any great significance. It is vital for a reputation service that the identity used be authenticated and not just authorized. In other words, is it reasonable to assume this entity is the bad actor? Some may take the attitude they should find a better mail provider should they get listed. It may not have been their mail provider at fault however. Mail gets relayed through administrative domains where, at any point, there may be a lapse in control over access to the mail channel. This is why it is vital that reputation services be built upon the CSV results, rather than depending upon the Sender-ID identity to serve this function. If the expected outcome of all the finger pointing results in the routine insertion of a Resent-From header, then there is virtually no difference between the identities being used between CSV and Sender-ID at that point. There is a significant difference in the strength of the authentication of these identities however. CSV isolates the authentication to a single administrative domain. Sender-ID may isolate the authentication to hundreds of administrative domains. This is a huge difference when one is attempting to block the bad actor, but where the bad actor may be masquerading as one of any of these administrative domains. Worse yet, if there is an "open-ended" list used, then the bad actor could be anyone regardless of the level of certainty obtained from Sender-ID due to the problem of "validation promotion". -Doug > I don't think this is by any means a trivial task, though. > > -Jim > > At 07:15 PM 8/27/2004 -0400, John Leslie wrote: >> We start by agreeing that the exact domain-part of the PRA is the >>unit to be accredited; and presume some (unspecified) DNS lookup for >>reputation information. >> >> We then evaluate the list of IPs authorized by the SPF2 record, >>and run them against known IP blacklists; accumulating a score based >>on weighting the reputation of those blacklists for spam identified, >>false negatives, and false positives. >> >> Now the part you probably won't like: we must assign low weighting >>to blacklists with high false negatives, while we can't assign low >>weighting to blacklists with moderate false positives. Worst of all, >>we can't assign any positive score to IP addresses not on any blacklist. >> >> Thus, in essence, we'll be producing ratings _highly_ correlated >>with the number of IP addresses authorized by the SPF2 record, and >>even for domains which only authorize a very few IP addresses, we'll >>have no practical way (except manual processing of requests) to >>correct outdated blacklist listings. >> >> We can, of course, include the suggested-service features of the >>CSV proposal, but the reputations of suggested services would have >>to be pretty-darn-good to outweigh the algorithm listed above. >> >> Can anybody design a better system of reputation services for >>SenderID? > From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 21:50: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 VAA27469 for ; Fri, 27 Aug 2004 21:50: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 i7S1RuKm079283; Fri, 27 Aug 2004 18:27: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 i7S1RufC079282; Fri, 27 Aug 2004 18:27:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S1Rt6d079276 for ; Fri, 27 Aug 2004 18:27:55 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7S1S1Ia019392; Fri, 27 Aug 2004 18:28:01 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 27 Aug 2004 18:28:01 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: RE: on the topic of IPR Date: Fri, 27 Aug 2004 18:28:00 -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: > Hallam-Baker, Phillip wrote: > > > >>I was one of those people who openly speculated about > >>Microsoft usurping SPF. > > > >>From a PR standpoint I somehow doubt that Microsoft is going to > > be known primarily for having created SenderID in ten years time. > > > > As Markus Stumpf pointed out, Microsoft created Caller-ID, while > Sender-ID is the product of this group. My point was that the fear that Microsoft would somehow gain undeserved prominence from or 'usurp' SenderID is misplaced. I don't think it figures. > > To obtain a WS-Security license all you have to do is to fill > > in a Web form. Sure I do not like to have to do this just to > > visit the Washington Post or New York Times, but I am prepared > > to put up with a minor piece of inconvenience. > > There is a crucial difference here. WS-Security, and many other > standards out there are not nearly as prevalent and largely used as > email standards are. The only things that have similar market > effects is > the Eolas patent and the TCP/IP security IPR issues with Cisco. The Eolas patent covers work that I did before the alleged inventor. Microsoft has clearly decided it is not going to get taken by another Eolas type patent. Short of the USPTO burning down a second time and all records being lost (if only!) the only way to get any protection against a patent suit is to file for a patent yourself and hope you got yours in first. Then you file continuations and interference claims for 20 years. From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 22:21: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 WAA28919 for ; Fri, 27 Aug 2004 22:21:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S1xtQw081789; Fri, 27 Aug 2004 18:59:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S1xtbJ081788; Fri, 27 Aug 2004 18:59:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S1xsiX081779 for ; Fri, 27 Aug 2004 18:59:54 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7S1wlJP016890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Aug 2004 21:58:52 -0400 Subject: Re: DEPLOY: Sender ID license is acceptable From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: <16687.55196.229533.14444@giles.gnomon.org.uk> References: <16687.55196.229533.14444@giles.gnomon.org.uk> Content-Type: text/plain Message-Id: <1093658280.7023.118.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 27 Aug 2004 21:58:00 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-08-27 at 20:53, Roy Badami wrote: > In summary, I believe that the Sender ID license, whilst somewhat > burdonsome to distributors of code, poses no major difficulties with > the GPL or other major open source licenses, and offers significant > benefits to both the open source community and the industry as a > whole. I'll start off with a question regarding the stated guidelines of Last Call. And it is an honest question, not in any way trying to corner you or meant in a sarcastic way, because I honestly don't know the answer. Are the author of any open source software or Free Software? In particular, is any software you write and/or modify-distribute covered under the GPL? I ask this because in the guidelines posted for discussing Last Call issues, we have been instructed to not speak for others, only ourselves. If Roy is not the author or modifier-distributor of GPLed or other FOSS licensed software, I would request that the co-chairs disregard all comments made in his post about the GPLed or other FOSS licensed software in his post, since he is not speaking for himself. If Roy is the author or modifier-distributor of GPLed or other FOSS licensed software, then disregard my previous two paragraphs as I move on to my further rebuttals. > I support the drafts being advanced in their current form (subject to > editorial nits and minor technical corrections). > > There may be scope for further discussion between the open source > community and Microsoft, and there is nothing to prevent Microsoft > offering an alternative patent license in the future as a result of > the outcome of that discussion. Any future possible changes are irrelevant. All that is relevant is that the current license is unacceptable. Submitting a proposed standard with known IPR problems in the likely vain hope that they will be resolved AFTER being ratified is foolhardy. > But I see nothing in the current > license that would justify rejecting or delaying the drafts that are > before us. You are entitled to your opinion, but don't speak for others, as the majority of your post below does. > This is a defensive patent license. It's purpose is to prevent other > people suing not just Microsoft, but all of us. Microsoft have > drafted it in a way to protect the community as a whole -- and not > just themselves -- from patent claims of third parties, and for this > they should be commended. Has Microsoft told you that that is the purpose of this license? I beg to differ, if it hasn't. But debating the purpose of this license will accomplish nothing. It's the effect that matters here, not its intended effect. See below for more. > I suspect that anyone who believes Microsoft have some plot to try to > monopolize Sender ID hasn't actually read and understood the license. As you point out below, you haven't kept up on the list. Almost ALL, maybe indeed ALL of the posters that have discussed this topic do seem to have, indeed, read the license AND the GPL and other licenses and concluded that the patent license conflicts with many of these licenses. Few, if any, have discussed 'plots' during this Last Call period regarding IPR issues. > It's a pain you have to sign it, but somehow I don't think that a > shrink-wrap reciprocal patent grant would hold water in any > jurisdiction. > > Justification: > > (Disclaimer: IANAL, and I'm way behind in reading the list given its > recent volume, so some of this may have been covered before) Then perhaps you should catch up, at least on the IPR threads. That's not a jab at you. I'm suggesting that you should mainly because of your IANAL disclaimer. To date, three lawyers have given their evaluation of the license (Eben Moglen, Larry Rosen, and Anne P. Mitchell, Esq.) and all concluded the same thing: that this patent license is NOT compatible with many FOSS licenses, not just the GPL. > GPL is a copyright license, the Sender ID licence is a patent license. > > As such there is fairly limited scope for them to be incompatible (in > the traditional sense of incompatibility of software licenses). Quite the opposite. A patent license causes much more trouble because ALL implementations are covered by it. If the implementation of the standard in GPL software imposes additional restrictions on the software, then directly it conflicts with at least section 6 of the GPL. > The only circumstance that I'm aware of in which a patent claim (and > its licensing terms) can be incompatible with the GPL is that the GPL > prevents a distributor of the code from placing additional > restrictions on the recipients. Which this license does. It restricts their distribution of the software unless they sign a license with Microsoft. > Eben Moglen has made it clear in the > past that his (and the FSF's) position is that asserting patent claims > with a restrictive license in his opinion constitutes placing > additional restrictions for the purposes of the GPL. > > But the point is that this makes the Sender ID license incompatible > with the GPL for Microsoft only. > > Microsoft will (by this interpretation of the GPL) be unable to > redistribute other people's GPL'd code that incorporates the Sender ID > invention, since Microsoft, by means of their patent claims, are > placing restrictions (additional to the GPL) on what the recipient may > do with it. I suspect Microsoft can live with that :-) No. ALL licensees of the patent are restricted from distributing Sender-ID implementations without executing a license with Microsoft. That's clear from section 2.2 of the license. > On the other hand, if _I_ redistribute GPL'd code that incorporates > the Sender ID invention, I haven't violated the GPL, since _I_ have > placed no additional restrictions on what the recipient can do. This > applies whether or not I have signed the Sender ID license. The > Sender ID license doesn't require me to place additional restrictions > on the recipients; it simply requires me to inform the recipients of > the restrictions that Microsoft (might be) placing on them. Then you, who are not a lawyer, are in disagreement with the opinion of the only three lawyers whose evaluations of this license have been posted. I think I'll go with what the lawyers say. > Granted, the requirement to execute a license agreement is burdonsome, > but it's not the end of the world. Nobody has suggested that. But three lawyers agree that it would be a serious problem for FOSS software. > Probably many distributors of software will fail to do so, out of > oversight more than anything else. If they don't execute an > agreement, what will happen? How is their situation worse than with > anything else they distribute? There could be unknown patent claims > on anything. And what weight does that carry? As I've said before, we have a KNOWN patent here. Or at least *somewhat* known, since Microsoft hasn't been clear exactly what it has a patent (or patent-pending) on. > In the case of the Sender ID license, the probability of Microsoft > choosing to sue a distributor who didn't execute a license is probably > small. If Microsoft did sue, the chances of them winning any damages > would be slight, given they would not have suffered any financial > losses (since the license is royalty free anyway), unless the > distributor also had a patent on some aspect of Sender ID. It's not about any IPR holder winning any damages...it's about MTA authors signing a license -- and therefore giving control over a portion of their products -- to a competitor. > In reality, if Microsoft were to take any action at all, it would > probably be to contact the distributor and insist that they sign the > patent license. Which would force them, at least in the case of the GPL (likely others), to violate the license of the software. > I'm not in any way advocating distributing Sender ID implementations > without executing an agreement with Microsoft, or suggesting this > would be a sensible course of action. But I suspect that the risks to > a distributor who does so are actually much smaller than the risks > that they take with most of the other software they distribute. Then why present an argument based on it? > As for the compatibility issue, I think it all boils down to what you > meen by 'compatible'. This is very different from the problem of > compatibility between open source copyright licenses. Not as much as you represent. But that is my opinion. Not that it matters... > There is a very > real problem that given a work A with a copyright licence L_A and a > work B with a copyright license L_B, if you create AB, which is a > derived work of both A and B, there exists _no_ license under which > you can legally distribute AB without violating either L_A or L_B (or > both). > The Sender ID license, being a patent license, doesn't create this > kind of difficulty. It may be incompatible with the principle of open > source and free software license in some peoples eyes, but I don't see > that it poses significant problems to open/free software. But three lawyers do. Lawyers who understand these licenses pretty thoroughly. Though I don't know Anne P. Mitchell beyond this list -- this discussion, however, is the event that will etch her name in my mind along side the next two -- at least Eben Moglen and Larry Rosen should be familiar to anyone who knows anything about FOSS. > Even if I'm mistaken on this last point, most (all?) of the major MTAs > support a plug-in architecture (and those that don't could grow one if > need be). There's nothing to stop Sender ID plug-ins being > distributed as separate packages if (for some reason) it can't be > incorporated into the core distribution. Except that it would still present a problem for distributors of 'compilations' that provide mirrors systems and complete redistribute-ability of their software. Witness at least Red Hat's Fedora and Debian. Neither of those could maintain their current distribution models and freedoms they give those who download it, who are given permission to redistribute without signing any agreement with anyone. > I'd also point out that this license is actually rather good for the > community as a whole (both open source and commercial). Once again, please don't speak for the open source community. Speak for yourself in this context. > The > reciprocal license grant provision requires any other patent holders > to grant a patent license not just to Microsoft, but to everyone else > as well. But there are no other patent holders. Submarine patent holders and patent pooling companies can be dealt with in other ways. There is no need to tie us to any corporate entity in order to fight this. > At a time when the open source community is becoming increasingly > concerned about the possibility of patent suits against them, I would > suggest that this license gains the open source community far more > that it loses. Your suggestion is wrong. I *loose* the ability to make my (currently conceptual) changes to Exim in order to implement Sender-ID without violating the GPL license it is covered under. Another is example is Sam Varshavchik has also described the problem it creates for him as the author of Courier-MTA. I'll let him speak for himself and just point you to: http://www.imc.org/ietf-mxcomp/mail-archive/msg03810.html. There have been others, and for that I can only suggest catching up on the Last Call discussion about IPR issues. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 22:28:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29211 for ; Fri, 27 Aug 2004 22:28:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S27TCu082314; Fri, 27 Aug 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 i7S27TWn082313; Fri, 27 Aug 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 mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S27SUX082307 for ; Fri, 27 Aug 2004 19:07:28 -0700 (PDT) (envelope-from davidb@verisignlabs.com) Received: from [192.168.1.13] ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 27 Aug 2004 22:07:29 -0400 id 002E0A27.412FE8E1.00003A09 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FB034@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FB034@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <042F39C5-F897-11D8-A992-000A95CC77E2@verisignlabs.com> Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DEPLOY: DNS Record Types Date: Fri, 27 Aug 2004 22:07:30 -0400 To: ietf-mxcomp@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 7:16 PM, Jim Lyon wrote: > On Friday, August 27, 2004 at 3:10 PM, David Blacka writes: > >> Why not: >> SHOULD publish SPF2 >> MAY publish TXT >> MUST publish at least one of the two. > > Because if you publish an SPF2 record without a TXT record, those of us > who can't query for an SPF2 record will conclude that you didn't > publish > anything. Just make it clear what it means to not publish the TXT or not publish the SPF2. Then it is the publishers choice. My real point was adding the 3rd line, not quibbling over whether TXT should be a MAY or a SHOULD. -- David Blacka Sr. Engineer Verisign Applied Research From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 22:46:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00021 for ; Fri, 27 Aug 2004 22:46:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S2QgxP083170; Fri, 27 Aug 2004 19: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 i7S2Qg4u083169; Fri, 27 Aug 2004 19:26:42 -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 i7S2QfwY083161 for ; Fri, 27 Aug 2004 19:26:41 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7S2ZCJv011336; Fri, 27 Aug 2004 19:35:12 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7S2ZCiv011333; Fri, 27 Aug 2004 19:35:12 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 27 Aug 2004 19:35:12 -0700 (PDT) From: "william(at)elan.net" To: Jim Lyon cc: David Blacka , Subject: RE: DEPLOY: DNS Record Types In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FB034@df-fido-msg.exchange.corp.microsoft.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, 27 Aug 2004, Jim Lyon wrote: > > On Friday, August 27, 2004 at 3:10 PM, David Blacka writes: > > > Why not: > > SHOULD publish SPF2 > > MAY publish TXT > > MUST publish at least one of the two. > > Because if you publish an SPF2 record without a TXT record, those of us > who can't query for an SPF2 record will conclude that you didn't publish > anything. That is why we should have a MUST for looking up SPF RR record. Its been shown (including with Microsoft products) that grabbing arbitrary data type in dns (including new data type by its number) can be done using existing low-level dns libraries. Its true that these "uknown" data types can not be interpreted by the library and will be just a binary data but for the SPF data format that is exactly what is needed and its up to the client to interpret it. So in my view there is no reason why we should NOT have clients be REQUIRED to lookup up new SPF RR records. But its additional matter that if they don't get the answer they may want to lookup TXT. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Aug 27 23: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 XAA03118 for ; Fri, 27 Aug 2004 23: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 i7S3BPDe085534; Fri, 27 Aug 2004 20:11: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 i7S3BPjZ085533; Fri, 27 Aug 2004 20:11:25 -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 i7S3BOVW085520 for ; Fri, 27 Aug 2004 20:11:24 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 89662 invoked by uid 1013); 28 Aug 2004 03:11:19 -0000 Date: Sat, 28 Aug 2004 05:11:19 +0200 From: Markus Stumpf To: "Hallam-Baker, Phillip" Cc: "'Yakov Shafranovich'" , IETF MARID WG Subject: Re: on the topic of IPR Message-ID: <20040828031119.GM30023@Space.Net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 27, 2004 at 06:28:00PM -0700, Hallam-Baker, Phillip wrote: > > As Markus Stumpf pointed out, Microsoft created Caller-ID, while > > Sender-ID is the product of this group. > > My point was that the fear that Microsoft would somehow gain > undeserved prominence from or 'usurp' SenderID is misplaced. > I don't think it figures. So why does Microsoft claim everywhere Sender-Id is their effort? Callid-Id is at best, nothing more. > Microsoft has clearly decided it is not going to get taken by another > Eolas type patent. Short of the USPTO burning down a second time > and all records being lost (if only!) the only way to get any > protection against a patent suit is to file for a patent yourself > and hope you got yours in first. Correct me if I am wrong ... 1) Prior art nullifies a patent (I think this is even the case in the USA) 2) This mailing list is publicly archived a few places and mailboxes throughout the Internet. Newspapers have writen articles up and down about how Caller-Id/Sender-Id works. So the principle is well documented. 3) No one can claim IPR unless s/he can prove s/he invented it first which will be kinda hard because of 2) 4) Now: a) Nobody owns the patent -> nothing to worry, no one can claim it from now on (or better even since about 1.5 years ago) b) Microsoft owns the patent -> we all have to worry c) someone claims prior art -> MS will loose the patent -> s/he can register the patent So for me there is no difference whether MS has the patent besides the fact that if MS has the patent we're all at their will. The difference for MS is only they can control the Sender-Id technique with the patent. I really don't understand why the license has to have any restrictions? Why do they put in this sublicensing thingy? Why don't they simply say: - we hold the patent - we grant everyone and every company a 20/50/100 years irrevocable license to make use of the IPR covered by this patent free of charge. They could even transfer the patent to the IETF/ISOC and make a contract they will never have to pay any license fees nor can someone revoke the license for them to use the IPR covered. They do neither and because of that I neither trust nor do I believe them. This is nothing special about Microsoft, it is generic to companies that size and that historic behaviour (and to a lot of others, too). \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 Sat Aug 28 01:13: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 BAA07946 for ; Sat, 28 Aug 2004 01:13: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 i7S4sIfs092593; Fri, 27 Aug 2004 21:54: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 i7S4sICn092592; Fri, 27 Aug 2004 21:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S4sHcD092586 for ; Fri, 27 Aug 2004 21:54:17 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [192.168.253.21] (unknown[66.240.194.10]) by comcast.net (sccrmhc12) with ESMTP id <2004082804541501200obnjte> (Authid: dhlii); Sat, 28 Aug 2004 04:54:16 +0000 Message-ID: <4130101F.8020605@comcast.net> Date: Fri, 27 Aug 2004 21:54:55 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: on the topic of IPR References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> In-Reply-To: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > It is one of the jobs of co-chairs to facilitate discussion of working > group topics. Not that the issue of IPR is being debated lightly, > however we would like to raise a few discussion points that may have > been overlooked or given light treatment. I am new to participation in this group, though like many I have a vested interest in a successful standard. But what is it that Microsoft claims to actually own ? Working with Microsoft is better than working against them, though I confess a strong distaste for intellectual property rights in general - You can not own ideas. Despite my personal views IP is a reality that must be dealt with. However, atleast in the U.S. a patent is supposed to be non-obvious, unique, not previously published, and represent more than just a compilation of peices. What I understand of Sender-ID, Caller-ID, and SPF, does not seem to contain anything patentable. Most of the core principles have been considered numerous times over the years. SPAM and Phishing were not the problems they are today and the costs were generally not deemed acceptable, but validating the sender of a message, and as I see it that is really the core of all of this is just not a new idea. Storing verification information in DNS TXT records, whether in XML or any other format or any of the other bells and whistles that may be important parts of a working implimentation and work deserving recognition just does not seem patentable to me. Regardless, what is it that Microsoft actually owns that is being argued about ? From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 01:14: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 BAA07964 for ; Sat, 28 Aug 2004 01:14: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 i7S4oRui092382; Fri, 27 Aug 2004 21: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 i7S4oRgp092381; Fri, 27 Aug 2004 21:50:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S4oPI0092373 for ; Fri, 27 Aug 2004 21:50:26 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7S4oN11031316 for ; Sat, 28 Aug 2004 05:50:23 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7S4oNxo031315; Sat, 28 Aug 2004 05:50:23 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: SPF/Sender ID support in Courier. References: <16687.55940.84075.510780@giles.gnomon.org.uk> From: Graham Murray Date: Sat, 28 Aug 2004 05:50:22 +0100 In-Reply-To: <16687.55940.84075.510780@giles.gnomon.org.uk> (Roy Badami's message of "Sat, 28 Aug 2004 02:06:12 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Roy Badami writes: > The licenses may well be technically incompatible, but that effects > no-one but Microsoft. You, as the distributor of courier, will only > be distributing code under the GPL. You will _not_ be granting rights > under the Sender ID patent grant, and more to the point you will not > (I assume) be making any patent claims on Sender ID. That is *not* correct. Two of the rights which the GPL licence gives to recipients (ie those to whom the software is distributed) are to 1) Be allowed to modify (or have modified) the software. 2) Be allowed to distribute the software, either the original as received, or as modified in 1) above. The patent grant (as currently on the table) is incompatibe with this, as you (the software author and patent licencee) do not have the rights under the patent licence to grant recipients the right to modify and distribute that modified software - to do so they would need to obtain a licence from the patent holder. The GPL is clear that if you cannot grant these rights (eg because it is not yours to give) to recipients then you cannot distribute the software under GPL. From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 01:29:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08715 for ; Sat, 28 Aug 2004 01:29: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 i7S55HPI093759; Fri, 27 Aug 2004 22:05: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 i7S55Hh8093758; Fri, 27 Aug 2004 22:05:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S55Gd4093746 for ; Fri, 27 Aug 2004 22:05:16 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [192.168.253.21] (unknown[66.240.194.10]) by comcast.net (rwcrmhc13) with ESMTP id <2004082805051801500on7hge> (Authid: dhlii); Sat, 28 Aug 2004 05:05:18 +0000 Message-ID: <413012BA.3070900@comcast.net> Date: Fri, 27 Aug 2004 22:06:02 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: IETF MARID WG Subject: Re: on the topic of IPR References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> <412F228E.4070007@hepcoe.com> In-Reply-To: <412F228E.4070007@hepcoe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Kevin Peuhkurinen wrote: > Perhaps, but you are going to have a lot of trouble convincing people > that this is the best possible license that Microsoft could offer. > It may be acceptable for large companies that are technology > consumers, but it will remain unacceptable for many developers and > smaller end users. It is too ambiguous, too obviously anti-open > source and requires you to waive certain important legal rights in the > event of a dispute. > > Your suggestion that we ought to just acquiese to MSFT because they > might have us by the short and curlys is simply not credible. If > MARID chooses ClassicSPF and Microsoft is granted patents that appear > to cover this technology, we have plenty of prior art to invalidate > such patents. If there is a strong case for prior art - then why is there any issue at all ? Microsoft can either produce an acceptable license, and be part of the process, or not and decide whether they beleive the results of MARID infringe on their IP. Microsoft's participation is to be highly desired, but if the resulting standard includes any License from Microsoft, then the standard itself becomes evidence of the validity of the patent on the licensed IP. If there is a strong beleif that the IP is not patentable either through prior art or otherwise then MARID should not be taking a position validating it. From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 01:58: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 BAA10268 for ; Sat, 28 Aug 2004 01:58: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 i7S5e5MS099936; Fri, 27 Aug 2004 22:40: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 i7S5e5gm099935; Fri, 27 Aug 2004 22:40:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S5e5Y1099905 for ; Fri, 27 Aug 2004 22:40:05 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [206.223.20.210] (24.152.199.18.res-cmts.eph.ptd.net[24.152.199.18]) by comcast.net (rwcrmhc12) with ESMTP id <20040828054004014006v90be> (Authid: dhlii); Sat, 28 Aug 2004 05:40:05 +0000 Message-ID: <41301AE1.4060304@comcast.net> Date: Fri, 27 Aug 2004 22:40:49 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: IETF MARID WG Subject: Re: on the topic of IPR References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: >Microsoft has clearly decided it is not going to get taken by another >Eolas type patent. Short of the USPTO burning down a second time >and all records being lost (if only!) > Please do not wish for something like that. It would be horrible. The best protection we have against the patent system is the system itself. It is already admittedly failing to be able to properly review the increasing volume of incoming patents. It is the bulk of existing patents - both recent and expired, that provide the greatest protection against the barage coming in. It is the massive volume coming in that will choke the system - and in the worst case scenario atleast twenty years from now all patents currently in effect will have expired But every expired patent becomes an obstacle to granting a new one anywhere close. While I beleive that all patents - but particularly software patents are just plain a bad idea. it is unlikely that theoretical arguments about the failure of the patent system to actually serve the purpose it was intended for will ever matter. But the practical failure of the system to work becoming mired in its own exponential growth as well as the technical problems of trying to distinguish the ever diminishing gnats difference between an existing or expired patent and a new one will eventually kill it. From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 02:22: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 CAA25530 for ; Sat, 28 Aug 2004 02:22: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 i7S62EFW003548; Fri, 27 Aug 2004 23:02: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 i7S62EO2003547; Fri, 27 Aug 2004 23:02:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S62Ee9003517 for ; Fri, 27 Aug 2004 23:02:14 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [206.223.20.210] (24.152.199.18.res-cmts.eph.ptd.net[24.152.199.18]) by comcast.net (rwcrmhc11) with ESMTP id <2004082806021001300goohpe> (Authid: dhlii); Sat, 28 Aug 2004 06:02:16 +0000 Message-ID: <41302012.9010104@comcast.net> Date: Fri, 27 Aug 2004 23:02:58 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Sender ID license is acceptable References: <16687.55196.229533.14444@giles.gnomon.org.uk> <1093658280.7023.118.camel@va.local.linuxlobbyist.org> In-Reply-To: <1093658280.7023.118.camel@va.local.linuxlobbyist.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Iadonisi wrote: > And what weight does that carry? As I've said before, we have a KNOWN >patent here. Or at least *somewhat* known, since Microsoft hasn't been >clear exactly what it has a patent (or patent-pending) on. > > If Microsoft is unwilling to make clear what patent they hold that needs licensed then what is this all about ? Can I claim to hold a patent or patent pending on some unspecified aspect of any draft standard and insist on requiring my own License no matter how benign get included as part of the standard ? Certainly Microsft speaks with more credibility there than I do, but still does it make sense to allow any interest to hold the standards process hostage without atleast making it clear what it is they beleive they own ? Microsoft has been able to provide a very concrete license, but what exactly is it a license for ? I have not had much participation in standards processes before. But I understand that some less broadly deployed standards might have included similar or even more restrictive licenses. But have other standards included licensed technology without atleast identifying what was licensed before ? Without identifying the IP that requires a license I do not see how this situation is fundimentally different from the possibility that a standard could discover after appoval that there is an unforseen IP infringement. Certainly to be avoided if possible, but do we just quit drafting standards because they might infringe on something ? Shouldn't discussion of whether Microsoft's license is acceptable or not come after we know that they actually hold IP rights that do cover some part of the standard ? From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 02:41: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 CAA26422 for ; Sat, 28 Aug 2004 02:41:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S6Ot2S006782; Fri, 27 Aug 2004 23: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 i7S6Otqh006781; Fri, 27 Aug 2004 23:24:55 -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 i7S6OsI1006775 for ; Fri, 27 Aug 2004 23:24:54 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i7S6OsBt007930 for ; Fri, 27 Aug 2004 23:24:54 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF-MXCOMP From: "Anne P. Mitchell, Esq." Subject: Re: Reputation services for SenderID Date: Fri, 27 Aug 2004 23:24:52 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >with the number of IP addresses authorized by the SPF2 record, and >even for domains which only authorize a very few IP addresses, we'll >have no practical way (except manual processing of requests) to >correct outdated blacklist listings. A lookup to IADB, which is an accreditation database rather than a blacklist or a whitelist, can (and will for listed IP addresses) give you enough information to determine whether the blacklist listing should be decreased in weight or even overridden. That information includes, among other things, the opt-in level of the mailing list mail which comes from that IP address, and whether that IP address is listed in Bonded Sender or Habeas. If an IADB-listed IP address returns a code indicating that all mailing list mail coming from that IP address is, for example, confirmed-opt-in, that's useful information in the face of the IP address also appearing on a blacklist. SPF publishers who are also listed in IADB include the "accredit=%{ir}.iadb.isipp.com" in their SPF records; I assume it would be the similar for SPF2. The information returned from an IADB query includes whether an SPF record is published for that IP, so there is a closed loop there - if you check SPF first, you'll know that the IP is listed in IADB and you can get more info there - if you check IADB first, you'll know that there is an SPF record for that IP address. Some receivers prefer to do their lookups to IADB2 rather than IADB - IADB2 provides an aggregated weighted score rather than, but based on, the individual bits of information. (http://www.isipp.com/iadb.php) Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy Professor of Law, Lincoln Law School of SJ Committee Member, Asilomar Microcomputer Workshop From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 02:47: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 CAA26628 for ; Sat, 28 Aug 2004 02:47: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 i7S6N8ni006570; Fri, 27 Aug 2004 23:23:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S6N8J9006569; Fri, 27 Aug 2004 23:23:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S6N8FZ006550 for ; Fri, 27 Aug 2004 23:23:08 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [206.223.20.210] (24.152.199.18.res-cmts.eph.ptd.net[24.152.199.18]) by comcast.net (rwcrmhc11) with ESMTP id <2004082806230201300gopf8e> (Authid: dhlii); Sat, 28 Aug 2004 06:23:02 +0000 Message-ID: <413024E4.7010508@comcast.net> Date: Fri, 27 Aug 2004 23:23:32 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Iadonisi CC: ietf-mxcomp@imc.org Subject: Re: Problematic issues with regard to last call References: <200408271957.i7RJvlSe050319@m5p.com> <1093638545.7023.64.camel@va.local.linuxlobbyist.org> In-Reply-To: <1093638545.7023.64.camel@va.local.linuxlobbyist.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Iadonisi wrote: > Well, that's not how I took it. I think it's referring more to post >of the sort that say 'give me SPF-Classic/SRS or give me death'. > What is wrong with that kind of post ? Poor, illogical or emotional based argument is a problem. flames and abusive argument is a problem. But was is holding fast to a particular position so long as it is reasoned and supported a problem ? It would be a very good thing to get Microsoft on board for this standard. It is highly likely without their support this standard will die and the net result will be alot of SPF-Classic implimentations, and a few big caller-id implimentations - and maybe a few mixed implimentations. But the best result for everybody is a universally agreed on standard. However if the standard results in something that does not have the support of FOSS the end result will be atleast as bad. The GPL and most FOSS licenses are not only a license but the expression of a set of values concerning software. No one should be expected to compromise there values and principles to reach a consensus. We are supposed to compromise on issues that we do not consider to be core values - even though the compromises still may involve sacrifice. From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 02:58: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 CAA27265 for ; Sat, 28 Aug 2004 02:58: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 i7S6cbR6009086; Fri, 27 Aug 2004 23:38: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 i7S6cb4j009085; Fri, 27 Aug 2004 23:38:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S6cbhv009054 for ; Fri, 27 Aug 2004 23:38:37 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [206.223.20.210] (24.152.199.18.res-cmts.eph.ptd.net[24.152.199.18]) by comcast.net (rwcrmhc13) with ESMTP id <2004082806383101500o7rlte> (Authid: dhlii); Sat, 28 Aug 2004 06:38:32 +0000 Message-ID: <4130289C.1000707@comcast.net> Date: Fri, 27 Aug 2004 23:39:24 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: on the topic of IPR References: <412F76F6.5040406@solidmatrix.com> In-Reply-To: <412F76F6.5040406@solidmatrix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > Therefore, I don't understand why Microsoft is insisting on such > license. Considering that it may seriously hinder deployment as > several people have testified, it would make more sense that a license > without a requirement to sign an agreement is issued. If the patent > trolls will come, the license will not stop them anyway but the patent > might. This way Microsoft can have its cake and eat it to. > > Yakov > > I do not understand the requirement to sign the license either. Their failure to accept a license bound to the standard or required as part of the source of an implimentation suguests that they do nto beleive their own EULA under which all of there software is distributed are binding or enforceable. Regardless, a license include as part of the standard or required in the text of any source would likely provide very nearly as strong a legal defense against patent counter claims though it still might not be acceptable to FOSS it would atleast be much closer. From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 04:39: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 EAA02022 for ; Sat, 28 Aug 2004 04:39: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 i7S8I65A028008; Sat, 28 Aug 2004 01:18: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 i7S8I6m0028007; Sat, 28 Aug 2004 01:18:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (adsl-69-225-172-218.dsl.pltn13.pacbell.net [69.225.172.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S8I5pN027989 for ; Sat, 28 Aug 2004 01:18:05 -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 132EF1D651 for ; Sat, 28 Aug 2004 01:18:04 -0700 (PDT) Date: Sat, 28 Aug 2004 01:18:07 -0700 From: Greg Connor To: ietf-mxcomp@imc.org Subject: Re: on the topic of IPR Message-ID: <17535314.1093655887@[192.168.0.2]> In-Reply-To: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> References: <970CDC76-F816-11D8-9196-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 (I haven't had time to post in the last month or so, due to moving, an illness in the family, and my own anti-spam project at work. But I have been mostly keeping up with the discussion.) Regarding the MS IPR and license, I have many thoughts and feelings about it, some of them conflicting. In general, I believe the following: 1. I would rather have MS on board than not. While I don't like the "contribution" being encumbered, I also see some advantage to having MS as a partner. Despite the encumbrance, I still think the distribution and usage of Sender ID will be faster and wider than without MS as a key partner. In other words, we as a group have put up with their license, so I am hoping MS will return the favor and implement Sender ID early and often, publicize and market it, and use their big stick on a few others to get them to hum along too :) 2. If the license proves to be a problem, MS is free to release their stuff under a modified license later. If enough people complain about, say, not getting posted to a mirror site because the mirror site owners and operators are afraid they will be accused of "distributing" protected material, perhaps MS will modify their license. They already have modified it a bit. 3. If MS IPR proves to be not worth the pain caused, we (ietf, marid, or individuals) all have alternatives to choose from that are not that unsavory. In my mind, the advantage of including MS as a partner is not that their IPR is that much better... But, if this doesn't work out, very few components need to be switched out to remove their IPR from play. So, in general I support going forward with SenderID becoming an RFC. I'm going to rant a bit here, but don't let my rant below interfere with the high-level assessment, that we should go forward with Sender ID. MS employees had a choice. They could have chosen to participate in this working group much like the rest of us have -- by contributing their ideas without worrying about whether they were IPR. They could have come to the table with some good ideas that were NOT encumbered. They could have fought harder against their own legal team to just let it go, and not worry about who "owns" what. Instead MS employees chose to "contribute" something encumbered. (And I use the term "contribute" loosely here because it's clear that MS still "owns" it - the rest of us will just be living in it rent free for its useful life. To my mind a real "contribution" of ideas would be totally public domain with no license needed, and the patent claim would be withdrawn. MS employees also chose to not even disclose WHAT THE PENDING PATENT IS FOR. The fact that they kept the "what is or is not pending a patent" a guarded secret shows that their interests come first, and makes me think that they are not hanging out on this group for an altruistic purpose. Maybe their hands were tied, but still, they could have fought back against their own lawyers, and in doing so demonstrated to the group and the world that they are interested in contributing to the greater good and not working their own agendas through us. I have some respect for Jim and Harry, but I would have had a lot more if they had been able to come back to the group and say "Hey we hogtied the lawyers and whatever part of the document you want to use, go for it" So. In the future, if I participate in other working groups, my lesson learned from this one is that I WILL look a gift horse in the mouth. Encumbered IPR is NOT FREE. If it doesn't have a substantial benefit over the non-encumbered idea, the non-encumbered idea should always win. A group such as ours should not hand-wave and dismiss IPR concerns from the start by saying "A royalty-free license will be provided later". Encumbered ideas should be entertained, but not as welcome as ideas given free and clear. I would suggest to any future group considering protected property as part of a proposed standard, that they should 1. evaluate whether the licensed property is clearly better, and hence worth the hassle of licensing, and 2. evaluate the license itself early and often, and not just accept a promise that a license will be provided later. If it is really the *best* idea, it will win, and people will license it. If it is just as good as the free idea, TAKE the free idea over the licensed one :) All that said, I still think the end product is worth it. What was brought to the table was nowhere near as great as the collaborative, creative process we all participated in. The input drafts were good. The RFC we will come up with will be better than any of the inputs. And, I sincerely hope that MARID continues to do useful work and doesn't stop at the first RFC. There will be revisions, best practices statements, actual implementations to share and test, feedback to be shared on honing the process, etc. There are statistics to be gathered and shared, forwarders to be pestered and guided toward doing the right thing, whitelists to create, maintain, and use, and much more. Even if MARID no longer exists as an IETF group at some point in the future, we have still formed some very good relationships and I would love to keep communication lines open :) -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 08:14: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 IAA11691 for ; Sat, 28 Aug 2004 08:14: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 i7SBk4kr064050; Sat, 28 Aug 2004 04:46:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SBk4nM064049; Sat, 28 Aug 2004 04:46:04 -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 i7SBk3J4064043 for ; Sat, 28 Aug 2004 04:46:03 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i7SBk5YF028199 for ; Sat, 28 Aug 2004 04:46:05 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: "IETF-MXCOMP WG'" From: "Anne P. Mitchell, Esq." Subject: Re: on the topic of IPR Date: Sat, 28 Aug 2004 04:46:03 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > 3. If MS IPR proves to be not worth the pain caused, we (ietf, marid, > or individuals) all have alternatives to choose from that are not that > unsavory. In my mind, the advantage of including MS as a partner is > not that their IPR is that much better... But, if this doesn't work > out, very few components need to be switched out to remove their IPR > from play. > >... > > MS employees also chose to not even disclose WHAT THE PENDING PATENT > IS FOR. The fact that they kept the "what is or is not pending a > patent" a guarded secret shows that their interests come first, and > makes me think that they are not hanging out on this group for an > altruistic purpose. And herein lies one of the rubs - without knowing what the patent alleges to include, we can't possibly say with any certainty that if it doesn't work out, very few components need to be switched out to remove their IPR from play. It's entirely possible that the pending patent includes everything, and a few extras besides. Certainly if I were their lawyer, that's how I'd write it. As such, it's entirely possible that one could find that one couldn't use *any* related components. Sure, as some have mentioned, there is prior art, MS created Caller I.D., not Sender I.D., etc. etc.. Are *you* going to fund and mount that legal battle? From a legal viewpoint, it's always safest to assume that the claim includes nearly everything, if not everything. Especially when one can't even see it. Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy Professor of Law, Lincoln Law School of SJ Committee Member, Asilomar Microcomputer Workshop From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 08:14:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11715 for ; Sat, 28 Aug 2004 08:14:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SBonvR064625; Sat, 28 Aug 2004 04:50: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 i7SBonxL064624; Sat, 28 Aug 2004 04:50:49 -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 i7SBomUj064618 for ; Sat, 28 Aug 2004 04:50:48 -0700 (PDT) (envelope-from roy+dated+1096285843.c86974@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7SBsZgc050262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 28 Aug 2004 11:54:40 GMT (envelope-from roy+dated+1096285843.c86974@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7SBohEE003935 for ; Sat, 28 Aug 2004 12:50:43 +0100 (BST) (envelope-from roy+dated+1096285843.c86974@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7SBohpx003934 for ietf-mxcomp@imc.org; Sat, 28 Aug 2004 12:50:43 +0100 (BST) (envelope-from roy+dated+1096285843.c86974@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 28 Aug 2004 12:50:42 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16688.29073.783505.95937@giles.gnomon.org.uk> Date: Sat, 28 Aug 2004 12:50:41 +0100 To: Paul Iadonisi Cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Sender ID license is acceptable In-Reply-To: <1093658280.7023.118.camel@va.local.linuxlobbyist.org> References: <16687.55196.229533.14444@giles.gnomon.org.uk> <1093658280.7023.118.camel@va.local.linuxlobbyist.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 >>>>> "Paul" == Paul Iadonisi writes: Paul> Are the author of any open source software or Free Software? Paul> In particular, is any software you write and/or Paul> modify-distribute covered under the GPL? No I am not. My apologies to the chairs and to the WG if this post was out of place. Paul> I ask this because in the guidelines posted for discussing Paul> Last Call issues, we have been instructed to not speak for Paul> others, only ourselves. I think it is fairly clear that my opinions are my own, and that I am speaking for no-one but myself, but I apologise if the post was out of place. -roy From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 08:15: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 IAA11773 for ; Sat, 28 Aug 2004 08:15: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 i7SBiQw3063899; Sat, 28 Aug 2004 04:44: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 i7SBiQUK063898; Sat, 28 Aug 2004 04:44:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SBiQO4063892 for ; Sat, 28 Aug 2004 04:44:26 -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 D0BFC414EF; Sat, 28 Aug 2004 04:44:27 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 28 Aug 2004 04:44:27 -0700 (PDT) Message-ID: <1107.64.142.13.68.1093693467.squirrel@harry.mail-abuse.org> In-Reply-To: References: Date: Sat, 28 Aug 2004 04:44:27 -0700 (PDT) Subject: Re: Reputation services for SenderID From: "Douglas Otis" To: "Anne P. Mitchell, Esq." Cc: "IETF-MXCOMP" 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 "Anne P. Mitchell, Esq." wrote: >> with the number of IP addresses authorized by the SPF2 record, and >> even for domains which only authorize a very few IP addresses, we'll >> have no practical way (except manual processing of requests) to >> correct outdated blacklist listings. > > A lookup to IADB, which is an accreditation database rather than a > blacklist or a whitelist, can (and will for listed IP addresses) give > you enough information to determine whether the blacklist listing > should be decreased in weight or even overridden. That information > includes, among other things, the opt-in level of the mailing list mail > which comes from that IP address, and whether that IP address is listed > in Bonded Sender or Habeas. If an IADB-listed IP address returns a > code indicating that all mailing list mail coming from that IP address > is, for example, confirmed-opt-in, that's useful information in the > face of the IP address also appearing on a blacklist. > > SPF publishers who are also listed in IADB include the > "accredit=%{ir}.iadb.isipp.com" in their SPF records; I assume it would > be the similar for SPF2. The information returned from an IADB query > includes whether an SPF record is published for that IP, so there is a > closed loop there - if you check SPF first, you'll know that the IP is > listed in IADB and you can get more info there - if you check IADB > first, you'll know that there is an SPF record for that IP address. > > Some receivers prefer to do their lookups to IADB2 rather than IADB - > IADB2 provides an aggregated weighted score rather than, but based on, > the individual bits of information. This is a listing service that, for a setup up fee and so much per month, will accept lists of IP addresses. These types of IP based white-listing services existed well before SPF. The publisher must have dominion over the IP addresses effectively. Pay for mailing rights work for bulk mailers. The selection of listing services is also provided by a simple scheme within CSV, but where a domain name is used. The history associated with a name does not require a payment stream to a white-listing service. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 08:25:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12293 for ; Sat, 28 Aug 2004 08:25:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SBu4Et065165; Sat, 28 Aug 2004 04:56: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 i7SBu4kX065164; Sat, 28 Aug 2004 04:56:04 -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 i7SBu4vU065158 for ; Sat, 28 Aug 2004 04:56:04 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i7SBu6V2009161; Sat, 28 Aug 2004 04:56:06 -0700 In-Reply-To: <1107.64.142.13.68.1093693467.squirrel@harry.mail-abuse.org> References: <1107.64.142.13.68.1093693467.squirrel@harry.mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3CE8D100-F8E9-11D8-8AD0-000A95AC5778@isipp.com> Content-Transfer-Encoding: 7bit Cc: "IETF-MXCOMP" From: "Anne P. Mitchell, Esq." Subject: Re: Reputation services for SenderID Date: Sat, 28 Aug 2004 04:56:04 -0700 To: "Douglas Otis" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm not sure that this line of discussion below is on-topic, so if I'm wrong to follow up, please whack me: > This is a listing service that, for a setup up fee and so much per > month, > will accept lists of IP addresses. Not an accurate representation. It's an accreditation service which researches, verifies, and accredits IP addresses which are listed in the database. Senders do indeed pay a monthly fee for listing, which is how it is supported so that we can make it available for free for receivers to query. There is no set-up fee. There is an application fee if the senders are not otherwise known to us, and fairly well, through industry channels. That fee is used to do a background check, check references, etc., as part of the accreditation process. > These types of IP based white-listing > services existed well before SPF. IADB is not, emphatically not, a whitelist. The information contained in IADB about the IPs and the mail flowing therefrom is purely factual and objective, with no value judgement made at all, nor expectation about what querying sites will do with that information - use it to accept mail, use it to reject mail, use it to figure out lottery numbers - it's entirely up to the querying site. That's the whole purpose of IADB - to put as much _factual_ information into the hands of the querier as possible so that they can make informed, educated decisions and choices about how to process email coming from any given IP address (whereas whitelists and blacklists tell you whether you should accept or reject that email). Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy Professor of Law, Lincoln Law School of SJ Committee Member, Asilomar Microcomputer Workshop From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 08:42: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 IAA13108 for ; Sat, 28 Aug 2004 08:42: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 i7SCGEXI068018; Sat, 28 Aug 2004 05:16:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SCGEY0068017; Sat, 28 Aug 2004 05:16:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.ashtonwoodshomes.com (mail.ashtonwoodshomes.com [216.191.52.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SCGCC4068003 for ; Sat, 28 Aug 2004 05:16:13 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from mail.ashtonwoodshomes.com (localhost.localdomain [127.0.0.1]) by mail.ashtonwoodshomes.com (8.12.8/8.12.8) with ESMTP id i7SCCrj2011783; Sat, 28 Aug 2004 08:12:53 -0400 Received: from localhost (terry@localhost) by mail.ashtonwoodshomes.com (8.12.8/8.12.8/Submit) with ESMTP id i7SCCov0011779; Sat, 28 Aug 2004 08:12:52 -0400 X-Authentication-Warning: mail.ashtonwoodshomes.com: terry owned process doing -bs Date: Sat, 28 Aug 2004 08:12:50 -0400 (EDT) From: terry@ashtonwoodshomes.com To: Andrew Newton cc: George Mitchell , Subject: Re: Problematic issues with regard to last call In-Reply-To: <0F8849C2-F866-11D8-9196-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: Very well then, can you rephrase your statment to be more concise? Because George is not the only person who took it "out of context", because that is *exactly* how I saw your message: "Agree or get lost" Terry On Fri, 27 Aug 2004, Andrew Newton wrote: > > > On Aug 27, 2004, at 3:57 PM, George Mitchell wrote: > > > Well, golly, I think this might refer to me. It might refer to a > > number of people who object to the license agreement under discussion. > > Certainly if all of us leave, that will resolve the lack of consensus > > on the licensing issue. Is that what you are requesting? > > I can see how you would be upset given that you took my statement out > of context. > > -andy > -- Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 09:15: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 JAA14947 for ; Sat, 28 Aug 2004 09:15: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 i7SCmZjd073553; Sat, 28 Aug 2004 05:48: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 i7SCmZTt073552; Sat, 28 Aug 2004 05:48:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.ashtonwoodshomes.com (mail.ashtonwoodshomes.com [216.191.52.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SCmWH2073534 for ; Sat, 28 Aug 2004 05:48:34 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from mail.ashtonwoodshomes.com (localhost.localdomain [127.0.0.1]) by mail.ashtonwoodshomes.com (8.12.8/8.12.8) with ESMTP id i7SCjDj2013219; Sat, 28 Aug 2004 08:45:13 -0400 Received: from localhost (terry@localhost) by mail.ashtonwoodshomes.com (8.12.8/8.12.8/Submit) with ESMTP id i7SCj7lJ013211; Sat, 28 Aug 2004 08:45:08 -0400 X-Authentication-Warning: mail.ashtonwoodshomes.com: terry owned process doing -bs Date: Sat, 28 Aug 2004 08:45:07 -0400 (EDT) From: terry@ashtonwoodshomes.com To: Jim Lyon cc: Chris Haynes , IETF MARID WG Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FB000@df-fido-msg.exchange.corp.microsoft.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, 27 Aug 2004, Jim Lyon wrote: > > On Thursday, August 26, 2004 at 7:01 PM, Chris Haynes wrote about > whether the RFC's and ID's really do or do not give one the legal > authority to silently discard forged email. > > I offered a reading of the docs that supports the case for silent > discards. Chris offers a reading of the same docs that supports the > case against forged email. > > > Even though the standards are ambiguous, there is ample precedent for > the action. I can demonstrate (on the basis of only 2 ISPs) that more > than 10% of all email sent today is silently discarded. > (There are lots of criminals performing crimes, that doesn't make crime acceptable). The SMTP RFC's clearly state "reliable". The reason some ISP's are discarding is obvious, but irrelevant. This WG should be trying to get us to a better (compliant) place, not justify existing bad behaviour. > > Nevertheless, this has strayed a long way from MARID's charter. It > does, however, point to a need for more clarity in one's > responsibilities in this area. > Agreed > -- Jim Lyon > -- Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 09:30: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 JAA15393 for ; Sat, 28 Aug 2004 09:30:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SD3r1o077182; Sat, 28 Aug 2004 06:03: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 i7SD3rGh077181; Sat, 28 Aug 2004 06:03:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SD3q45077172 for ; Sat, 28 Aug 2004 06:03:52 -0700 (PDT) (envelope-from roy+dated+1096290227.5722e1@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7SD7eMH058299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 28 Aug 2004 13:07:46 GMT (envelope-from roy+dated+1096290227.5722e1@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7SD3lVm004413 for ; Sat, 28 Aug 2004 14:03:47 +0100 (BST) (envelope-from roy+dated+1096290227.5722e1@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7SD3lGv004412 for ietf-mxcomp@imc.org; Sat, 28 Aug 2004 14:03:47 +0100 (BST) (envelope-from roy+dated+1096290227.5722e1@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 28 Aug 2004 14:03:45 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16688.33456.768519.664243@giles.gnomon.org.uk> Date: Sat, 28 Aug 2004 14:03:44 +0100 To: Graham Murray Cc: ietf-mxcomp@imc.org Subject: Re: DEPLOY: SPF/Sender ID support in Courier. In-Reply-To: References: <16687.55940.84075.510780@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Graham" == Graham Murray writes: Graham> The GPL is clear that if you cannot grant these rights (eg Graham> because it is not yours to give) to recipients then you Graham> cannot distribute the software under GPL. Hmm, I concede that you may well be right. I still think Sender ID is useful though, and would hate to see this effort grind to a halt over squabbles over IPR, which is what seems to be happening. -roy From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 09:37:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15587 for ; Sat, 28 Aug 2004 09:37:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SDCiU9078594; Sat, 28 Aug 2004 06:12: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 i7SDCiN5078592; Sat, 28 Aug 2004 06:12:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SDCiFn078586 for ; Sat, 28 Aug 2004 06:12:44 -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 713CA414EF; Sat, 28 Aug 2004 06:12:46 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 28 Aug 2004 06:12:46 -0700 (PDT) Message-ID: <1134.64.142.13.68.1093698766.squirrel@harry.mail-abuse.org> In-Reply-To: <3CE8D100-F8E9-11D8-8AD0-000A95AC5778@isipp.com> References: <1107.64.142.13.68.1093693467.squirrel@harry.mail-abuse.org> <3CE8D100-F8E9-11D8-8AD0-000A95AC5778@isipp.com> Date: Sat, 28 Aug 2004 06:12:46 -0700 (PDT) Subject: Re: Reputation services for SenderID From: "Douglas Otis" To: "Anne P. Mitchell, Esq." Cc: "Douglas Otis" , "IETF-MXCOMP" 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'm not sure that this line of discussion below is on-topic, so if I'm > wrong to follow up, please whack me: > >> This is a listing service that, for a setup up fee and so much per >> month, will accept lists of IP addresses. > > Not an accurate representation. It's an accreditation service which > researches, verifies, and accredits IP addresses which are listed in > the database. Senders do indeed pay a monthly fee for listing, which > is how it is supported so that we can make it available for free for > receivers to query. There is no set-up fee. There is an application > fee if the senders are not otherwise known to us, and fairly well, > through industry channels. That fee is used to do a background check, > check references, etc., as part of the accreditation process. This was not said to diminish the value of your services. I was attempting to clarify money establishes a history. Tracking the history of an individual is a difficult task when working with IP addresses as an identity. This adds to the cost of these services. >> These types of IP based white-listing services existed well before SPF. > > IADB is not, emphatically not, a whitelist. The information contained > in IADB about the IPs and the mail flowing therefrom is purely factual > and objective, with no value judgement made at all, nor expectation > about what querying sites will do with that information - use it to > accept mail, use it to reject mail, use it to figure out lottery > numbers - it's entirely up to the querying site. Perhaps the relationship between paying and having a record with some information added is objective and that the white pays for the black. There must be trust in the address information, especially when there are negative assertions applied. This is where this model becomes weakest. Those causing trouble will not help in tracking their addresses. I did not intend to imply any negative assertions about this type of service. Again, the point I was attempting to make was the setup fees and payment stream provides credibility to addresses associated with a customer's claim. I would expect the setup fee pays for vetting this information. I was only attempting to highlight difference between only using IP addresses and the benefits of using domain names. The major benefit is from maintaining history without tracking IP addresses. What I am sure has been lost in this conversation, is that the Sender-ID Mailbox Domain is not adequately validated to be used as a basis for negative assertions. The authentication of CSV, although weak by most security standards, is significantly stronger at establishing an accountable domain identity. Both CSV and SPF allow the sender to recommend a service. ; ) -Doug From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 10:29:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19031 for ; Sat, 28 Aug 2004 10:29:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SE1GdD086911; Sat, 28 Aug 2004 07:01:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SE1GCq086910; Sat, 28 Aug 2004 07:01:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from icicle.pobox.com (icicle.pobox.com [207.8.226.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SE1FFt086888 for ; Sat, 28 Aug 2004 07:01:15 -0700 (PDT) (envelope-from SRS0=Tx/0=LS=dumbo.pobox.com=mengwong@bounce2.pobox.com) Received: from emerald.pobox.com (emerald.pobox.com [207.8.226.12]) by icicle.pobox.com (Postfix) with ESMTP id DD45411A9FE; Sat, 28 Aug 2004 10:01:15 -0400 (EDT) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 28CD7132D11; Sat, 28 Aug 2004 10:00:33 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id E26D75BC; Sat, 28 Aug 2004 10:01:14 -0400 (EDT) Date: Sat, 28 Aug 2004 10:01:14 -0400 From: Meng Weng Wong To: Roy Badami Cc: Graham Murray , ietf-mxcomp@imc.org Subject: Re: DEPLOY: SPF/Sender ID support in Courier. Message-ID: <20040828140114.GC3684@dumbo.pobox.com> References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16688.33456.768519.664243@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Aug 28, 2004 at 02:03:44PM +0100, Roy Badami wrote: | | Hmm, I concede that you may well be right. I still think Sender ID is | useful though, and would hate to see this effort grind to a halt over | squabbles over IPR, which is what seems to be happening. | The above seems to be a "for" vote. As recent discussions have focused on patent issues, a positive vote is worthy of note. Could I ask you and other people who like Sender ID on technical grounds to please explain what you like about it in more detail? Of course my other coauthors and I have our own opinions, but I would like to hear from other members in the working group. Please limit replies to "what I like about Sender ID" --- responses to those can come later. cheers From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 11:19: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 LAA21261 for ; Sat, 28 Aug 2004 11:19:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SEpcx5096954; Sat, 28 Aug 2004 07:51:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SEpcEw096953; Sat, 28 Aug 2004 07:51:38 -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 i7SEpcL7096947 for ; Sat, 28 Aug 2004 07:51:38 -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 14713414EE; Sat, 28 Aug 2004 07:51:41 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 28 Aug 2004 07:51:41 -0700 (PDT) Message-ID: <1168.64.142.13.68.1093704701.squirrel@harry.mail-abuse.org> In-Reply-To: References: <1093629989.5542.9.camel@ddev.mail-abuse.org> Date: Sat, 28 Aug 2004 07:51:41 -0700 (PDT) Subject: Re: TECH-ERROR: Misuse of DNS Records 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 "Mark Lentczner" wrote: > I think your message contains two distinct issues: > > On Aug 27, 2004, at 11:06 AM, Douglas Otis wrote: >> The Protocol draft mandates a minimum of 10 DNS text script macro >> evaluations. These scripts may reference any number of A, AAAA, MX, >> PTR, TXT, and SPF2 resource record types. ... > > This seems to be a concern that the type of processing limits in the > draft are unsuitable for keeping the amount of DNS traffic down to a > reasonable level. Several other people (Wayne in particular) have > suggested other types of processing limits for the draft that would > more precisely limit DNS queries. Do you have a particular proposal in > mind? I view this task as finding solutions that obtain the following goals: 1) A suitable identity for performing MTA reputation checks. 2) Allow the domain to constrain their mail to sets of MTA servers. 3) Allow the domain to list typical MTA servers, if not constrained. 4) Allow a means to recommend a listing service. 5) Minimize the impact upon the existing mail infrastructure. Contrary to a view this must be done by applying a Band-Aid, there should be a change in how this is structured. This change in structure will arrive at these goals. A side benefit in doing this is that the IPR problem is avoided as well. >> The Protocol draft also allows for “open-ended” definitions by >> appending notation such as “+all” or “?all” > > I think you are concerned here that the draft allows domains to publish > what you would argue are unsafe and detrimental records. Do you have a > specific proposal for changing the draft to address this issue? Sender-ID does not properly provide for goals 2 and 3. Sender-ID attempts to combine the MTA authorization with the Mailbox Domain authorization. This creates a problem. Mail is often relayed through a series of servers and is not always end-to-end. By combining these functions, this creates a problem of "validation promotion" where at one server, the message would be seen as outside the prescribed Mail Channel, but at the next, the message would be seen as inside the prescribed Mail Channel. Users will find that by offering an "open-ended" list to achieve the lesser goal 3, may also find these records being exploited to send spam using their identity, but now as fully validated. Expecting checks made at each MTA as a means to protect the integrity of the RFC2822 information is also a problem. Splitting the message authorization from the MTA authorization solves the problem with the number of DNS lookups. Authenticate the MTA and validate its authorization. The MTA authentication and authorization can be done without adding any additional DNS lookups. MTA authentication provides a domain that CAN safely be used for Goal 1. By having the Mailbox Domain reference a list of MTA domains, either as a restriction or to indicate a nominal, this is achieved using a non-sequential DNS lookup. This solves the problem of "open-ended" lists being exploited by spammers. This solves the problem of "validation promotion". This solves the problem of ISPs needing to include Resent-From headers. This allows the MTA to be authenticated without breaking the operation of list servers or forwarding. >> Solution: >> http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt > > If your concerns are truly TECH-ERROR concerns with the protocol draft, > please suggest specific ways to fix them. I have suggested very specific ways to fix them. > If your concern is that the draft is so broken that the working group > should abandon it and proceed with discussing your draft, then that is > much more than a TECH-ERROR issue. Perhaps it is a DEPLOY level issue, or > perhaps a meta-level issue to be brought up with the working group chairs. The draft has been transformed dramatically several times in its recent history. As I see it now, the current structure is unworkable. Changing the structure provides virtually all the same features far better but with MUCH less overhead and damage to the existing system. By making these changes, it would also dramatically reduce the cost of tracking spammers. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 12:01:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23959 for ; Sat, 28 Aug 2004 12:01:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SFWvmm008194; Sat, 28 Aug 2004 08:32: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 i7SFWvuo008193; Sat, 28 Aug 2004 08:32:57 -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 i7SFWvj2008187 for ; Sat, 28 Aug 2004 08:32:57 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7SFWnY15419; Sat, 28 Aug 2004 08:32:49 -0700 Date: Sat, 28 Aug 2004 08:32:47 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <868035598.20040828083247@brandenburg.com> To: "Anne P. Mitchell, Esq." CC: "Douglas Otis" , "IETF-MXCOMP" Subject: Re: Reputation services for SenderID In-Reply-To: <3CE8D100-F8E9-11D8-8AD0-000A95AC5778@isipp.com> References: <1107.64.142.13.68.1093693467.squirrel@harry.mail-abuse.org> <3CE8D100-F8E9-11D8-8AD0-000A95AC5778@isipp.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 Anne, APME> IADB is not, emphatically not, a whitelist. The information contained APME> in IADB about the IPs and the mail flowing therefrom is purely factual APME> and objective, with no value judgement made at all, nor expectation I thought I had understood what IADB was about, but now I am confused. The web page says: The ISIPP Accreditation Database (IADB) is a DNS list of the domains and/or IP addresses of senders who either a) meet ISIPP's criteria as determined by background, reference, and other checks ("non-vouched listings"), or b) are personally known to ISIPP to meet the criteria and to be good Internet mailing citizens, and for whom we will thus vouch ("vouched listings"). This very definitely defines a service that makes a value judgement. Please clarify. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 13:37: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 NAA00815 for ; Sat, 28 Aug 2004 13:37: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 i7SH5LW1022419; Sat, 28 Aug 2004 10: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 i7SH5LUP022418; Sat, 28 Aug 2004 10:05:21 -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 i7SH5KkL022412 for ; Sat, 28 Aug 2004 10:05:20 -0700 (PDT) (envelope-from sb0-0658f91e4b-johnl@iecc.com) Received: (qmail 12732 invoked by uid 100); 28 Aug 2004 17:05:23 -0000 Date: 28 Aug 2004 17:05:23 -0000 Message-ID: <20040828170523.12731.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Why sublicensing is important Organization: I.E.C.C., Trumansburg NY USA Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A recent article in eWeek makes it crystal clear that the crucial issue in the Microsoft patent license is sublicensing, and that the MS lawyers can't (or at least won't) change the terms. Sublicensing isn't an merely because MS is big company with lots of lawyers. The IBM Public License (see below) that they use for code that they release to open source projects is sublicensable. So why is it critical here? The reason you don't allow sublicenses of a free license is to preserve your ability to change the terms in the future. I'm not weaving conspiracy theories here, I'm just stating the obvious. So the question is whether we're willing to use a license that Microsoft has told us that they're considering changing. Without attributing any evil intent, I find that much too risky simply because I don't know what situation Microsoft will be in three or five years from now, and neither does anyone else. As someone who is constantly writting twiddles to mail software and exchanging them with other people (qmail patches, mostly) this presents a huge spanner that could be chucked into the works at any time. Since a lot of people have made it equally clear that they're willing to go ahead with Sender ID, the least bad option seems to me to be to move both Sender ID and SPF ahead as experimental standards. They're both experimental because we still have only the sketchiest experience with day to day usage of both, and we don't know about server loads, DNS loads, likely spammer counterattacks, or anything else operational. People who are so inclined can easily implement both, particularly if they use the same DNS records. Then MARID can turn its attention to other things like CSV which are also useful and less contentious, and let the IETF standards process work the way it's supposed to, leading with any luck to the rough consensus and running code that I think we all still want. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly. PS: eWeek article: http://www.eweek.com/print_article/0,1761,a=134028,00.asp IBM public license: http://www-124.ibm.com/developerworks/opensource/license10.html FYI, I happen to know the guy who write the article, and I think he can be counted on to get his facts right. Also, several people have suggested that one could circumvent the sublicensing clause by rounding up all of your friends and having them all get licenses that could later be used if the terms change, but no-transfer prevents that. (No doubt this same scenario occurred to people in Redmond.) Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 14:40:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03790 for ; Sat, 28 Aug 2004 14:40:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SI6BMa032936; Sat, 28 Aug 2004 11:06: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 i7SI6B2a032935; Sat, 28 Aug 2004 11:06:11 -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 i7SI6BwO032922 for ; Sat, 28 Aug 2004 11:06:11 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i7SI6Cvf023998; Sat, 28 Aug 2004 11:06:12 -0700 In-Reply-To: <868035598.20040828083247@brandenburg.com> References: <1107.64.142.13.68.1093693467.squirrel@harry.mail-abuse.org> <3CE8D100-F8E9-11D8-8AD0-000A95AC5778@isipp.com> <868035598.20040828083247@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "IETF-MXCOMP WG'" From: "Anne P. Mitchell, Esq." Subject: Re: Reputation services for SenderID Date: Sat, 28 Aug 2004 11:06:10 -0700 To: Dave Crocker X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 28, 2004, at 8:32 AM, Dave Crocker wrote: > The web page says: > > The ISIPP Accreditation Database (IADB) is a DNS list of the > domains and/or IP addresses of senders who either a) meet > ISIPP's > criteria as determined by background, reference, and other > checks > ("non-vouched listings"), or b) are personally known to ISIPP to > meet the criteria and to be good Internet mailing citizens, and > for whom we will thus vouch ("vouched listings"). > > This very definitely defines a service that makes a value judgement. > > Please clarify. Dave, Thank you for pointing that out, as I can see where it is confusing and we need to clarify that on our website. In order to be *allowed* to be listed in IADB you must pass the background check - *unless* we already know you through various activities - that can take the place of the background check. That's the only aspect of vouched/unvouched. It's a hurdle to entry. The data listed/contained in IADB itself is purely factual information, for example: Publishes SPF record Publishes Microsoft "Caller I.D. for Email" record Participates in Habeas program Participates in Ironport's Bonded Sender program Accepts unverified sign-ups such as through web page Accepts unverified sign-ups, gives chance to opt out Adds only customer and inquirer email addresses to mailing list without opt-in, gives chance to opt out ..and so on. The full list of codes is at: http://www.isipp.com/iadbcodes.php Does that help to clarify any? Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy Professor of Law, Lincoln Law School of SJ Committee Member, Asilomar Microcomputer Workshop From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 14:48: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 OAA04128 for ; Sat, 28 Aug 2004 14:48:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SILvO1035823; Sat, 28 Aug 2004 11:21: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 i7SILvFh035822; Sat, 28 Aug 2004 11:21:57 -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 i7SILu1q035815 for ; Sat, 28 Aug 2004 11:21:57 -0700 (PDT) (envelope-from roy+dated+1096309312.9e269a@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7SIPn6l090349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 28 Aug 2004 18:25:55 GMT (envelope-from roy+dated+1096309312.9e269a@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7SILqHQ005547 for ; Sat, 28 Aug 2004 19:21:52 +0100 (BST) (envelope-from roy+dated+1096309312.9e269a@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7SILqMn005546 for ietf-mxcomp@imc.org; Sat, 28 Aug 2004 19:21:52 +0100 (BST) (envelope-from roy+dated+1096309312.9e269a@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 28 Aug 2004 19:21:46 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16688.52538.55612.753445@giles.gnomon.org.uk> Date: Sat, 28 Aug 2004 19:21:46 +0100 To: Meng Weng Wong Cc: Roy Badami , Graham Murray , ietf-mxcomp@imc.org Subject: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) In-Reply-To: <20040828140114.GC3684@dumbo.pobox.com> References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.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 >>>>> "Meng" == Meng Weng Wong writes: Meng> The above seems to be a "for" vote. As recent discussions Meng> have focused on patent issues, a positive vote is worthy of Meng> note. It is. Unfortunately there appears to be no procedure within the last call for indicating approval of the drafts, other than by individually replying to specific objections that are made, and I'm afraid that given the volume of traffic during this last call, I'm simply unable to keep up with the comments. Meng> Could I ask you and other people who like Sender ID on Meng> technical grounds to please explain what you like about it Meng> in more detail? One of the main reasons is that it allows me to take steps to make it harder for people to spoof mail from domains that I control. For me personally, this is not a serious issue. In the context of the company I work for, however, we have concerns that spam and virus e-mail purporting to by from us is taken at face value by non-technical users. Phishing isn't an issue for us; customers and potential customers thinking that we are sending them spam and viruses is a moderate concern. In this context, Sender ID is far more useful to us than SPF, because SPF protects an identity that is not available to the MUA in any reliable way. I realize that Sender ID also protects an identity that isn't currently displayed by MUAs, but hopefully we will see that change fairly rapidly. [1] That said, we will almost certainly be publishing SPF records in addition to Sender ID records. And we will almost certainly publish Sender ID records, regardless of whether the spec has the aproval of the IETF or gets filibustered by endless arguments in this WG, as long as we see a benefit to us in doing so. (And Hotmail alone accounts for a large enough proportion of non-technical users that I suspect that even if no-one except Microsoft checks Sender ID, we would decide that it was in our interests to publish.) As the above implies, I'm not against checking MAIL FROM (and believe it is useful), and I would like to see this WG discuss MAIL FROM validation if/when it completes its current work items (Sender ID and CSV). Another reason is that like most people, particular people who have been using e-mail for a long time, we are deluged with spam. We use a heuristic spam checker, which works quite well, but there is a need to whitelist organizations in order to avoid false positives. The problem is that when you whitelist a major corporation, the chances of receiving spam or viruses claiming to be from is quite high. So I'd like to be able to whitelist based on a validated identity. For this purpose though it doesn't really matter what the identity is. If they publish Sender ID records, I'll whitelist them based on the PRA; if they publish SPF records, I'll whitelist them based on the MAIL FROM. If they publish CSV records, I could whitelist them based on HELO strings (though this last requires them to tell me all the HELO strings of their outbound MTAs, so is less convenient). I support Sender ID also for the flexibility of the SPF record. Many people have criticised it for being over-flexible (and hence over complex, and overly resource intensive) but I feel that this flexibility is key. Having a policy language that is expressive enough to allow people to describe their existing policies will result in far more buy in than requiring people to change their policies to fit in with MARID. It is certainly possible that we may need to make per-user exceptions in the records we publish, at least in the early days of deployment, to allow for a small number of people who work from home who don't currently use our MTAs to originate e-mail. I am of course aware of the utility of a validated identify in constructing reputation systems, and the potential utility of reputation systems in attacking the spam problem. Sender ID is likely to be useful in this regard, too. This is an area though where I'm less sure of relative utility of the different identities, and I can see that CSV may be of particular use here too. However in summary, of all the proposals I'm aware of, Sender ID seems to me to be of the most immediate utility to me. This is partly due to its specific functionality, and partly due to the specs now being in a fairly mature state, which could be deployed tomorrow without too much difficulty. (Without a doubt, SPF is the most mature of the specifications out there, but for the technical reasons I describe above, I expect Sender ID to provide me with greater benefits). Even if Sender ID is incompatible with the GPL [2] -- and I'm skeptical that it is except under the most extreme interpretations -- Sender ID can be implemented now, and the license is not so burdonsome as to prevent significant deployment. If it can't be implemented within some MTAs, it can be implemented as a separate stand-alone package that interfaces to the MTA. Most modern MTAs have interfaces that would permit this. I have nothing against this WG seeking other solutions which are either better or complementary to Sender ID, including attempting to design an alternative solution that is unencumbered by patent claims. But that should be a future work item. Despite any technical and legal shortcomings of Sender ID, it's the best thing we have _now_, and I am in favour of progressing it to the IESG for consideration as a Proposed Standard. Sorry for the length of this -roy [1] If Microsoft fixes Hotmail, Outlook and Outlook Express to display the PRA, and Apple fixes their mail client to display the PRA, and both Microsoft and Apple roll out the fixes via their automatic updates mechanisms, then you've covered a very significant proportion of non-technical users. There's no reason why this has to take lots of time. [2] And on further reflection my opinion is that whilst Sender ID _might_ be incompatible with the GPL, to conclude this you have to take a fairly extreme view of what the GPL requires. In particular, under such a view, _no_ GPL'd software that has (or even might have) any patent claims against it may be redistributed. That essentially means prety much all non-trivial GPL'd software. For instance, the Linux kernel is GPL'd, and we _know_ that there are numerous patent claims that may apply to it. Distributing an MTA that incorporates Sender ID is at least as legal is distributing the Linux kernel. If that's not good enough, then maybe it's time to throw away the GPL. From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 15:05: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 PAA05241 for ; Sat, 28 Aug 2004 15:05: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 i7SIZ3aL037732; Sat, 28 Aug 2004 11:35:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SIZ3SR037731; Sat, 28 Aug 2004 11:35: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 i7SIZ3xd037724 for ; Sat, 28 Aug 2004 11:35: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 i7SIZ6Y03543; Sat, 28 Aug 2004 11:35:06 -0700 Date: Sat, 28 Aug 2004 11:35:03 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1367937938.20040828113503@brandenburg.com> To: "Anne P. Mitchell, Esq." CC: "IETF-MXCOMP WG'" Subject: Re: Reputation services for SenderID In-Reply-To: References: <1107.64.142.13.68.1093693467.squirrel@harry.mail-abuse.org> <3CE8D100-F8E9-11D8-8AD0-000A95AC5778@isipp.com> <868035598.20040828083247@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 Anne, APME> In order to be *allowed* to be listed in IADB you must pass the APME> background check ... APME> The data listed/contained in IADB itself is purely factual information, APME> for example: There is an added bit of information, to the strictly 'factual' set of data you provide in the entry. That bit of information is that they passed your background check. Your basis for choosing a particular set of criteria is not 'factual'. It is determined by you opinion of what the requirements should be set for listing. This is not a bad thing at all, but it also is not objective. In fact, it is the REAL value of such a listing, namely that the entity being referred to was able to pass your test. It is at the core of the value proposition for serious accreditation/reputation services, namely someone's independent assessment of the entity being considered. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 15:06:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05348 for ; Sat, 28 Aug 2004 15:06:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SIaVGl037899; Sat, 28 Aug 2004 11:36: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 i7SIaVA6037898; Sat, 28 Aug 2004 11:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SIaV7l037892 for ; Sat, 28 Aug 2004 11:36:31 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7SIaWRo001756; Sat, 28 Aug 2004 11:36:32 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 28 Aug 2004 11:36:32 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'John Levine'" , ietf-mxcomp@imc.org Subject: RE: Why sublicensing is important Date: Sat, 28 Aug 2004 11:36:30 -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: > Sublicensing isn't an merely because MS is big company with lots of > lawyers. The IBM Public License (see below) that they use for code > that they release to open source projects is sublicensable. It is critical that a code license be sublicensable because otherwise there is no way to modify the code and to pass the modified code on together with the original. The need to sublicense is a direct consequence of the need to merge two work products. This is not a code license, it is a patent license. Confusing the two is mistaken. With a patent license there is no way for a third party to extend the patent scope. If a fresh patent issues then the result is a separate patent with separate patent licensing terms. The work products are distinct. > So why is > it critical here? The reason you don't allow sublicenses of a free > license is to preserve your ability to change the terms in the future. > I'm not weaving conspiracy theories here, I'm just stating the > obvious. This has no effect on the ability to change the terms. The reason that sublicensing is prohibited is that this could be used to avoid the granting of reciprocal rights. > So the question is whether we're willing to use a license that > Microsoft has told us that they're considering changing. Where do you find that statement? I don't see it. > Without > attributing any evil intent, I find that much too risky simply because > I don't know what situation Microsoft will be in three or five years > from now, and neither does anyone else. Once the license is granted it is granted. > As someone who is constantly > writting twiddles to mail software and exchanging them with other > people (qmail patches, mostly) this presents a huge spanner that could > be chucked into the works at any time. Given that the courts have in the past revoked patents after the holders failed to disclose them under 'note well' type rubric it hardly seems likely that Microsoft can tell the working group that it has IPR, that it is available on license terms X and then subsequently change the terms to anything that is less favorable (in the Pareto sense) than X. The same issue is at work here, detrimental reliance. From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 15: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 PAA08031 for ; Sat, 28 Aug 2004 15: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 i7SJBfoY050203; Sat, 28 Aug 2004 12:11:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJBf9t050201; Sat, 28 Aug 2004 12:11:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJBe2b050125 for ; Sat, 28 Aug 2004 12:11:40 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7SJAVth013292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Aug 2004 15:10:32 -0400 Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: <16688.52538.55612.753445@giles.gnomon.org.uk> References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> Content-Type: text/plain Message-Id: <1093720180.7023.148.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 28 Aug 2004 15:09:40 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2004-08-28 at 14:21, Roy Badami wrote: [snip] > In this context, Sender ID is far more useful to us than SPF, because > SPF protects an identity that is not available to the MUA in any > reliable way. I realize that Sender ID also protects an identity that > isn't currently displayed by MUAs, but hopefully we will see that > change fairly rapidly. [1] This makes no sense. MAIL FROM is most certainly at least as available to the MUA as Sender-ID via the Return-Path: header. Neither is displayed by most MUAs, but if I'm not mistaken, Sender-ID identity is heuristically determined. Return-Path: is one value, so it is presumably much simpler to determine. Anyhow, that may not be significant. It's the only technical disagreement I have with you that I can discern from your post here. > That said, we will almost certainly be publishing SPF records in > addition to Sender ID records. And we will almost certainly publish > Sender ID records, regardless of whether the spec has the aproval of > the IETF or gets filibustered by endless arguments in this WG, as long > as we see a benefit to us in doing so. I object to this being referred to as filibustering. If it were, I would have expected the co-chairs to put a stop to it by now. With very few exceptions (mostly from those in favor of moving forward with the current Sender-ID patent license), the discussion has been very civil and well reasoned. [snip] > > Even if Sender ID is incompatible with the GPL [2] -- and I'm > skeptical that it is except under the most extreme interpretations -- And we have yet to see a convincing legal argument (or *any* legal argument) from an attorney posted to this list. I'd like to know what Anne Mitchell (on this list) thinks of her legal analysis being called extreme by a non-lawyer. > Sender ID can be implemented now, and the license is not so burdonsome > as to prevent significant deployment. If it can't be implemented > within some MTAs, it can be implemented as a separate stand-alone > package that interfaces to the MTA. Most modern MTAs have interfaces > that would permit this. This is not as simple as you make it out to be. You are once again leaving out compilations such as Red Hat's Fedora and Debian. I'm sure I could list many others. Having a separate module makes no difference if it's included in the cdrom ISOs that are distributed. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 15:46:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08395 for ; Sat, 28 Aug 2004 15:46:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJJCTH055137; Sat, 28 Aug 2004 12:19: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 i7SJJC8W055136; Sat, 28 Aug 2004 12:19:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts25-srv.bellnexxia.net (tomts25.bellnexxia.net [209.226.175.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJJB1R055109 for ; Sat, 28 Aug 2004 12:19:12 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040828191912.ISFU7925.tomts25-srv.bellnexxia.net@ibmrkydk2ufvdd>; Sat, 28 Aug 2004 15:19:12 -0400 From: "John Glube" To: "'John Levine'" , Subject: RE: Why sublicensing is important Date: Sat, 28 Aug 2004 15:20:15 -0400 Message-ID: <017001c48d34$0c884710$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20040828170523.12731.qmail@xuxa.iecc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SJJC1R055130 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit John, Thank you for putting forward your suggestions. After Anne Mitchell made her initial post concerning the Microsoft license, I sat down and re-analyzed the patent license and reviewed the status of Sender-ID for my personal benefit. The conclusions I reached were: * Reject Sender-ID because of the patent license, given certain technical drafting issues and a lack of knowledge about the formal patent application. I realized that I had missed certain issues in my first go through of the draft license and FAQ. * Allow Sender-ID to proceed, but on a conditional basis, subject to field testing and resolution of the issues surrounding the patent license and the exact nature of the claimed intellectual property. I also felt I did not have enough knowledge about how Sender-ID would actually work in the wild to support full approval at this juncture. (The issues surrounding the implementation of the text record by large corporations as reported to this list, along with subsequent comments made about the design, simply highlighted the difficultly for me.) Upon balance my inclination was to go with the second option of conditional approval. In making these comments, I want to be clear that I still consider Microsoft has done a good job in the FAQ and draft patent license. I attribute no bad intent to Microsoft. The negotiating team which presented the FAQ and draft patent license to this WG was carrying out their task, to fully protect the organization's interests while being fair. However, after going through the material for a second time, after Anne rang the alarm bell, for which I am most grateful, as her stance took courage, I personally concluded the draft patent license did not go far enough. As to SPF, because it was not formally before the IETF, I came to no conclusion other than to note, even though a lot of work has been done with SPF, from inquiries I made large scale testing was required before one could consider SPF as a full standard. (I realize some folks will probably consider the last statement the equivalent of heresy, but...) As to CSV, I will simply state having read through all of the online discussions along with the drafts, I concur with your analysis and suggestion. For these reasons, I support your suggestion that both Sender-ID and SPF be granted approval as experimental standards. I agree that any approval of Sender-ID as a full standard, in addition to being conditional upon testing and the like, also be subject to satisfactory resolution of the issues surrounding the intellectual property rights and patent license. I repeat, from my perspective my stance is not meant as a criticism of the Microsoft negotiating team. Because of its size, Microsoft is easy to attack. Microsoft is simply a large group of individuals working together to achieve common goals. The individuals involved do take great pride in achieving their common objectives and rightfully so. Balancing the competing interests is not an easy task. This is why I fully support the concept of conditional approval for Sender ID as an experimental protocol. This will give the parties involved the time needed to sort through the thorny issues surrounding the draft patent license, while allowing for large scale testing of Sender ID. In turn this will ensure, on full roll out, any rough edges have been worked through so resulting in a better result for all concerned. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 16:12: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 QAA10241 for ; Sat, 28 Aug 2004 16:12: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 i7SJZvIn065325; Sat, 28 Aug 2004 12:35: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 i7SJZvEe065324; Sat, 28 Aug 2004 12:35:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJZuKr065193 for ; Sat, 28 Aug 2004 12:35:57 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7SJZodU006794 for ; Sat, 28 Aug 2004 20:35:50 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7SJZoJG006793; Sat, 28 Aug 2004 20:35:50 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: In favour of Sender ID References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> From: Graham Murray Date: Sat, 28 Aug 2004 20:35:50 +0100 In-Reply-To: <16688.52538.55612.753445@giles.gnomon.org.uk> (Roy Badami's message of "Sat, 28 Aug 2004 19:21:46 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Roy Badami writes: > I support Sender ID also for the flexibility of the SPF record. Many > people have criticised it for being over-flexible (and hence over > complex, and overly resource intensive) but I feel that this > flexibility is key. Having a policy language that is expressive > enough to allow people to describe their existing policies will result > in far more buy in than requiring people to change their policies to > fit in with MARID. I agree that people should not be required to change their policies and working practices purely to fit in with MARID. However, I think that the fight against phishing and identify forging could be greatly helped if, as well as technical measures such as MARID, some organisations (especially some of those most liable to have their identity spoofed by phishers) were to make some changes to their policies and working practices. In particular using third parties (eg PR companies or advertising agencies) to send e-mail to customers (and potential customers) makes it very much harder (before MARID or equivalent authentication is introduced) to distinguish between genuine emails and phishing attempts. Changing to only sending emails from MTAs using MAIL FROM, EHLO and rDNS within their own domain would not only help (those who know how to read headers) distinguish genuine emails from phishing before MARID is introduced but could greatly simplify the MARID DNS ecords which have to be published and checked. From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 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 QAA10891 for ; Sat, 28 Aug 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 i7SJp58p074804; Sat, 28 Aug 2004 12:51:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJp5wA074803; Sat, 28 Aug 2004 12:51:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.simkin.ca (IDENT:ayWwwn8b4p2YwExHCQBzmuLTwaWKDjqM@skynet.simkin.ca [199.175.137.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJp4rw074754 for ; Sat, 28 Aug 2004 12:51:05 -0700 (PDT) (envelope-from ahodgson@simkin.ca) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.simkin.ca (Postfix) with ESMTP id 40885FAB6 for ; Sat, 28 Aug 2004 12:51:05 -0700 (PDT) Received: from mail.simkin.ca ([127.0.0.1]) by localhost (skynet.simkin.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30125-08 for ; Sat, 28 Aug 2004 12:50:08 -0700 (PDT) Received: by mail.simkin.ca (Postfix, from userid 509) id F279AFAF5; Sat, 28 Aug 2004 12:50:07 -0700 (PDT) Date: Sat, 28 Aug 2004 12:50:07 -0700 From: Alan Hodgson To: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Sender ID license is acceptable Message-ID: <20040828195007.GA2990@simkin.ca> Reply-To: Alan Hodgson References: <16687.55196.229533.14444@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16687.55196.229533.14444@giles.gnomon.org.uk> User-Agent: Mutt/1.4.1i X-SPF-Protected: True (see http://spf.pobox.com/) Organization: Simkin Network Consulting Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Aug 28, 2004 at 01:53:48AM +0100, Roy Badami wrote: > > > In summary, I believe that the Sender ID license, whilst somewhat > burdonsome to distributors of code, poses no major difficulties with > the GPL or other major open source licenses, Based on what? The lawyers who have examined the issue seem to believe differently. All users of FOSS software are, potentially, distributors. -- "It's not a war on drugs, it's a war on personal freedom. Keep that in mind at all times." From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 16:36: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 QAA11497 for ; Sat, 28 Aug 2004 16:36: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 i7SKElgg088186; Sat, 28 Aug 2004 13:14: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 i7SKElab088185; Sat, 28 Aug 2004 13:14:47 -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 i7SKElu9088163 for ; Sat, 28 Aug 2004 13:14:47 -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 B6D3940EB for ; Sat, 28 Aug 2004 13:14:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1093720180.7023.148.camel@va.local.linuxlobbyist.org> References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> <1093720180.7023.148.camel@va.local.linuxlobbyist.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) Date: Sat, 28 Aug 2004 13:14:42 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 28, 2004, at 12:09 PM, Paul Iadonisi wrote: > This makes no sense. MAIL FROM is most certainly at least as > available to the MUA as Sender-ID via the Return-Path: header. Neither > is displayed by most MUAs, but if I'm not mistaken, Sender-ID identity > is heuristically determined. Return-Path: is one value, so it is > presumably much simpler to determine. Your main points are true: In general, the Return-Path and the PRA value are both in the headers and available to MUAs to display. And yes, Return-Path requires less processing than the PRA. (Though given that the headers are read and parsed anyway, PRA isn't that hard.) However, you are mistaken: There is nothing heuristic in the PRA identity. It follows directly from the RFC 2822 definition of the headers. The meanings of From:, Sender:, Resent-From:, and Resent-Sender: is in there, as is their relative precedence and the ordering issue with Resent-Sender: and multiple Resent-* blocks. > Anyhow, that may not be significant. It's the only technical > disagreement I have with you that I can discern from your post here. Ditto here. - Mark From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 17: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 RAA14837 for ; Sat, 28 Aug 2004 17:50: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 i7SLLBmb009777; Sat, 28 Aug 2004 14:21: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 i7SLLBIm009776; Sat, 28 Aug 2004 14:21:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SLLAgd009741 for ; Sat, 28 Aug 2004 14:21:10 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7SLK585016357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Aug 2004 17:20:06 -0400 Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) From: Paul Iadonisi To: IETF MARID WG In-Reply-To: References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> <1093720180.7023.148.camel@va.local.linuxlobbyist.org> Content-Type: text/plain Message-Id: <1093727953.7023.167.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 28 Aug 2004 17:19:14 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2004-08-28 at 16:14, Mark Lentczner wrote: [snip] > However, you are mistaken: There is nothing heuristic in the PRA > identity. It follows directly from the RFC 2822 definition of the > headers. The meanings of From:, Sender:, Resent-From:, and > Resent-Sender: is in there, as is their relative precedence and the > ordering issue with Resent-Sender: and multiple Resent-* blocks. I stand corrected. However, Roy's comment about SPF identity (MAIL FROM) not being available in any reliable way is not accurate, except to the extent that most MUAs do not display it by default. It is, however, easily accessible. That was my main point. So to correct myself, both SPF and Sender-ID identities are essentially equivalent with respect to how available they are to the MUA (relatively speaking, since no MUAs currently display either by default). -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 18:55: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 SAA18462 for ; Sat, 28 Aug 2004 18:55: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 i7SMXujk016520; Sat, 28 Aug 2004 15:33: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 i7SMXuuP016519; Sat, 28 Aug 2004 15:33:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMXnJv016493 for ; Sat, 28 Aug 2004 15:33:56 -0700 (PDT) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id i7SMXd9I079350; Sat, 28 Aug 2004 22:33:39 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.12.9-20030917/8.12.9) with ESMTP id i7SMXd2C003257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 00:33:39 +0200 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id i7SMXcrr003256; Sun, 29 Aug 2004 00:33:38 +0200 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Sun, 29 Aug 2004 00:33:38 +0200 From: Koen Martens To: "Hallam-Baker, Phillip" Cc: "'John Levine'" , ietf-mxcomp@imc.org Subject: Re: Why sublicensing is important Message-ID: <20040828223338.GJ2468@metro.cx> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eDB11BtaWSyaBkpc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 X-Helo-Milter: checked X-Helo-Reject: No Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --eDB11BtaWSyaBkpc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 28, 2004 at 11:36:30AM -0700, Hallam-Baker, Phillip wrote: >=20 > This is not a code license, it is a patent license. Confusing the > two is mistaken. So why then does the license put terms on the distribution of code and binaries?=20 Koen --=20 K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ --eDB11BtaWSyaBkpc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBMQhCktDgRrkFPpYRAunbAJ0U9v0tZ4Og3OwH3eAWxSOuZspuuACglQYG sK4xkSPSVU480SDCKbZ5PqE= =F7DK -----END PGP SIGNATURE----- --eDB11BtaWSyaBkpc-- From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 19:31:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19609 for ; Sat, 28 Aug 2004 19:31:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SN7qp3020041; Sat, 28 Aug 2004 16:07: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 i7SN7qli020040; Sat, 28 Aug 2004 16:07: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 i7SN7oGm020027 for ; Sat, 28 Aug 2004 16:07:51 -0700 (PDT) (envelope-from roy+dated+1096326468.8794b5@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7SNBmhP018296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 28 Aug 2004 23:11:54 GMT (envelope-from roy+dated+1096326468.8794b5@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7SN7n10006513 for ; Sun, 29 Aug 2004 00:07:49 +0100 (BST) (envelope-from roy+dated+1096326468.8794b5@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7SN7m71006512 for ietf-mxcomp@imc.org; Sun, 29 Aug 2004 00:07:48 +0100 (BST) (envelope-from roy+dated+1096326468.8794b5@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 29 Aug 2004 00:07:48 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16689.4163.809423.451252@giles.gnomon.org.uk> Date: Sun, 29 Aug 2004 00:07:47 +0100 To: John Levine Cc: ietf-mxcomp@imc.org Subject: Why sublicensing is important In-Reply-To: <20040828170523.12731.qmail@xuxa.iecc.com> References: <20040828170523.12731.qmail@xuxa.iecc.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "John" == John Levine writes: John> A recent article in eWeek makes it crystal clear that the John> crucial issue in the Microsoft patent license is John> sublicensing, and that the MS lawyers can't (or at least John> won't) change the terms. I think allowing sublicensing of the patent grant would significantly weaken the effectiveness of the reciprocal patent grant as a defensive measure. It seems fairly obvious to me that the license is drafted in such a way as to give maximum protection to the community as a whole against patent claims on Sender ID. Would it be possible for Microsoft to give some legally binding guarantee that the Sender ID license will _always_ be available under the current terms? Would that meet your concerns? Would Microsoft be willing to take such a step? -roy From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 21:50: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 VAA24501 for ; Sat, 28 Aug 2004 21:50:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T1HmPW027443; Sat, 28 Aug 2004 18:17: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 i7T1HmBL027442; Sat, 28 Aug 2004 18:17:48 -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 i7T1HmIX027435 for ; Sat, 28 Aug 2004 18:17:48 -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, 28 Aug 2004 21:17:51 -0400 id 00213569.41312EBF.0000164E In-Reply-To: <413024E4.7010508@comcast.net> References: <200408271957.i7RJvlSe050319@m5p.com> <1093638545.7023.64.camel@va.local.linuxlobbyist.org> <413024E4.7010508@comcast.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3DF0ED8C-F959-11D8-881C-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Paul Iadonisi , ietf-mxcomp@imc.org From: Andrew Newton Subject: Re: Problematic issues with regard to last call Date: Sat, 28 Aug 2004 21:17:49 -0400 To: "David H. Lynch Jr." X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 28, 2004, at 2:23 AM, David H. Lynch Jr. wrote: > But was is holding fast to a particular position so long as it is > reasoned and supported a problem ? Nothing is wrong with that. But holding to a position regardless of reason only leads to dogmatic standoffs. -andy From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 22: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 WAA24863 for ; Sat, 28 Aug 2004 22: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 i7T1QOla027888; Sat, 28 Aug 2004 18:26:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T1QOPS027887; Sat, 28 Aug 2004 18:26:24 -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 i7T1QOTD027881 for ; Sat, 28 Aug 2004 18:26:24 -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, 28 Aug 2004 21:26:28 -0400 id 00213569.413130C5.000016CC In-Reply-To: <1093650303.3782.3839.camel@localhost.localdomain> References: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> <1093650303.3782.3839.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <72A8ABAC-F95A-11D8-881C-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: MARID , Jim Lyon From: Andrew Newton Subject: Re: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages Date: Sat, 28 Aug 2004 21:26:27 -0400 To: Mark Shewmaker X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 7:45 PM, Mark Shewmaker wrote: > So, is that suggestion something that could be included within > SenderID, > perhaps in a security-considerations section? For clarity, can you give the text you would like included in the security section? I think this would better help in understanding the problem and better help people formulate an opinion. -andy From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 22:08:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25160 for ; Sat, 28 Aug 2004 22:08: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 i7T1WFPb028248; Sat, 28 Aug 2004 18:32: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 i7T1WFB8028247; Sat, 28 Aug 2004 18:32:15 -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 i7T1WEEk028239 for ; Sat, 28 Aug 2004 18:32: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 092A0414EF; Sat, 28 Aug 2004 18:32:19 -0700 (PDT) Received: from 69.36.229.218 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sat, 28 Aug 2004 18:32:19 -0700 (PDT) Message-ID: <63413.69.36.229.218.1093743139.squirrel@harry.mail-abuse.org> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.micr osoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> Date: Sat, 28 Aug 2004 18:32:19 -0700 (PDT) Subject: RE: DEPLOY - IP, HELO & touch count. DOC-BUG too. From: "Douglas Otis" To: "Jim Lyon" Cc: "Douglas Otis" , "Matthew Elvey" , "MXCOMP" 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 Fri, 27 Aug 2004 14:52:56 -0700 Jim Lyon wrote: > On Thu, 26 Aug,2004 at 5:07 PM, Douglas Otis wrote: >> On Thu, 2004-08-26 at 15:56, Jim Lyon wrote: >>> On Thursday, August 26, 2004 at 1:35 PM, Doug Otis wrote about the >>> authentication and authorization aspects of SenderID, compared to >>> schemes involving EHLO. >>> >>> After much thinking, I realized that our disagreements have to do with >>> confusions about how the two schemes treat identity, authentication and >>> authorization. >>> >>> Sender-ID: >>> >>> Identity: The identity of a sending MTA is its IP address. >>> >>> Authentication: There is no authentication other than that implicit in >>> the TCP/IP stack. Because in practice you can't perform an SMTP >>> transaction without being able to receive packets destined to the IP >>> address, this works well. (Yes, I know about TCP/IP spoofing attacks, >>> but they're impractical for sending bulk e-mail.) >>> >>> Authorization: The SenderID test determines whether the sending MTA is >>> authorized to send mail that claims to come from a particular domain. >>> This authorization can only be bestowed by the domain that the mail >>> claims to come from. >> >> The Identity being authorized is the PRA Mailbox Domain by way of >> reference to a Mail Channel prescription of IP addresses. This PRA >> Mailbox is the Identity the draft hopes exposed to the user. The >> Mailbox Domain has not been authenticated, only authorized as the Mail >> Channel will not safely permit such conclusion. The domain >> administratively accountable for the MTA remains anonymous beyond the IP >> address. There is no identity authenticated through this relationship >> unless you wish to claim some significance with the MTA IP address. If >> there is a problem, what identity will the user report? If there is a >> problem, what identity will the MTA/MUA filter or reject? In each case, >> the PRA Mailbox Domain is the identity affected. The problem is that >> this identity has not been authenticated, but the authenticated MTA IP >> address is ignored. > > No, please try reading it again. The identity being authorized is the > sending MTA's IP address. The action being authorized is to send a > message on behalf of the PRA. The organization doing the authorization > is the domain of the PRA. This is a distinction without much significance. Restated to suit your definition would be: The identity being authorized is (the IP address to send the message on behalf of) the PRA Mailbox Domain by way of reference to a Mail Channel prescription of IP addresses. Of course the Mail Channel prescription would be administratively controlled by the PRA Mailbox Domain and the PRA Mailbox Domain resolves the prescribed Mail Channel. PRA Mailbox Domain -> Mail Channel IP Address prescription -> MTA IP Address Although the IP address has been authenticated by way of the TCP protocol, the PRA Mailbox Domain has not been authenticated, as the RFC2822 information is not trustworthy. The only safe identity resulting when skiping the steps of authenticating the MTA before resolving authorization (for sending the message based upon) the Mailbox Domain is the MTA IP address. This does not represent much of an improvement with respect to how reputation can be handled. Mailbox Domain -> Mail Channel EHLO Name prescription -> Authenticated EHLO This has the advantage of providing of the EHLO domain being useable with reputation checks which minimizes efforts needed to track IP addresses of various entities. It also has the advantage of allowing the Mail Channel prescription to be just a simple list of names that do not require obtaining address lists maintained by other domains to resolve the Mail Channel. Imagine, one DNS lookup and you're done. : ) >>> EHLO-based schemes: >>> >>> Identity: The identity of a sending MTA is its EHLO name. >>> >>> Authentication: Various scheme to determine whether the EHLO name that >>> an SMTP client sent is true. >> >> The goal of CSV is to ensure a consistent and simple scheme >> authenticates and verifies MTA authorization. The identity is the EHLO >> domain as the message broker. This authenticated identity can be held >> accountable. The Sender-ID identity as represented by the PRA Mailbox >> Domain has not been authenticated as this requires unverifiable >> assumptions made with respect to Mail Channel. Bug. >> >>> Authorization: Depending on the scheme, there might be none. >>> Otherwise, there might be a scheme to determine whether the sending MTA >>> is authorized by its domain owner to be an SMTP client. There is no >>> authorization of individual messages. >> >> As I said, CSV provides both MTA authentication and authorization. This >> was the goal of the MARID charter. : ) >> >>> The SenderID series of documents is based on an explicit decision to >>> pursue the first world-view; the fact that it doesn't do the second is >>> not a bug. >> >> Not authenticating the identity you wish everyone to hold accountable is >> a bug in this logic. By allowing an "open-ended" record to exist, this >> process becomes an exercise in futility, as not even the IP address of >> the otherwise anonymous MTA is checked. Such "open-ended" records leave >> open the door for endless spoofing. Sender-ID's false assumptions of >> identity trustworthiness will ensure great potential for harm. : ( > > (... yet another advertisement for CSV ...) > Ignored as not relevant. Could I expect a clarification that reputation is not to be based upon the PRA Domain, but rather the IP address of the MTA? -Doug From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 22:27: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 WAA25626 for ; Sat, 28 Aug 2004 22:27: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 i7T21gnK031224; Sat, 28 Aug 2004 19:01: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 i7T21gHR031223; Sat, 28 Aug 2004 19:01:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T21fU4031217 for ; Sat, 28 Aug 2004 19:01:41 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-108-527.area3.spcsdns.net ([68.245.166.74]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C1F0s-0001Bl-Mj; Sat, 28 Aug 2004 22:01:48 -0400 Message-ID: <413138FB.5020402@solidmatrix.com> Date: Sat, 28 Aug 2004 22:01:31 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Paul Iadonisi CC: ietf-mxcomp@imc.org Subject: Re: In favour of Sender ID References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> <1093720180.7023.148.camel@va.local.linuxlobbyist.org> In-Reply-To: <1093720180.7023.148.camel@va.local.linuxlobbyist.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Iadonisi wrote: > On Sat, 2004-08-28 at 14:21, Roy Badami wrote: > >>Even if Sender ID is incompatible with the GPL [2] -- and I'm >>skeptical that it is except under the most extreme interpretations -- > > > And we have yet to see a convincing legal argument (or *any* legal > argument) from an attorney posted to this list. I'd like to know what > Anne Mitchell (on this list) thinks of her legal analysis being called > extreme by a non-lawyer. > The main point here is whether the current IPR issue can delay deployment. The mere fact that several lawyers have stated their expert opinion that this license is incompatible with existing open source licenses, can cause deployment problems. However, it is important to note how people react to their statements. We have already seen several parties including myself stating that they will not implement Sender-ID in their products unless the legal terms are changed, or the legal situtation is clarified. We also saw several parties, including Roy, state that they are willing to implement it even with the current legal situation intact. Therefore, it seems to me that there exists a sizable percentage of the possible market for this standard that will hesistate to deploy Sender-ID. This, we have a deployment problem. Whether the underlying facts that cause it are true, might not be relevant, since we care about what people will do. Yakov From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 22:27: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 WAA25644 for ; Sat, 28 Aug 2004 22:27: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 i7T20QTb031151; Sat, 28 Aug 2004 19:00: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 i7T20QRv031150; Sat, 28 Aug 2004 19:00: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 i7T20QL4031144 for ; Sat, 28 Aug 2004 19:00:26 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Sat, 28 Aug 2004 22:00:32 -0400 id 0021356A.413138C0.000018F8 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <413012BA.3070900@comcast.net> References: <970CDC76-F816-11D8-9196-000A95B3BA44@hxr.us> <412F228E.4070007@hepcoe.com> <413012BA.3070900@comcast.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <34798076-F95F-11D8-881C-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: on the topic of IPR Date: Sat, 28 Aug 2004 22:00:30 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 28, 2004, at 1:06 AM, David H. Lynch Jr. wrote: > Microsoft's participation is to be highly desired, but if the > resulting standard includes any License from Microsoft, then the > standard itself becomes evidence of the validity of the patent on the > licensed IP. If there is a strong beleif that the IP is not patentable > either through prior art or otherwise then MARID should not be taking > a position validating it. Actually, there is nothing this working group can do to validate or invalidate Microsoft's IPR. After looking at their license and IPR claim, we can decide not to further Sender ID in the standards process, or we can decide to send it on in acceptance of their IPR claim, or we can decide to send it on while ignoring their IPR claim. The latter has not been discussed here much. -andy From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 22:29: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 WAA25749 for ; Sat, 28 Aug 2004 22:29: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 i7T1svfW030930; Sat, 28 Aug 2004 18:54: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 i7T1svBx030929; Sat, 28 Aug 2004 18:54:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T1su8g030921 for ; Sat, 28 Aug 2004 18:54:56 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-108-527.area3.spcsdns.net ([68.245.166.74]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C1EuF-0000vA-P0; Sat, 28 Aug 2004 21:54:57 -0400 Message-ID: <4131375D.4080609@solidmatrix.com> Date: Sat, 28 Aug 2004 21:54:37 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'John Levine'" , ietf-mxcomp@imc.org Subject: Re: Why sublicensing is important References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: >>Without >>attributing any evil intent, I find that much too risky simply because >>I don't know what situation Microsoft will be in three or five years >>from now, and neither does anyone else. > > > Once the license is granted it is granted. > The license states that it can be revoked if the licensee if found in material breach of the terms. Microsoft's lawyers get to determine that and the only way to challenge and resolve that if it happens, would be through the courts. The mere fear of a possible legal proceeding might be sufficient to delay deployment. Yakov From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 22:49:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26297 for ; Sat, 28 Aug 2004 22:49:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2EATf031654; Sat, 28 Aug 2004 19:14: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 i7T2EAeV031653; Sat, 28 Aug 2004 19:14:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2E9oZ031647 for ; Sat, 28 Aug 2004 19:14:10 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-108-527.area3.spcsdns.net ([68.245.166.74]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C1FCy-00026F-C3; Sat, 28 Aug 2004 22:14:18 -0400 Message-ID: <41313BE6.1020106@solidmatrix.com> Date: Sat, 28 Aug 2004 22:13:58 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Markus Stumpf CC: "Hallam-Baker, Phillip" , IETF MARID WG Subject: Re: on the topic of IPR References: <20040828031119.GM30023@Space.Net> In-Reply-To: <20040828031119.GM30023@Space.Net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Markus Stumpf wrote: > On Fri, Aug 27, 2004 at 06:28:00PM -0700, Hallam-Baker, Phillip wrote: > >>Microsoft has clearly decided it is not going to get taken by another >>Eolas type patent. Short of the USPTO burning down a second time >>and all records being lost (if only!) the only way to get any >>protection against a patent suit is to file for a patent yourself >>and hope you got yours in first. > > ... > I really don't understand why the license has to have any restrictions? > Why do they put in this sublicensing thingy? > Why don't they simply say: > - we hold the patent > - we grant everyone and every company a 20/50/100 years irrevocable > license to make use of the IPR covered by this patent free of > charge. > They could even transfer the patent to the IETF/ISOC and make a contract > they will never have to pay any license fees nor can someone revoke the > license for them to use the IPR covered. > I don't understand it either. The patent trolls are not going to be caught with the license anyway. Perhaps, a lawyer (Anne?) can explain this? > They do neither and because of that I neither trust nor do I believe them. > This is nothing special about Microsoft, it is generic to companies that > size and that historic behaviour (and to a lot of others, too). > It is interesting to note that RFC 3669 recommends using historical behavior of the IPR holder as part of the overall decision on IPR issues: " If working group participants are dissatisfied with the confidence level they can obtain directly about licensing terms for a particular technology, they can possibly extrapolate from history. In order for licensed technology to become a draft standard, at least two independent licenses need to have been issued. If the IPR claimant for the technology the working group is considering has licensed other technology in the past, there is a record of the sorts of terms they are willing to grant, at least in those specific cases. This sort of thing is weak but everything counts, and it may be of some help. " It would be interesting to see what this evaluation what bring up in regards to Microsoft. Yakov From owner-ietf-mxcomp@mail.imc.org Sat Aug 28 23:37: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 XAA27939 for ; Sat, 28 Aug 2004 23:37:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2tjg8033874; Sat, 28 Aug 2004 19:55: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 i7T2tjLK033873; Sat, 28 Aug 2004 19:55:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2tit4033867 for ; Sat, 28 Aug 2004 19:55:44 -0700 (PDT) (envelope-from ogud@ogud.com) Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i7T2tboH078393; Sat, 28 Aug 2004 22:55:37 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040828214646.02a823d0@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Sat, 28 Aug 2004 22:55:38 -0400 To: "Jim Lyon" , "IETF MARID WG" From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: TECH-ERROR: DNS Record Types In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchang e.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.44 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 20:09 23/08/2004, Jim Lyon wrote: >I believe that the latest Protocol draft (draft-ietf-marid-protocol-03) >contains changes that don't correctly reflect the consensus of the group >concerning DNS record types. Briefly, it states: > >1. Publishers MUST publish using the new SPF2 record type. >2. Publishers MAY also publish using TXT records. >3. Consumers MUST do lookups using the new SPF2 record type. >4. Consumers MAY also do lookups using TXT records. >5. Consumers MAY do both lookups (3 and 4) in parallel. >6. If consumers receive records from both lookups, they SHOULD use > the SPF2 record and ignore the TXT record. > >These are all in section 2.1.1 of the Protocol doc. > >The problems with the above are: > >a. It's not what was previously debated / agreed to. >b. Anyone who can't publish an SPF2 record cannot comply with this spec. >c. Anyone who can't look up an SPF2 record cannot comply with this spec. >d. Publishers who take the "MAY" in step 2 above to heart and don't > publish TXT records will have their record be completely invisible > to consumers that can't query for the new record type. Standards documents are supposed to be long lived, and everyone knows there is going to be a period during which b. and c. are facts of life. The question is how to overcome that hurdle in the shortest time possible. In my dealings with operational people the only thing that will get them to upgrade is clear violation of standards, "MUST" or "MUST NOT" violation. "SHOULD" "SHOULD NOT" "MAY" are brushed under the table or join the long queue of things to fix when time is available. For this reason I pushed for the strong text in the draft. Your point d. is a good one but still runs counter to the philosophy above as when SPF (I do not like the name SPF2) RR has died or become prevalent there is no reason publish spf policies in TXT records. As for a. is concerned I can not find an statement from chairs that is the consensus of the working group. One of the reasons that Mark agreed to the text was exactly to find out if a rough consensus on this issue could be formed. >I respectfully request that the above requirements be replaced with: > >1.Pushblishers SHOULD publish using the new SPF2 record type, > if they are able to do so. This is an operational guidance not a definition of a standard. If this text is accepted by the WG then none has to ever deploy the new type. >2. Regardless of whether they published using the SPF2 record > type, publishers MUST publish a TXT record. This is counter to a long term strategy and unless the WG intents to be around for a long time there will never be a time when publishing only SPF RR is acceptable. >2a.The contents of the SPF2 record and TXT record MUST be identical. This I agree with and the current document says so (at least that is my reading of section 2.1 paragraph 3). But I agree with you that putting in a MUST there is a good idea. >3. Consumers SHOULD check for the new SPF2 record type, if they > are able to do so. >4. Consumers who either cannot query for SPF2 records or who find > that a domain hasn't published any SPF2 records MUST query for > a TXT record. >5. Consumers MAY do both lookups (3 and 4) in parallel. >6. If consumers receive records from both lookups, they SHOULD use > the SPF2 record and ignore the TXT record. > >Brief Discussion: >It's undisputed that the world would be a better place if everyone uses >the new record type. However, it's also undisputed that many players >won't be able to publish and/or consume the new record type until new >software is installed. The updated requirements as I've spelled them out >above will me that: > a) Everyone can work before new DNS software is installed. > b) After new DNS software is installed, there will be minimal harm to >the DNS system. The fundamental difference between your position and mine is you: want everyone to be compliant at all times. me: Specify clearly fully compliant state and tolerate non compliance during phase-in. >I think that (a) is obvious. There are four sub-cases: >i. Publisher and consumer both have out-of-date DNS software: > >If the publisher and consumer both have out-of-date DNS software, the >publisher will only publish a TXT record. The consumer will only query >for a TXT record, and get the right information. All of the oft-debated >issues of packet size and TCP fallback apply. This is the stage we all are trying to keep to absolute minimum, What the text in the ID is trying to do is to get as publishers to publish SPF records as soon as possible, while giving the consumers more flexibility in how the information is accessed: via TXT or SPF records. The issue we need to keep in mind is test and traceability. It is simple and quick to check if a publisher is compliant, thus the MUST's. It is simple to check if a consumer MTA issues queries for SPF, thus the MUST. It is hard to check which type is used, if both are available thus the SHOULD. Once the records are available and consumers have started to ask for them then it is publishers choice to either continue to publish TXT records or risk failures when dealing with the laggard consumers. >ii. Publisher has up-to-date DNS software and consumer has out-of-date >DNS software: >iii. Publisher has out-of-date DNS software and consumer has up-to-date >DNS software: >iv. Publisher and consumer both have up-to-date DNS software. > >If both the publisher and the consumer have up-to-date DNS software, the >publisher will publish both an SPF2 and a TXT record. They consumer will >query for the SPF2 record, and get the right information. The >packet-size issues will generally not apply, because the SPF2 record >won't be mingled with other irrelevant records. > >So in all four cases, the updated requirements work. Contrast this with >the currently specified requirements, which cause cases (ii) and (iii) >to fail to discover the record. I humbly disagree, the ID documents the state everyone will (hopefully) migrate to, in your analysis you assume the worst behavior possible by both sides. For the publisher in the short term it is in their interest to publish both RR types with spf information. Similarly the consumer by asking for both types maximizes its chance of getting an answer. Once the MARID RR type has been in use for some time it is possible to assess if it is worth while, then there are two optimizations possible: cut out the TXT query from the MTA's Tear out all the SPF processing from the MTA's. At this point I do not know which one will be the one done, I hope it is the first one. In conclusion, I recommend the WG keep the text as is. Olafur From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 00:12: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 AAA29236 for ; Sun, 29 Aug 2004 00:12: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 i7T3clUU036591; Sat, 28 Aug 2004 20:38: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 i7T3cl8R036590; Sat, 28 Aug 2004 20:38:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T3ckOG036584 for ; Sat, 28 Aug 2004 20:38:46 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7T3cmA2001359; Sat, 28 Aug 2004 20:38:48 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 28 Aug 2004 20:38:48 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , "Hallam-Baker, Phillip" Cc: "'John Levine'" , ietf-mxcomp@imc.org Subject: RE: Why sublicensing is important Date: Sat, 28 Aug 2004 20:38:47 -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 license states that it can be revoked if the licensee if found in > material breach of the terms. Microsoft's lawyers get to > determine that No they don't, the phrase material breach has a very narrow legal definition, it means that the licensee has to fail to keep an undertaking made. Since the only undertaking made is not to sue microsoft for infringement of a Sender ID patent there is absolutely no ambiguity here. > and the only way to challenge and resolve that if it happens, > would be through the courts. The only way to breach the terms of the license is to sue Microsoft which means that you are already in court. From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 00:35: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 AAA00378 for ; Sun, 29 Aug 2004 00:35: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 i7T414ap038144; Sat, 28 Aug 2004 21:01:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T414Xk038143; Sat, 28 Aug 2004 21:01:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T413cu038137 for ; Sat, 28 Aug 2004 21:01:03 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-108-527.area3.spcsdns.net ([68.245.166.74]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C1GsR-00063G-IU; Sun, 29 Aug 2004 00:01:13 -0400 Message-ID: <413154F1.20404@solidmatrix.com> Date: Sun, 29 Aug 2004 00:00:49 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: ietf-mxcomp@imc.org Subject: Re: Why sublicensing is important References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hallam-Baker, Phillip wrote: >>The license states that it can be revoked if the licensee if found in >>material breach of the terms. Microsoft's lawyers get to >>determine that > > > No they don't, the phrase material breach has a very narrow legal > definition, it means that the licensee has to fail to keep an > undertaking made. Since the only undertaking made is not to sue > microsoft for infringement of a Sender ID patent there is absolutely > no ambiguity here. I believe that you are referring to section 2.4 of the license: ----snip--- "2.4 Defensive Suspension. If Microsoft or any of its Affiliates, or You or any of Your Affiliates, are first sued for patent infringement (“the sued party”) by the other Party hereto or any of its Affiliates, on account of the manufacture, use, sale, offer for sale, importation or other disposition or promotion of the sued party’s Licensed Implementation or Microsoft’s Sender ID Implementation, as applicable, then the sued party may terminate all license grants and any other rights provided under this Agreement to such entity and such entity’s Affiliates. The foregoing shall not apply if the patent infringement suit that would otherwise trigger such clause is solely based on the sued party’s Licensed Implementation or Microsoft’s Sender ID Implementation (as defined in Section 2.3), as applicable, not complying with the scope of the license grants set forth in this Agreement. " ----snip--- I was refering to section 3 of the license: ----snip--- "Microsoft may terminate this Agreement (including all license grants) earlier if You materially breach this Agreement, and You fail to cure the breach within thirty (30) days after You receive notice of the breach from Microsoft." ----snip--- Yakov From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 03:59: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 DAA23393 for ; Sun, 29 Aug 2004 03:59:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T7M5wH086659; Sun, 29 Aug 2004 00:22:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T7M5R5086658; Sun, 29 Aug 2004 00:22:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T7M4CM086651 for ; Sun, 29 Aug 2004 00:22:04 -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 23106414EF; Sun, 29 Aug 2004 00:22:05 -0700 (PDT) Received: from 64.142.13.68 (SquirrelMail authenticated user dotis) by harry.mail-abuse.org with HTTP; Sun, 29 Aug 2004 00:22:05 -0700 (PDT) Message-ID: <1183.64.142.13.68.1093764125.squirrel@harry.mail-abuse.org> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAFC7@df-fido-msg.exchange.corp.micr osoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFC7@df-fido-msg.exchange.corp.microsoft.com> Date: Sun, 29 Aug 2004 00:22:05 -0700 (PDT) Subject: RE: TECH OMISSION: Stronger checks against email forgery From: "Douglas Otis" To: "Jim Lyon" Cc: "Douglas Otis" , "John Glube" , "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 Fri, Aug 27, 2004 2:22 pm Jim Lyon wrote: > On Thu, 26 Aug 2004 15:00:54 -0700 Douglas Otis wrote: >> On Thu, 2004-08-26 at 11:27, Jim Lyon wrote: >>> John points out that a forger can defeat SenderID checks by inserting a >>> Resent-From (or similar) header that references either himself a domain >>> that hasn't published a SenderID record. >>> >>> He goes on to suggest possible ameliorations, including EHLO checks >>> and/or classic SPF checks using MAIL-FROM. >>> >>> He's right that there's a potential problem, but I think he got the >>> wrong amelioration. >>> >>> If there's consensus that a change is required, I would recommend: >>> >>> Whenever the PRA is not equal to the 2822 "From", and the SenderID >>> result is anything other than "pass", and at least 6 months have elapsed >>> since SenderID became a Proposed Standard, then the message SHOULD be >>> treated as forged. >> >> The reference could be from any domain that provides an "open-ended" >> record. The referenced record could be from a "throw-away" domain as a >> means to still spoof _ANY_ RFC2822 From Mailbox Domain. As checks >> become more stringent, more domains may be tempted to publish "+all" >> records to quell picayune refusals. Reputation services will become >> inundated and ineffectual due to lack of Sender-ID identity >> authentication. Will Sender-ID really force the world to publish highly >> problematic records as pertaining to reputation services? > > Yes, they will. And those domains will get a (richly deserved) bad > reputation, and most people will refuse to accept mail from them. > > That other (unspecified) factors will cause many legitimate domains to > publish records with "+all". I don't believe it. I certainly haven't seen > anyone on this list claim that they intend to publish a "+all". Why is there a "+all" when no one intends to use this notation? Now you suggest when they do, they'll get a bad reputation. If reputation is based upon the IP address, as you previously suggested, using a "+all" would not affect the IP address. It could easily be a dare, "Declare this domain as a spammer on this basis, and they'll see you in court." By having "+all" in the standard, it plainly implies "Don't compare this domain's mail to their list of MTA IP addresses." The same problem exists with "?all", as long as this also is accepted, this raises the same question, why? The standard is allowing these settings. This deserves a better explanation than no one will use it, and, if they do, their mail will be blocked. >>> Reasons for this proposal: >>> >>> 1. For most instances of personal mail, PRA == 2822 From == bounce >>> address, and none of these issues apply. They only apply in the cases >>> of specialized agents like forwarders, list servers, third-party mailers >>> and similar. >> >> Sender-ID will likely invite such assumptions to change. From providers >> dealing with customers expecting to send mail from their networks, the >> norm could easily become inclusion of the Resent-From header. This >> "every field is the same" model does not fit for large amounts mail and >> will impose exceptional problems for most domains to confront. > > That SenderID will cause the normal, person-to-person email message to > use something other than PRA == 2822 From == bounce address. > I don't believe this either. Is there any support for this proposition? > If SenderID forces a change, then what will it change to? As I said, ISPs not wishing to endure costs of training their customer base to quit using their return addresses and are forced by those that decide to refuse to accept mail with lists using of "+all" or "?all". The solution is rather obvious. Add a Resent-From header that can be comprehensively defined in a "closed" list that is independent of the RFC2822 From header. There would be virtually no difference in the scope of this identity from that returned by CSV, except that the name obtained from CSV has been authenticated without making unverifiable assumptions of the Mail Channel. >>> 2. It's reasonable to hold specialized agents to a higher standard than >>> the rest of the E/Mail community (by requiring a "pass" instead of >>> merely the absence of a "fail", for instance.) >> >> This could create a deployment reaction of having Resent-From included >> routinely to ameliorate a long list of potential problems. Once that >> becomes the norm, EHLO authentication and authorization would then >> provide the same identity. If one were to follow this logic of all >> fields are normally the same, only authenticating and confirming >> authorization of the EHLO domain arrives at the same identity with much >> less chance of this identity being spoofed! >> >>> 3. When the set of documents hits Proposed Standard, many of the >>> legitimate specialized agents won't yet be in compliance. But as a >>> whole, it's a well-managed community that can move fairly quickly. >> >> How will they move? Where are we going and why are we in this >> hand-basket? : ) Will they re-train their customers or add a >> Resent-From? >> >>> Reasons against EHLO or bounce address: >>> >>> 1. EHLO tells you a name for the sending MTA. But it gives you no idea >>> whether that MTA is authorized to act on behalf of the name mentioned in >>> the message he's sending. It seems therefore to be irrelevant. >> >> Seems irrelevant? There you go, blaming the message rather than the >> messenger. : ) >> >> It is a matter of first establishing accountability. The assumptions >> used to validate a Sender-ID identity will not allow the Sender-ID >> identity to be held accountable. >> >> A simple scheme to impose a Mail Channel prescription upon either the >> RFC2821 MAIL FROM or the RFC2822 From is illustrated in this draft: >> >> http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt >> >> Accountability is established first, and this scales well for then >> prescribing the Mail Channel. The use of the prescription is for >> authorization, never authentication. >> >>> 2. bounce address tells you who wants to know if the message isn't >>> delivered. It's also irrelevant when deciding whether the MTA is >>> authorized to act of behalf of the name mentioned in the message he's >>> sending. >>> >> By also allowing a Mail Channel prescription for the MAIL FROM Mailbox >> Domain would curtail bounce traffic. The use of reputation services can >> not abate this type of traffic. Again, I refer you back to the MPR >> draft as how this type of restriction can be imposed while not requiring >> sequential DNS lookups. > > That all problems are solved if we merely implement > draft-otis-marid-mpr-00. I (and many others on the group) disagree, for > reasons stated many times previously. I would think for Last-Call these reasons would be restated on your behalf. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 06:56: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 GAA29803 for ; Sun, 29 Aug 2004 06:56: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 i7TASWhT043912; Sun, 29 Aug 2004 03:28: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 i7TASVpF043911; Sun, 29 Aug 2004 03:28:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.old-mill.net (old-mill-adsl.demon.co.uk [80.176.87.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TASUBZ043878 for ; Sun, 29 Aug 2004 03:28:31 -0700 (PDT) (envelope-from nick@old-mill.net) MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Microsoft Claimed IP, License Terms, etc. X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Nick Shelness Message-ID: Date: Sun, 29 Aug 2004 11:27:21 +0100 X-MIMETrack: Serialize by Router on MailGate/Home(Release 6.0|September 26, 2002) at 29/08/2004 11:27:01, Serialize complete at 29/08/2004 11:27:01 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, I don't really want to enter this discussion, but I believe it is necessary. For those that don't know me, I'm the ex-CTO of Lotus (98-01) and thus someone who professionally had to spend a great deal of time (too much) worrying about IP issues, and consulting with IP lawyers. I was also the source of a private suggestion to Harry Katz that [E]SMTP be extended to identify the email submitter as an alternative to mucking about with RFC [2]822 headers. At the time, Harry indicated that this idea was new to him and Microsoft. I leave it to Harry to indicate whether he has subsequently encountered a prior claim to this idea. Now to the nub of the issue. Microsoft has disclosed that they claim to possess Intellectual Property (IP) that must be utilized to implement the in-process-of-development IETF standards described in draft-ietf-marid-core-03.txt, draft-ietf-marid-pra-00.txt, and their successors. This disclosure is required as a precondition of Microsoft (employees) involvement in the development of these in-process-of-development IETF standards. They are not required to disclose specifics of the IP they claim to posses, merely that they claim to possess it. This disclosure in no way establishes the validity of this claim. This awaits the issuance of a patent or patents, and the subsequent defense of this patent or patents. Any individual or organization is free to write to the patent authorities in any and all jurisdictions claiming that IP that they believe has been submitted for patent protection is covered by "prior art" or is "obvious", both of which are grounds for rejection of a patent application. The patent authorities can also determine that IP that has been submitted for patent protection is covered by "prior art" or is "obvious" on their own, but in the US they are constrained by a number of adverse judgements that restrict their ability to so do. Given the above, an individual or organization wishing to implement and distribute code that supports the processes defined in draft-ietf-marid-core-03.txt, draft-ietf-marid-pra-00.txt, and their successors, has to determine the strength of Microsoft's, and other potential, and as yet undisclosed, IP claims. This is unfortunate, but is a feature of the current software development landscape. In the case of the Microsoft IP claims, Microsoft has offered to waive any and all of their claims with respect to IP required to implement the in-process-of-development IETF standards described in draft-ietf-marid-core-03.txt, draft-ietf-marid-pra-00.txt, and their successors, on a royalty-free basis in exchange for execution of a license agreement. I recognize that there potential problem with this licence, especially with respect to its non-extension to sub-licences. So, net, net, implementors have three choices. 1. They, with the help of their advisors, can determine that Microsoft, and as yet unknown others, possesses no IP that would encumber an implementation of draft-ietf-marid-core-03.txt, draft-ietf-marid-pra-00.txt, and their successors. Based on such a determination, they can then proceed apace. They might of course be liable to subsequent claims for redress from Microsoft, and as yet unknown others, if this determination proved subsequently to be in error. 2. They, with the help of their advisors, can determine that Microsoft, and as yet unknown others, do possesses IP that would encumber an implementation of draft-ietf-marid-core-03.txt, draft-ietf-marid-pra-00.txt, and their successors, but can further determine that Microsoft, and as yet unknown others, are highly unlikely to make claims for redress. Based on such a determination, they can then proceed apace. 3. They, with the help of their advisors, can determine that Microsoft, and as yet unknown others, do possesses IP that would encumber an implementation of draft-ietf-marid-core-03.txt, draft-ietf-marid-pra-00.txt, and their successors, and in order to receive protection from subsequent claims for redress from Microsoft enter into a licence agreement with Microsoft that grants them the right to employ the claimed IP. They can then proceed apace. The IETF (marid wg) also has a number of choices. 1. Encourage Microsoft to more precisely identify their claimed IP so that implementors could make a more informed judgement with respect to its "obviousness" and coverage by "prior art". My guess, is that this IP is limited to determining whether the PRA as defined by the PRA algorithm is consistent with the sending SMTP client's IP address. My sense is that "prior art" can be found for determining the PRA - it's implicit in RFC 822, but not for whether the PRA is consistent with the sending SMTP client's IP address. 2. Limit the scope of marid to the [E]SMTP MAIL FROM: command, with or without the SUBMITTER parameter. RMX, SPF, etc. which operated on the MAIL FROM: address almost certainly constitute prior art, and I am the source of the proposal to Microsoft that [E]SMTP be extended to identify a submitter, and gladly waive any and all rights, etc. Sadly, their may other earlier claims to the idea of extending [E]SMTP. 3. Attempt to find a non-PRA based approach to verifying the message (SMTP DATA) content. The above does not propose a solution to the problem at hand, but I hope at least lays out the alternatives that may be pursued by implementors/marid. Nick Shelness Independent Technology Consultant From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 06:59: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 GAA29981 for ; Sun, 29 Aug 2004 06: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 i7TAalla045720; Sun, 29 Aug 2004 03:36:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TAal4o045718; Sun, 29 Aug 2004 03:36:47 -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 i7TAalvS045712 for ; Sun, 29 Aug 2004 03:36:47 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i7TAamhX017825 for ; Sun, 29 Aug 2004 03:36:48 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <531C36B3-F9A7-11D8-8AD0-000A95AC5778@isipp.com> Content-Transfer-Encoding: 7bit From: "Anne P. Mitchell, Esq." Subject: Re: Why sublicensing is important Date: Sun, 29 Aug 2004 03:36:45 -0700 To: "IETF-MXCOMP WG'" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> The license states that it can be revoked if the licensee if found in >> material breach of the terms. Microsoft's lawyers get to >> determine that > > No they don't, the phrase material breach has a very narrow legal > definition, it means that the licensee has to fail to keep an > undertaking made. This is inaccurate. In practice it means simply that the alledged breacher has failed to live up to their part of the bargain, and there are any number of ways that they could do that, including simply forgetting to include in both the source code and with a license distribution the Microsoft intellectual property rights language dictated in ss 2.2 of the license. >> and the only way to challenge and resolve that if it happens, >> would be through the courts. > > The only way to breach the terms of the license is to sue Microsoft > which means that you are already in court. That is really really incorrect, although I can understand why one would come to that conclusion. One can be in breach for any number of reasons - always at least as many, and often more, as there are substantive clauses in the contract/license/agreement. Anne From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 10:15:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09989 for ; Sun, 29 Aug 2004 10:15:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TDoMkL082051; Sun, 29 Aug 2004 06:50: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 i7TDoMJ4082050; Sun, 29 Aug 2004 06:50:22 -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 i7TDoIW7082037 for ; Sun, 29 Aug 2004 06:50:21 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i7TDo6Pa004833; Sun, 29 Aug 2004 15:50:06 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i7TDl8EZ031552; Sun, 29 Aug 2004 15:47:08 +0200 From: Hadmut Danisch Date: Sun, 29 Aug 2004 15:47:08 +0200 To: Nick Shelness Cc: ietf-mxcomp@imc.org Subject: Re: Microsoft Claimed IP, License Terms, etc. Message-ID: <20040829134708.GA30677@danisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Aug 29, 2004 at 11:27:21AM +0100, Nick Shelness wrote: > > This disclosure in no way establishes the validity of this claim. This > awaits the issuance of a patent or patents, and the subsequent defense of > this patent or patents. Any individual or organization is free to write to > the patent authorities in any and all jurisdictions claiming that IP that > they believe has been submitted for patent protection is covered by "prior > art" or is "obvious", both of which are grounds for rejection of a patent > application. Thanks for that information. I'm not familiar with the US procedures to do so, so could you (or anyone else) give me details about how to do this (address, formal requirements, costs,etc.). > their may > other earlier claims to the idea of extending [E]SMTP. I do remember that something like this has been discussed earlier, before MS published CallerID. The discussion was (I'm not sure until I've searched my archives, but I think I raised the discusssion) about the fact, that the sender address does not need to have the meaning of a 'sender' or 'submitter' for RMX and RMX-alike proposals. Actually it is just an abstract, meaningless pointer to any domain providing a record covering the sender's IP address. As far as I can remember I have proposed somewhere to just run the message header against a regular expression and use just everything, which looks like an e-mail address to find a domain covering the sending host, and allow the sender to include just any arbitrary header line to include an appropriate e-mail address. Your/Microsoft's proposal is different in the way that it places the 'pointer' in the MAIL FROM:-command instead of the message header. But from my point of view this is far away from reaching the invention depth required for a patent. Even without the discussion I mentioned I'd consider this idea as trivial (once RMX was published), and not sufficient for a patent. And, not to offend you, but to give my honest opinion: Claiming a patent on such a minor and trivial 'invention' is unworthy of any serious software company. Given the fact that Bill Gates was still talking about making e-mails expensive and digital stamps a few months ago, Microsoft must face the question why they didn't invent anything on their own, but need to abuse such trivial 'microinventions' to hijack other people's ideas. Hadmut Danisch From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 10:29:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11081 for ; Sun, 29 Aug 2004 10:29:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TE9PCt084962; Sun, 29 Aug 2004 07:09: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 i7TE9P90084961; Sun, 29 Aug 2004 07:09:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp1g.bellsouth.com (aismtp1g.bellsouth.com [139.76.165.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TE9PXp084944 for ; Sun, 29 Aug 2004 07:09:25 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp1g.bellsouth.com with ESMTP; Sun, 29 Aug 2004 10:09:21 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: In favour of Sender ID X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Sun, 29 Aug 2004 09:09:12 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB9B7D629@bremocog-55> Thread-Topic: In favour of Sender ID Thread-Index: AcSNbS2zIzvUhLHhS5mOodGQBC4srQAYioXg From: "Sauer, Damon" To: "Yakov Shafranovich" , "Paul Iadonisi" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7TE9PXp084956 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Due to our very clear rules concerning obtaining and maintaining licenses on installed software, until terms and our liabilities in the license (current or revised) are made legally crystal clear, as much as I personally would like to deploy, I will be unable to do so. As far as the comments made by Mr.Shelness (btw. Thank you very much for wading in) is there anything that the group can do to correlate dates of published ideas (I am assuming that by emailing this public group it can be a legally protected idea) with IP claims made by MS? Regards, Damon Sauer -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Yakov Shafranovich Sent: Saturday, August 28, 2004 9:02 PM To: Paul Iadonisi Cc: ietf-mxcomp@imc.org Subject: Re: In favour of Sender ID Paul Iadonisi wrote: > On Sat, 2004-08-28 at 14:21, Roy Badami wrote: > >>Even if Sender ID is incompatible with the GPL [2] -- and I'm >>skeptical that it is except under the most extreme interpretations -- > > > And we have yet to see a convincing legal argument (or *any* legal > argument) from an attorney posted to this list. I'd like to know what > Anne Mitchell (on this list) thinks of her legal analysis being called > extreme by a non-lawyer. > The main point here is whether the current IPR issue can delay deployment. The mere fact that several lawyers have stated their expert opinion that this license is incompatible with existing open source licenses, can cause deployment problems. However, it is important to note how people react to their statements. We have already seen several parties including myself stating that they will not implement Sender-ID in their products unless the legal terms are changed, or the legal situtation is clarified. We also saw several parties, including Roy, state that they are willing to implement it even with the current legal situation intact. Therefore, it seems to me that there exists a sizable percentage of the possible market for this standard that will hesistate to deploy Sender-ID. This, we have a deployment problem. Whether the underlying facts that cause it are true, might not be relevant, since we care about what people will do. Yakov ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 10:40:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11708 for ; Sun, 29 Aug 2004 10:40:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TEHBSW085572; Sun, 29 Aug 2004 07:17: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 i7TEHBR8085571; Sun, 29 Aug 2004 07:17:11 -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 i7TEHAeK085565 for ; Sun, 29 Aug 2004 07:17:10 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040829141707.TMDB14082.tomts16-srv.bellnexxia.net@ibmrkydk2ufvdd>; Sun, 29 Aug 2004 10:17:07 -0400 From: "John Glube" To: "'John Levine'" , Subject: RE: Why sublicensing is important Date: Sun, 29 Aug 2004 10:19:03 -0400 Message-ID: <000001c48dd3$23c9cc60$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: <017001c48d34$0c884710$6c62fea9@ibmrkydk2ufvdd> 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 i7TEHBeK085566 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Just for the record, since many people on this list may not know, I do have a law degree (along with an undergraduate degree in economics and mathematics) along with 25 years of experience in providing sophisticated business and legal analysis, including a number of years focused on issues surrounding intellectual property, trade, marketing and regulatory matters. I should have added this to my earlier message in this thread, when I wrote: >I sat down and re-analyzed the patent license and reviewed >the status of Sender-ID for my personal benefit. I regret any inconvenience. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.742 / Virus Database: 495 - Release Date: 19/08/2004 From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 12:14:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16653 for ; Sun, 29 Aug 2004 12:14:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TFqE4T090473; Sun, 29 Aug 2004 08:52: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 i7TFqEKK090472; Sun, 29 Aug 2004 08:52:14 -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 i7TFqDf1090456 for ; Sun, 29 Aug 2004 08:52:13 -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 i7TFqBvu018955 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 29 Aug 2004 08:52:11 -0700 Message-ID: <036501c48de0$29d0d880$3201a8c0@rasta> From: "Harold A'Hole" To: , "Nick Shelness" References: Subject: Re: Microsoft Claimed IP, License Terms, etc. Date: Sun, 29 Aug 2004 08:50:09 -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 Isn't it nice to know that any software we write can be so encumbered and restricted by unknown agents who claim they invented and own some processing logic so you can't use that logic yourself? Patents protect innovation in software so well. Perhaps this shows once again that the IETF would do better to adopt existing protocols that have been field proven before they try to make them into standards. Let the code and process logic be in the public domain for a few years, see how it really works (or doesn't) and let enough time pass to find out if there are any torpedo patents lurking (they should all have been granted or rejected, or at least published after that much time). Harry From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 13:10: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 NAA20522 for ; Sun, 29 Aug 2004 13:10: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 i7TGd3TS093841; Sun, 29 Aug 2004 09:39: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 i7TGd3bF093840; Sun, 29 Aug 2004 09:39:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGd3Aw093833 for ; Sun, 29 Aug 2004 09:39:03 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7TGlnC2025363 for ; Sun, 29 Aug 2004 09:47:49 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7TGlntG025360 for ; Sun, 29 Aug 2004 09:47:49 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 29 Aug 2004 09:47:48 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: Re: Microsoft Claimed IP, License Terms, etc. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 29 Aug 2004, Nick Shelness wrote: > All, > > I don't really want to enter this discussion, but I believe it is > necessary. > > For those that don't know me, I'm the ex-CTO of Lotus (98-01) and thus > someone who professionally had to spend a great deal of time (too much) > worrying about IP issues, and consulting with IP lawyers. I was also the > source of a private suggestion to Harry Katz that [E]SMTP be extended to > identify the email submitter as an alternative to mucking about with RFC > [2]822 headers. At the time, Harry indicated that this idea was new to him > and Microsoft. I leave it to Harry to indicate whether he has subsequently > encountered a prior claim to this idea. It is nice to have confirmation that idea of SUBMITTER did not come from Microsoft. On this I'll note that there are alternatives available to current CallerID system which take major parts from it, including SUBMITTER and authentication of external (independent network-network) connections and establishing party responsible for introduction of processing of email for each such network, but this does not use PRA algorithm and would probably not be bound by Microsoft IPR claims (hard to confirm these things when you dont know what exactly they claim is invented) Since chairs specifically asked not to discuss any alternatives to CallerID until we decide on current set of documents based on last call, I will not be mentioning any details, but if you do like the parts of CallerID approach mentioned above but believe IPR claims and other tech issues are significant that CallerID should not go forward as is, this does not mean the whole approach is necessarily dead and the only options are envelope bounces-to (the so called envelope "mail-from") and EHLO identities and that RFC822 From and what is shown to MUAs can not be protected by MARID design. At the same time, I also believe that protecting just one idenity and designing protocol such that is so specific to just that idenity with no support for scoping and other identities is bad, if we put aside current documents which were done in way too much haste (they leave too many technical issues and errors unresolved and should probably not go forward even if there was not such an IPR controversy) then we may have opportunity to work on more complete approach to authentication of email session with help of DNS records which is what MARID was charted to do. I'm also leaving below some other parts of the email I replied to which are relevent to what I just wrote above. > 2. Limit the scope of marid to the [E]SMTP MAIL FROM: command, with or > without the SUBMITTER parameter. RMX, SPF, etc. which operated on the MAIL > FROM: address almost certainly constitute prior art, and I am the source > of the proposal to Microsoft that [E]SMTP be extended to identify a > submitter, and gladly waive any and all rights, etc. Sadly, their may > other earlier claims to the idea of extending [E]SMTP. > > 3. Attempt to find a non-PRA based approach to verifying the message (SMTP > DATA) content. > > The above does not propose a solution to the problem at hand, but I hope > at least lays out the alternatives that may be pursued by > implementors/marid. > > Nick Shelness > Independent Technology Consultant From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 15: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 PAA00307 for ; Sun, 29 Aug 2004 15: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 i7TIv3PL001653; Sun, 29 Aug 2004 11:57: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 i7TIv3Yn001652; Sun, 29 Aug 2004 11:57: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 i7TIv3Z1001645 for ; Sun, 29 Aug 2004 11:57: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 i7TIuoD28892; Sun, 29 Aug 2004 11:56:50 -0700 Date: Sun, 29 Aug 2004 11:56:47 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <172238056.20040829115647@brandenburg.com> To: "Jim Lyon" CC: "IETF MARID WG" Subject: Re: TECH OMISSION: Stronger checks against email forgery In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAC52@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAC52@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> 3. When the set of documents hits Proposed Standard, many of the JL> legitimate specialized agents won't yet be in compliance. But as a JL> whole, it's a well-managed community that can move fairly quickly. Without commenting on the rest of your proposal, I need to comment that your estimate of adoption time is not matched by any Internet example of the last 15 years. When changing an existing service, adoption that reaches reasonable utility within 3 years is lightening quick, and then it is ANOTHER 2-8 years before it is considered to be an integral part of "all" systems in the service. So if you are going to make a proposal that has any serious dependency on adoption happening quicker than that, it would be very helpful if you could explain what processes well ensure that rapidity. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 15:33:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00831 for ; Sun, 29 Aug 2004 15:33:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJ9ckY002389; Sun, 29 Aug 2004 12:09: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 i7TJ9cHp002388; Sun, 29 Aug 2004 12:09:38 -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 i7TJ9bsP002382 for ; Sun, 29 Aug 2004 12:09:37 -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 i7TJ9aD29615; Sun, 29 Aug 2004 12:09:36 -0700 Date: Sun, 29 Aug 2004 12:09:33 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1158974714.20040829120933@brandenburg.com> To: "Jim Lyon" CC: "John Glube" , "IETF MARID WG" Subject: Re: TECH OMISSION: Stronger checks against email forgery In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF8FAC52@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAC52@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> Reasons against EHLO or bounce address: JL> 1. EHLO tells you a name for the sending MTA. But it gives you no idea JL> whether that MTA is authorized to act on behalf of the name mentioned in JL> the message he's sending. It seems therefore to be irrelevant. Apparently you missed my earlier posting : Channel-based tells us about the aggregate message-sending behavior of a specific MTA. In a world of compromised personal computers, this sort of aggregate assessment can be very helpful for identifying "pipes" that are more or less dangerous. Message-based tells us about a particular author. This is clearly useful against phishing. To be useful against spam, the reputation of each author must be assessed. Note that per-message analysis does not permit the sort of aggregate analysis that lets one determine that an entire ISP's pool of systems is problematic. Note the potential scaling benefits. With HELO-based you do one validation per session, rather than one per message. In some scenarios, that is a huge savings. Even better, note the difference in registering the relatively small number of sending MTA domain names, versus the very large number of message authors. A rather serious problem in these discussion is the implied assumption that any single mechanism must do everything. We need to get away from that, so that we can focus on having individual mechanisms that do individual things that are useful. There is nothing wrong with the fact that Sender-ID does not vet the HELO field. And it should not try to. Sender-ID has a different goal. That's fine. We need multiple mechanisms, each attacking different parts of the problem space. That is what is called a layered defense. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 15:58:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01947 for ; Sun, 29 Aug 2004 15:58:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJY9uL003329; Sun, 29 Aug 2004 12: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 i7TJY97N003328; Sun, 29 Aug 2004 12:34:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJY8iX003322 for ; Sun, 29 Aug 2004 12:34:08 -0700 (PDT) (envelope-from sb0-0659338a17-johnl@iecc.com) Received: (qmail 25141 invoked from network); 29 Aug 2004 19:34:10 -0000 Received: (ofmipd 127.0.0.1); 29 Aug 2004 19:33:48 -0000 Date: 29 Aug 2004 15:34:10 -0400 Message-ID: From: "John R Levine" To: "Roy Badami" Cc: "ietf-mxcomp@imc.org" Subject: Re: Why sublicensing is important In-Reply-To: <16689.4163.809423.451252@giles.gnomon.org.uk> References: <20040828170523.12731.qmail@xuxa.iecc.com> <16689.4163.809423.451252@giles.gnomon.org.uk> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Would it be possible for Microsoft to give some legally binding > guarantee that the Sender ID license will _always_ be available under > the current terms? Would that meet your concerns? The reciprocal license issue hadn't struck me as an important one before, but I see your point. I agree that language promising to offer new licenses on similar terms to anyone designated by current licensees would be about as good as sublicensing, albeit more cumbersome for users. > Would Microsoft be willing to take such a step? Good question. In view of the discussion with OSI's lawyer reported in the article I cited, I'd be surprised if it hadn't come up. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 18:49: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 SAA14178 for ; Sun, 29 Aug 2004 18:49:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TMM9Te012581; Sun, 29 Aug 2004 15:22:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TMM9RI012580; Sun, 29 Aug 2004 15:22:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TMM6mX012546 for ; Sun, 29 Aug 2004 15:22:06 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so83776rnk for ; Sun, 29 Aug 2004 15:22:04 -0700 (PDT) Received: by 10.38.3.57 with SMTP id 57mr670696rnc; Sun, 29 Aug 2004 15:22:04 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Sun, 29 Aug 2004 15:22:04 -0700 (PDT) Message-ID: <94df60cf040829152232ce5533@mail.gmail.com> Date: Sun, 29 Aug 2004 18:22:04 -0400 From: Reply-To: To: John Leslie Subject: Re: Reputation services for SenderID Cc: MXCOMP In-Reply-To: <20040827231531.GI465@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> <20040827231531.GI465@verdi> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 27 Aug 2004 19:15:31 -0400, John Leslie wrote: > ... > We then evaluate the list of IPs authorized by the SPF2 record, > and run them against known IP blacklists; accumulating a score based > on weighting the reputation of those blacklists for spam identified, > false negatives, and false positives. This might usually work, but what do you do about the exists and ptr mechanisms? In general there is no practical and 100% reliable way to produce a list of IP addresses authorized by an SPF2 record. David From owner-ietf-mxcomp@mail.imc.org Sun Aug 29 20:03:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17958 for ; Sun, 29 Aug 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 i7TNYVOl016218; Sun, 29 Aug 2004 16:34: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 i7TNYVT8016217; Sun, 29 Aug 2004 16:34:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TNYVOK016204 for ; Sun, 29 Aug 2004 16:34:31 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so86520rnk for ; Sun, 29 Aug 2004 16:34:22 -0700 (PDT) Received: by 10.38.164.76 with SMTP id m76mr695822rne; Sun, 29 Aug 2004 16:34:22 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Sun, 29 Aug 2004 16:34:22 -0700 (PDT) Message-ID: <94df60cf040829163469ba9429@mail.gmail.com> Date: Sun, 29 Aug 2004 19:34:22 -0400 From: Reply-To: To: MARID Subject: DOC-BUG: permitted use of PRA/submitter address 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 It's hard from the current drafts to figure out when exactly it is appropriate to send mail to the PRA of a received mail message. I'm guessing this is because the authors are relying on previous RFCs for this. However, given that a lot of people are already confused by the distinction between envelope and From: address, there is a danger that the introduction of a third address would lead to an even larger number of broken vacation-type programs. I'd like to suggest that the Sender ID (or maybe the PRA or SUBMITTER) document have somewhere a non-normative paragraph that clues people in to how they can learn about appropriate uses of the PRA. As an example, here are a bunch of questions whose answers are not immediately obvious from reading Sender ID and associated drafts: * Is it ever actually required that the PRA be a valid mailbox? Is it legal to construct some mailbox whose domain has an SPF2 record but not an MX or A record? I presume the answer is no, but that the logic involves some other RFC I'm just not looking at. How would you go about convincing an administrator this is wrong. * I am on vacation, and receive mail which lists my own address in the To: or CC: fields, and does not have any indications such as "Precedence: list/bulk/junk" that it is from a mailing list. I wish for my filter to notify the sender that I will not be responding for a week. Should I send the notification to the MAIL-FROM address, as I currently do, or to the PRA? * I receive mail with an attachment that contains a virus. I wish to configure my MUA or spam filter automatically to notify the sender that his/her machine has a virus and the attachment has been deleted. Should I send mail to the PRA? Can/should that mail come from the empty envelope sender, or should/must it come from my real email address? * I have been erroneously subscribed to a mailing list. Should I complain directly to the PRA? Should I attempt to form a new address by appending "-owner" or "-request" to the local part of the PRA? Or should I complain to an address based on the envelope sender, as I currently would. * I receive offensive and/or threatening mail from someone, and wish to complain to their administrator. Should I complain to postmaster/abuse at the domain name in the PRA, as opposed to the domain in the From or envelope sender address? * In order to reduce spam, I currently perform an SMTP callback on the envelope sender of mail, ensuring that any mail I accept could have been bounced. (This is highly effective against spam from virus-infected machines, because many machines infected by viruses can make outgoing TCP connections but not accept incoming ones, and thus are forced to use other people's often invalid envelope senders.) In case of forgery, people can block these callbacks by using SPFv1 records. Once we have Sender ID, should I instead perform SMTP callbacks to validate the SUBMITTER or PRA address rather than MAIL-FROM, so as to avoid wasting bandwidth of sites whose addresses are being forged? David From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 02:32: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 CAA24729 for ; Mon, 30 Aug 2004 02:32: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 i7U61agi057153; Sun, 29 Aug 2004 23:01:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7U61ato057152; Sun, 29 Aug 2004 23:01:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7U61Zrk057141 for ; Sun, 29 Aug 2004 23:01:35 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [206.223.20.210] (24.152.199.18.res-cmts.eph.ptd.net[24.152.199.18]) by comcast.net (rwcrmhc13) with ESMTP id <2004083006013701500lhmuqe> (Authid: dhlii); Mon, 30 Aug 2004 06:01:38 +0000 Message-ID: <4132C2D0.20102@comcast.net> Date: Sun, 29 Aug 2004 23:01:52 -0700 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: Microsoft Claimed IP, License Terms, etc. References: <20040829134708.GA30677@danisch.de> In-Reply-To: <20040829134708.GA30677@danisch.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hadmut Danisch wrote: > >Claiming a patent on such a minor and trivial 'invention' is unworthy >of any serious software company. Given the fact that Bill Gates was >still talking about making e-mails expensive and digital stamps a few >months ago, Microsoft must face the question why they didn't invent >anything on their own, but need to abuse such trivial >'microinventions' to hijack other people's ideas. > > > I was about to ask regarding that too. I thought that there was a set of requirements to determine if something was patentable. Something to the efect that it has to be implimentable - You are not supposed to be able to patent ideas only implimentations of them, the fact that software is so close to the pure expression of the underlying idea is one of the strong arguments against software patents. I think some of the other requirements are no published prior art, uniqueness, novelty, usefullness, and non-obviousness. I think Hadmut's reference to this being a trivial micro-invention, is approximately equivalent to saying that it is obvious. I am also not sure how verifying the PRA actually even constitutes an invention much less a patentable one. But if Microsoft is filing 20,000 patent applications a year I would imagine that an awful lot of them have to be pretty trivial. Software patents are an evil aspect of life that has to be dealt with atleast until it becomes more obvious that they have failed - not in the theoretical sense of being a bad idea but in the practical sense of having become totally unworkable. There are not things I will give Microsoft the benefit of the doubt on. But my guess is their massive patent portfolio effort is more deffensive than offensive. I do beleive they are capable of using IP to try and disadvantage FOSS. As evil as that sounds it is also legitimate. The purpose of patents is to prevent the competition from capitolizing on your invention. To Microsoft FOSS is the competition. But for the most part Microsoft's IP record has been mostly defensive and not offensive. Further, trying to actively use IP to disadvantage FOSS is a dangerous and counterproductive step. The FOSS community may or may not have deep pocket litigation resources depending on the particular issue. But the prior art research resources available to FOSS are enormous. Someone somewhere at some time must have atleast discussed some form of verification of Sender addresses in a public mail list or newsgroup. From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 02: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 CAA25461 for ; Mon, 30 Aug 2004 02: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 i7U6Oge4060813; Sun, 29 Aug 2004 23:24: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 i7U6OgqS060812; Sun, 29 Aug 2004 23:24:42 -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 i7U6Of0I060797 for ; Sun, 29 Aug 2004 23:24:42 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040830062436.OVCG4758.tomts13-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 30 Aug 2004 02:24:36 -0400 From: "John Glube" To: "'John R Levine'" , "'Roy Badami'" Cc: Subject: RE: Why sublicensing is important Date: Mon, 30 Aug 2004 02:26:30 -0400 Message-ID: <000001c48e5a$4b6fde80$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 i7U6Og0I060806 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit John and Roy, Just a couple of follow up points to your discussion. In an earlier post on this topic, I referenced Anne's note. After going through the FAQ and draft license a few more times, my own analysis pointed to a number of technical concerns. These are more than just the sub-licensing issue. These include: * MS wants to limit the patent license grant to that intellectual property which is necessary to allow the Licensee to only implement the Sender ID Specification, presuming there is no other technically reasonable alternative available. In my view the proposed limitations are overly restrictive, unduly favouring the competitive interests of MS. MS needs to give more thought to properly balancing the underlying interests. In this case, we are dealing with email, part of the Internet's very fabric. There has been some discussion about the financial and market power of MS. To avoid any concern, MS could consider going beyond even IBM's stance and donating its IPR, along with any future IPR involving Sender ID to the MS trust, with the appropriate beneficiaries for a trust of this nature, the trustees being nominated by MS, the trust protector being Bill Gates. The MS Trust would have the purpose of furthering the continuous development of Sender ID. Under the trust terms, anyone who wishes to implement Sender ID including MS could apply to the trust for a royalty free patent license upon reasonable terms (licensee to take on an "as is where is" basis, waiving any right to sue the trust for damages). The key proviso? The applicant would have to grant its existing IPR or any future IPR involving Sender ID to this trust. MS in turn could guarantee the trust's ability to perform its functions, including defending any countervailing patent claims made against the trust and enforcing licensees obligations under any patent license as granted. (Needless to say, much thought would have to go into refining this concept.) All I am saying is that at present the patent license does not strike the proper balance. I add this is an extremely complex area, especially with the international implications. * MS, being an American corporation is subject to US export law. The license contains a clause which reflects the need to comply with any applicable export restrictions. Firms outside the US may well sign the license. With the reciprocal patent grant, the clause reflects the need to comply with any applicable foreign export restrictions. We require clarification as to whether there are any existing US restrictions which prohibit export of the IPR, including the need for export permits. Will MS undertake to take the necessary steps to obtain and keep in force any required export permits However, there is an underlying issue. The US is a leader in developing new technologies. As a result, the US has very sophisticated and complex laws regulating exports with extraterrorial application. The US, imposes export restrictions on its technology for a variety of social, political and strategic reasons. Members of Congress and the President in their respective roles as elected representatives of the American people pass the needed laws to safeguard US national interests. The IETF and related bodies is a standards organization for the Internet, which is world wide. Even if Sender ID were granted RFC status tomorrow, world wide implementation will take time. Email is a crucial part of the Internet. Though there may not be any applicable restrictions today, the US for very valid strategic reasons necessary to protect American national interests may at some future time decide to impose restrictions on the export of technology which could aid another nation state in fighting the spam scourge, including the use of the Sender-ID technology or any derivative and collaborative works. MS can't guarantee such a restriction could not happen and it would be wrong to ask for this kind of guarantee. This possibility is not as far fetched as it may seem. In saying this I appreciate there are a myriad of treaties which impose various restraints on what nation states can do. This issue simply highlights the problem of properly dealing with the potential clashes between national interests and world wide implementation of an Internet standard dealing with email. * Applicable law Typically in contracts between parties of equal bargaining strength a jurisdiction is chosen which is mutually acceptable to both parties. Personally, I would prefer English law, with the venue being the Court of Queen's Bench in London, England, no right to a jury trial, the parties having the right to agree on binding mediation. However, the likelihood of this happening is slim to none, so let me suggest New York State law and US law, the venue being the US District Court of Southern Manhattan, no right to a jury trial, the parties having the right to agree on binding mediation. I simply outline these points, so that folks appreciate, oh if we just get MS to deal with the sublicensing issue as Roy has proposed, all is fine. Also, based on technical comments, it seems Sender ID is a solution put forward in response to certain design criteria of various large financial institutions who are confronted with a real and immediate problem. This problem apparently affects: * their continued ability to rely on email for transactional purposes; and, * their customers ability to trust email from financial institutions, given the level of financial loses being suffered. Unfortunately, this pressing need also highlights the rational for only granting experimental protocol status to a standard which has global application. Why? There are fundamental technical disagreements concerning Sender-ID's role which remain unresolved. The biggest one. Whether a proposal like Sender-ID is only one part of a multi-layered defence which includes various approaches to sender authentication , or should we treat Sender ID as the only viable framework for sender authentication. Unfortunately, this lack of consensus highlights the difficulty in granting Sender-ID anything more than experimental status without first completing a full scale operational and security review by graybeards and conducting wide scale tests. This analysis also points to how difficult it is for any IETF WG to get involved in detailed analysis of any proposed patent license. This is why the guidelines contained in the RFC's dealing with how to treat IPR claims have great merit. In putting forward this analysis, I reiterate although I do have a law degree and significant experience in legal and business analysis, I am not a lawyer. This comment is merely for information purposes only. John John Glube Toronto, Canada The FTC Calls For Sender Authentication http://www.learnsteps4profit.com/dne.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.742 / Virus Database: 495 - Release Date: 19/08/2004 From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 03:14:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26740 for ; Mon, 30 Aug 2004 03:14:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7U6mS0F065510; Sun, 29 Aug 2004 23:48: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 i7U6mSpp065509; Sun, 29 Aug 2004 23:48:28 -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 i7U6mR2k065501 for ; Sun, 29 Aug 2004 23:48:27 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.38.106]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040830064826.LOCZ29920.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Mon, 30 Aug 2004 02:48:26 -0400 From: "John Glube" To: "'John R Levine'" , "'Roy Badami'" Cc: Subject: RE: Why sublicensing is important Date: Mon, 30 Aug 2004 02:50:21 -0400 Message-ID: <000001c48e5d$9ea34760$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 i7U6mS2k065504 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Two additional comments: * The use of a trust (or the IBM form of patent license) would also establish a precedent for how to deal with DomainKeys. * The counter argument to any perceived concerns about application of US export law is simple. The US is a pluralistic democracy, with an enshrined bill of rights and has been said before a democracy is the worst system of governance, except for all the others. John Glube Toronto, Canada --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.742 / Virus Database: 495 - Release Date: 19/08/2004 From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 03:22: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 DAA27092 for ; Mon, 30 Aug 2004 03:22: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 i7U70xBq067791; Mon, 30 Aug 2004 00:00: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 i7U70x0P067790; Mon, 30 Aug 2004 00:00:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp1g.bellsouth.com (aismtp1g.bellsouth.com [139.76.165.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7U70wTH067761 for ; Mon, 30 Aug 2004 00:00:59 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp1g.bellsouth.com with ESMTP; Mon, 30 Aug 2004 03:00:49 -0400 Importance: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Why sublicensing is important X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Mon, 30 Aug 2004 02:00:49 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB9B7D63E@bremocog-55> Thread-Topic: Why sublicensing is important Thread-Index: AcSOXabfc+HE6X3PTO+1B6OtByGeswAASrpw From: "Sauer, Damon" To: "John Glube" , "John R Levine" , "Roy Badami" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7U70xTH067784 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 John Glube > Sent: Monday, August 30, 2004 1:50 AM > To: 'John R Levine'; 'Roy Badami' > Cc: ietf-mxcomp@imc.org > Subject: RE: Why sublicensing is important > The US is a pluralistic democracy, with an enshrined bill > of rights and has been said before a democracy is the worst > system of governance, except for all the others. Thank God! > > John Glube > Toronto, Canada > > Regards, Damon Sauer ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 03:54: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 DAA29402 for ; Mon, 30 Aug 2004 03:54: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 i7U7PxT3073107; Mon, 30 Aug 2004 00:25: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 i7U7PxgP073106; Mon, 30 Aug 2004 00:25:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7U7Pwt8073066 for ; Mon, 30 Aug 2004 00:25:58 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1C1gY3-000NvP-00 for ietf-mxcomp@imc.org; Mon, 30 Aug 2004 08:25:51 +0100 Message-ID: <184001c48e62$32e93520$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: TECH-OMISSION: Security vulnerability - Malicious DSN attacks Date: Mon, 30 Aug 2004 08:23:03 +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 In draft-ietf-core-03.txt section 6 (Security Considerations) add a new section... vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv 6.5 Malicious DSN attacks on third-parties There is class of attacks in which an attacker A can entice a participant P to send a malicious message to a victim V. These attacks are undertaken by A citing the address of V in the SMTP Mail-From request and then by causing P to generate (or invoke the generation of) a Delivery Status Notification 'bounce' message (RFC3464), which is sent to the victim V. The attacker relies upon it being common practice to copy the original message into the 'bounce' report, thereby causing the malice to be sent onwards to V. This mode of attack has the advantages (to the attacker) - of obfuscating the location of the host from which the attack was mounted - of possibly damaging the reputation of P by making it appear that P originated, or was an active participant in, the sending of the malicious message. In current practice, A causes P to invoke the 'bounce' by addressing the original message to a non-existent recipient. Sender-ID enables a new variant of this attack. In this variant the attacker A sends a message whose PRA (section 4) is selected by the attacker to be such that, when P undertakes the Sender-ID test, a 'Fail' will result (section 5.3). The message will be rejected (as the attacker intended) and a malicious 'bounce' message may be generated and sent to the victim V. ^^^^^^^^^^^^^^^^^^^^^^^^ ... and add a new Normative reference to RFC3464 in section 10.1 ============================ Rationale for new section This new mode of attack has been discussed extensively in the thread "DEPLOY: Legal liability for creating bounces from forged messages", and has been mentioned in others. It has been accepted by proponents of Sender-ID that this mode of attack can occur; the debate has been about whether or not Sender-ID or should provide any defence against this attack. The extant draft contains no such defence, hence the need to declare this security vulnerability within the draft. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 04:45:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02259 for ; Mon, 30 Aug 2004 04:45: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 i7U8EASk080117; Mon, 30 Aug 2004 01:14: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 i7U8EAAQ080116; Mon, 30 Aug 2004 01:14:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7U8EAM8080110 for ; Mon, 30 Aug 2004 01:14:10 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1C1hIi-000AXh-00; Mon, 30 Aug 2004 09:14:04 +0100 Message-ID: <184c01c48e68$ef817c00$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Cc: "John Levine" , "Meng Weng Wong" References: <20040828170523.12731.qmail@xuxa.iecc.com> Subject: Re: Why sublicensing is important Date: Mon, 30 Aug 2004 09:11:21 +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 "John Levine" opined: >... the least bad option seems to me to be to > move both Sender ID and SPF ahead as experimental standards. They're > both experimental because we still have only the sketchiest experience > with day to day usage of both, and we don't know about server loads, > DNS loads, likely spammer counterattacks, or anything else > operational. People who are so inclined can easily implement both, > particularly if they use the same DNS records. This proposal has within it the opprtunity to ameliorate the concerns over Sender-ID's lack of defense against the Sender-ID-specific mode of 'bounce-bomb' attack - documented this morning in "TECH-OMISSION: Security vulnerability - Malicious DSN attacks". For an experimental phase the concerns could be reduced by: 1) Releasing Sender-ID at the same time as, or after, SPF 2) Recommending, either in Sender-ID or in an accompanying BCP that: "In the event of a Sender-ID test result of 'Fail', an SPF test of the Mail-From address SHOULD be undertaken. If that SPF test should also 'Fail' the message SHOULD be silently discarded." draft-zinn-smtp-bounces-01.txt may be cited as 'proto-authority' for the discard. If this approach were to prove successful, I would recommend that the SHOULDs above be changed to MUSTs in a post-experimental phase. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 06:30:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09158 for ; Mon, 30 Aug 2004 06:30:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7U9wGGQ097438; Mon, 30 Aug 2004 02: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 i7U9wGoY097437; Mon, 30 Aug 2004 02:58:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7U9wFA0097419 for ; Mon, 30 Aug 2004 02:58:16 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1C1ivX-000F10-00; Mon, 30 Aug 2004 10:58:15 +0100 Message-ID: <188c01c48e77$7d768bf0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Cc: "Andrew Newton" References: <111001c48be5$ebaa1360$0200000a@ringo> Subject: Re: TECH-OMISSION: Divergent assumptions about objectives Date: Mon, 30 Aug 2004 10:55:32 +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 The co-chair, Andrew Newton, asked > > On Aug 26, 2004, at 11:28 PM, Chris Haynes wrote: > > > I have classed this as a TECH-OMISSION because its a case of inserting/ > > modifying a requirement so that it matches the actual functionality > > being > > specified; it closes a requirement-functionality gap which is what I > > interpret > > the spirit of TECH-OMISSION to be. > > Can you need to be more explicit about the change you desire? This > helps with readability and tracking of the issues. > > -andy > ============================= Please find below proposed changes to draft-ietf-marid-core-03.txt, which embody my proposed changes. It will be recalled that I proposing to meet the TECH-OMISSION objectives by re-writing the requirements of Sender-ID to match the reality of the functionality specified. This is also intended to make much more clear the positioning and capabilities of Sender-ID among the battery of anti-spam, anti-virus and anti-phishing techniques under consideration. I have just drafted here the Abstract and Introduction to the '-core' document. If these changes were accepted, there are doubtless many other parts of the Sender-ID drafts which could benefit from a corresponding revision and clarification. ================ Replace the existing Abstract with... vvvvvvvvvvvvvvvvvvvvvvvvvvv Abstract Internet mail is vulnerable to a specific form of deception, known colloquially as 'Phishing'. In a Phishing attack a message contains an unauthorised 'From:' address, thereby purporting to come from a legitimate authority, such as a bank. The message content often attempts to perpetrate a fraud on the recipient. This specification defines a mechanism by which a bona-fide sender of a message can assure the recipient that the host offering the message from transmission is authorised to do so by the domain purporting to send the message. ^^^^^^^^^^^^^^^^^^^^^ =================== Replace the entire Introduction with... vvvvvvvvvvvvvvvvvvvvvvvvvvv 1. Introduction Today, a huge majority of unwanted email contains headers that lie about the origin of the mail. This is true of most spam and substantially all of the virus email that is sent. One particular form of lying involves forging the RFC 2821 'From:' header, so that the recipient ascribes to the message an authority which it does not actually have. Such messages are frequently used to attempt to perpetrate a fraud on the recipient. Bona fide senders have no way of assuring recipients that messages purporting to be from them are, indeed from them. A potential solution, which is compatible with current SMTP practice, would be to be to provide some means for MUAs to authenticate the address purporting to be responsible for the message, and to display some clear visual indication of authenticity (akin to the HTTPS closed padlock symbol) alongside the domain which has been found to be responsible for the message. This specification contributes to such a solution by defining a mechanism for message authorisation, and recommends that authorisation failures be notified to the RFC 2821 message sender through the DSN 'bounce' mechanism. In this mechanism bona fide senders use DNS to publish rules which confirm that a host (identified by IP address) is authorised to send messages purporting to originate from that domain. The recipient of a message from that host can determine the Purported Responsible Address of the message, obtain the rules published by the domain of that address, and thereby assure itself that the message was authorised by its purported originator. The way that assurance is communicated to an MUA and displayed to its user is not the subject of this specification. To provide compatibility with the overwhelming majority of legitimate remailers and mailing list operators the test of the 'From: address is modified to use the Purported Responsible Address, determined algorithmically from the 'From:', 'Sender:', 'Resent-From: and 'Resent-Sender:' message headers. Where the PRA is not the 'From:' address, any MUA display mechanism SHOULD display the domain of the PRA, as well as the 'From:' address, and MUST NOT indicate that the 'From' address has been assured. ^^^^^^^^^^^^^^^^^^^^^^^^^ Chris Haynes From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 10:52: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 KAA29569 for ; Mon, 30 Aug 2004 10:52:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UEMcis038005; Mon, 30 Aug 2004 07:22: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 i7UEMcjm038004; Mon, 30 Aug 2004 07:22:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UEMb08037987 for ; Mon, 30 Aug 2004 07:22:37 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48E9C.CB75C6EE" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: More on Exim, GPL and the IPR license Date: Mon, 30 Aug 2004 10:22:35 -0400 Message-ID: <14DDECDDC9218248B52FF951E5A9A9B611076B@exch-prod.hepcoe.com> Thread-Topic: More on Exim, GPL and the IPR license Thread-Index: AcSOnMuNCuLpQRiSRpKpTeV4xJGn9Q== From: "Peuhkurinen, Kevin" To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C48E9C.CB75C6EE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I hate to keep harping on this, but I really do believe that it is = important. I solicited the opinion of Dr. Philip Hazel of Cambridge = University who as you probably know is the principal author of Exim. I = asked him if he would consider releasing Exim under a difference license = other than the GPL if doing so would allow Sender-ID code to be included = in it. His response was: "The short answer is "No".=20 I have no desire to change Exim's licence, and certainly not as a result = from pressure of Microsoft's lawyers. Furthermore, some of the other postings I've seen have said that developers using this "free" licence must register with Microsoft. That is completely unacceptable." I believe that Dr. Hazel's response demonstrates two things. The first = is that one of the most popular MTAs in use will not be able to include = Sender-ID code. The second is that a very well respected open source = developer sees the IPR license terms as "completely unacceptable". Kevin ------_=_NextPart_001_01C48E9C.CB75C6EE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable More on Exim, GPL and the IPR license

I hate to keep harping on this, but I = really do believe that it is important.   I solicited the = opinion of Dr. Philip Hazel of Cambridge University who as you probably = know is the principal author of Exim.   I asked him if he = would consider releasing Exim under a difference license other than the = GPL if doing so would allow Sender-ID code to be included in = it.   His response was:

"The short answer is "No".

I have no desire to change = Exim's licence, and certainly not as a result
from pressure of Microsoft's = lawyers. Furthermore, some of the other
postings I've seen have said = that developers using this "free" licence
must register with Microsoft. = That is completely unacceptable."

I believe that Dr. Hazel's response = demonstrates two things.   The first is that one of the most = popular MTAs in use will not be able to include Sender-ID = code.   The second is that a very well respected open source = developer sees the IPR license terms as "completely = unacceptable".

Kevin

------_=_NextPart_001_01C48E9C.CB75C6EE-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 12:37: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 MAA06670 for ; Mon, 30 Aug 2004 12:37: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 i7UG2ZFe055790; Mon, 30 Aug 2004 09:02: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 i7UG2Zlw055789; Mon, 30 Aug 2004 09:02:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UG2Y0l055782 for ; Mon, 30 Aug 2004 09:02:34 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7UG2ZMO014312; Mon, 30 Aug 2004 09:02:36 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 30 Aug 2004 09:02:35 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Peuhkurinen, Kevin'" , ietf-mxcomp@imc.org Subject: RE: More on Exim, GPL and the IPR license Date: Mon, 30 Aug 2004 09:02:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48EAA.C329C5EB" 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_01C48EAA.C329C5EB Content-Type: text/plain; charset="iso-8859-1" T here is a rule in the House of Commons that whenever a document is referred to the entirety of the document must be lodged in the house library, rather than just the portions that are quoted. What was the letter sent to Dr Hazel? What are the grounds on which his statement is based? What is the context of the excerpt? It seems somewhat strange that Dr Hazel would take this position when he has in the past taken a much more open approach to licensing: Written by: Philip Hazel < address@bogus.example.com> University of Cambridge Computing Service, Cambridge, England. Phone: Copyright (c) 1997-2000 University of Cambridge Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions: 1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 2. The origin of this software must not be misrepresented, either by explicit claim or by omission. In practice, this means that if you use PCRE in software which you distribute to others, commercially or otherwise, you must put a sentence like this Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. somewhere reasonably visible in your documentation and in any relevant files or online help data or similar. A reference to the ftp site for the source, that is, to ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ should also be given in the documentation. 3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. 4. If PCRE is embedded in any software that is released under the GNU General Purpose Licence (GPL), then the terms of that licence shall supersede any condition above with which it is incompatible. I hate to keep harping on this, but I really do believe that it is important. I solicited the opinion of Dr. Philip Hazel of Cambridge University who as you probably know is the principal author of Exim. I asked him if he would consider releasing Exim under a difference license other than the GPL if doing so would allow Sender-ID code to be included in it. His response was: "The short answer is "No". I have no desire to change Exim's licence, and certainly not as a result from pressure of Microsoft's lawyers. Furthermore, some of the other postings I've seen have said that developers using this "free" licence must register with Microsoft. That is completely unacceptable." I believe that Dr. Hazel's response demonstrates two things. The first is that one of the most popular MTAs in use will not be able to include Sender-ID code. The second is that a very well respected open source developer sees the IPR license terms as "completely unacceptable". Kevin ------_=_NextPart_001_01C48EAA.C329C5EB Content-Type: text/html; charset="iso-8859-1" More on Exim, GPL and the IPR license
T here is a rule in the House of Commons that whenever a document is referred to the entirety of the document must be lodged in the house library, rather than just the portions that are quoted.
 
What was the letter sent to Dr Hazel? What are the grounds on which his statement is based? What is the context of the excerpt?
 
It seems somewhat strange that Dr Hazel would take this position when he has in the past taken a much more open approach to licensing:
 
 
Written by: Philip Hazel <address@bogus.example.com>

University of Cambridge Computing Service,
Cambridge, England. Phone:  <redacted> 

Copyright (c) 1997-2000 University of Cambridge

Permission is granted to anyone to use this software for any purpose on any
computer system, and to redistribute it freely, subject to the following
restrictions:

1. This software is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

2. The origin of this software must not be misrepresented, either by
   explicit claim or by omission. In practice, this means that if you use
   PCRE in software which you distribute to others, commercially or
   otherwise, you must put a sentence like this

     Regular expression support is provided by the PCRE library package,
     which is open source software, written by Philip Hazel, and copyright
     by the University of Cambridge, England.

   somewhere reasonably visible in your documentation and in any relevant
   files or online help data or similar. A reference to the ftp site for
   the source, that is, to

     ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

   should also be given in the documentation.

3. Altered versions must be plainly marked as such, and must not be
   misrepresented as being the original software.

4. If PCRE is embedded in any software that is released under the GNU
   General Purpose Licence (GPL), then the terms of that licence shall
   supersede any condition above with which it is incompatible.


I hate to keep harping on this, but I really do believe that it is important.   I solicited the opinion of Dr. Philip Hazel of Cambridge University who as you probably know is the principal author of Exim.   I asked him if he would consider releasing Exim under a difference license other than the GPL if doing so would allow Sender-ID code to be included in it.   His response was:

"The short answer is "No".

I have no desire to change Exim's licence, and certainly not as a result
from pressure of Microsoft's lawyers. Furthermore, some of the other
postings I've seen have said that developers using this "free" licence
must register with Microsoft. That is completely unacceptable."

I believe that Dr. Hazel's response demonstrates two things.   The first is that one of the most popular MTAs in use will not be able to include Sender-ID code.   The second is that a very well respected open source developer sees the IPR license terms as "completely unacceptable".

Kevin

------_=_NextPart_001_01C48EAA.C329C5EB-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 12:43: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 MAA07301 for ; Mon, 30 Aug 2004 12:43: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 i7UGFZvS057911; Mon, 30 Aug 2004 09:15: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 i7UGFZqq057910; Mon, 30 Aug 2004 09:15:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from draco.cus.cam.ac.uk (cusexim@draco.cus.cam.ac.uk [131.111.8.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UGFXSK057898 for ; Mon, 30 Aug 2004 09:15:34 -0700 (PDT) (envelope-from ph10@cus.cam.ac.uk) Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.42) id 1C1oog-0000Gq-3K for ietf-mxcomp@imc.org; Mon, 30 Aug 2004 17:15:34 +0100 Date: Mon, 30 Aug 2004 17:15:34 +0100 (BST) From: Philip Hazel To: ietf-mxcomp@imc.org Subject: [DEPLOY] Exim and Sender-id In-Reply-To: <11c301c48e04$bde0b490$0a46a8c0@pbdesktop> Message-ID: References: <11c301c48e04$bde0b490$0a46a8c0@pbdesktop> 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: As the author of Exim, I have been asked to post to this list on this subject (I am not subscribed to this list; if you want me to see any response, please cc me). I have been told that > On Fri, Aug 27, 2004 at 08:01:16PM -0400, Sam Varshavchik wrote: > > It will not be possible for me to implement Sender ID in Courier. Courier > > is licensed under the GPL. The FSF already flatly stated that Microsoft's > > IP license is not GPL compatible. I reviewed the most recent version of > > Microsoft's proposed IP license, and I've reached the same conclusion. For > > this reason Sender ID cannot be implemented in Courier; Courier's > > implementation will be limited to the unencumbered SPF-classic. I have not reviewed the proposed licence, but I am prepared to take the word of the FSF, Sam, and others who have reached the same conclusion. Exim is licenced under the GPL. As the proposed Microsoft IP licence is not GPL compatible, Sender ID cannot be implemented in Exim. Unemcumbered SPF-classic functionality has, I am told, already been made to work in Exim by appropriate configuration settings. Philip -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 12:44: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 MAA07468 for ; Mon, 30 Aug 2004 12:44: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 i7UGLZQp058840; Mon, 30 Aug 2004 09:21:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UGLZvA058839; Mon, 30 Aug 2004 09:21:35 -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 i7UGLZe7058831 for ; Mon, 30 Aug 2004 09:21: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; Mon, 30 Aug 2004 12:21:35 -0400 id 0015FA75.4133540F.00006278 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: Re: DEPLOY: SPF/Sender ID support in Courier. Date: Mon, 30 Aug 2004 12:21:32 -0400 To: Sam Varshavchik X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 8:01 PM, Sam Varshavchik wrote: > Microsoft has made certain patent claims on the Sender-ID > specification. Microsoft has issued the IPR disclosures and royalty > free license required by the IETF. The IETF does not require a royalty free license. > It appears that IETF's contemporary policies do not prevent the > sponsor/advocates from including patented IP material into > standards-track specifications, without even requiring the sponsor to > actually enumerate and identify their intellectual property; a mere > claim of the existence of some nebulous IP rights is sufficient, which > can be revealed at any point in the future, at the sponsor's > discretion. I'm not sure what point you are trying to make here. > It will not be possible for me to implement Sender ID in Courier. > Courier is licensed under the GPL. The FSF already flatly stated that > Microsoft's IP license is not GPL compatible. I reviewed the most > recent version of Microsoft's proposed IP license, and I've reached > the same conclusion. For this reason Sender ID cannot be implemented > in Courier; Courier's implementation will be limited to the > unencumbered SPF-classic. A couple of questions: 1) How do you base your decision on incompatibility? I ask this because Courier uses OpenSSL and ships with a file called COPYING which states: > This software is released under the GPL, version 2 (see COPYING.GPL). > Additionally, compiling, linking, and/or using the OpenSSL toolkit in > conjunction with this software is allowed. According to the FSF, the OpenSSL license is also incompatible with the GPL. Additionally, is the webmail part of Courier licensed in a different way? Would there be issues using it with Apache since the FSF also considers the Apache license to be incompatible with the GPL? 2) Based on my limited understanding of Courier, it seems that the only document in the Sender ID docset that needs to be implemented directly into Courier is the SUBMITTER ESMTP extension. The encumbered portions of Sender ID, -core and -pra, could easily be implemented in a separate module using the courierfilter interface. Are you unwilling to incorporate the unencumbered SUBMITTER even if a core/pra courierfilter were available? 3) If somebody were to patch Courier with Sender ID and distribute it with such modifications, would you take legal action against them? 4) You have stated above that you believe Microsoft's claim is "nebulous" with regard to rights being claimed. Your release notes state "Implemented Sender Policy Framework checking on the From: header. Be sure to read the documentation and understand the implication." Since checking of the From: header is listed in the -pra document, are you concluding that this is not encumbered by Microsoft's claim? If so, how did you come to this conclusion? -andy From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 12:59: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 MAA08501 for ; Mon, 30 Aug 2004 12:59:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UGVpxt060020; Mon, 30 Aug 2004 09:31: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 i7UGVpox060019; Mon, 30 Aug 2004 09:31:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exch-prod.hepcoe.com (ns1.hepcoe.com [209.202.101.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UGVoU5060010 for ; Mon, 30 Aug 2004 09:31:50 -0700 (PDT) (envelope-from Kevin.Peuhkurinen@HEPCOE.com) Received: from hepcoe.com ([10.1.254.32]) by exch-prod.hepcoe.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 12:31:53 -0400 Message-ID: <41335679.50608@hepcoe.com> Date: Mon, 30 Aug 2004 12:31:53 -0400 From: Kevin Peuhkurinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: ietf-mxcomp@imc.org Subject: Re: More on Exim, GPL and the IPR license References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2004 16:31:53.0131 (UTC) FILETIME=[DB809FB0:01C48EAE] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Before I get to the quoting, I'd like to point out that I don't see the PCRE license as being a "more open approach" except in that he allows the GPL to supersede his own license. Now, notwithstanding that this is not the House of Commons, here is my email to Dr. Hazel: /-------------------- Hello Philip. I am writing you this email because at this moment the IETF is debating whether or not to accept Sender-ID as an Internet standard. Unfortunately, Sender-ID is encumbered by a "Royalty Free Patent License" from Microsoft which Eben Moglen of the FSF has declared incompatible with the GPL. It therefore appears that Sender-ID code could not be included in GPL'ed software such as Exim. Since Exim has a significant MTA market share, I think it is important that we consider this issue. I would therefore like to ask you one question: if the IETF accepts Sender-ID as is, would you -- and indeed could you -- release Exim under a different license other than the GPL which may be more compatible with Microsoft's patent license in order to allow Sender-ID to be built into Exim? Please note that any answer you give me will be passed on to the public IETF forum. Thanks very much for your time. I appreciate it. / ------------------------ Here is his reply, which quotes my email: ------------------------- /On Fri, 27 Aug 2004, Kevin Peuhkurinen wrote: / >/> Hello Philip. I am writing you this email because at this moment the IETF is >> debating whether or not to accept Sender-ID as an Internet standard. >> Unfortunately, Sender-ID is encumbered by a "Royalty Free Patent License" from >> Microsoft which Eben Moglen of the FSF has declared incompatible with the GPL. >> It therefore appears that Sender-ID code could not be included in GPL'ed >> software such as Exim. Since Exim has a significant MTA market share, I >> think it is important that we consider this issue. >/ > / Indeed. I have received several emails on this topic, and there are also some on the exim-users mailing list. / >/> I would therefore like to ask you one question: if the IETF accepts Sender-ID >> as is, would you -- and indeed could you -- release Exim under a different >> license other than the GPL which may be more compatible with Microsoft's >> patent license in order to allow Sender-ID to be built into Exim? >/ > / The short answer is "No". I have no desire to change Exim's licence, and certainly not as a result from pressure of Microsoft's lawyers. Furthermore, some of the other postings I've seen have said that developers using this "free" licence must register with Microsoft. That is completely unacceptable. Personally, I don't like the SPF/Sender_ID idea because it breaks automatic email redirection. However, people have already configured Exim to support SPF, without any code changes, though I do not know the details (or how SPF differs from Sender-ID). / >/> Please note that any answer you give me will be passed on to the >> public IETF forum. >/ > / I have no problem with that. Regards, Philip/ ------------------------- Hallam-Baker, Phillip wrote: > T here is a rule in the House of Commons that whenever a document is > referred to the entirety of the document must be lodged in the house > library, rather than just the portions that are quoted. > > What was the letter sent to Dr Hazel? What are the grounds on > which his statement is based? What is the context of the excerpt? > > It seems somewhat strange that Dr Hazel would take this position when > he has in the past taken a much more open approach to licensing: > > > Written by: Philip Hazel > > > University of Cambridge Computing Service, > Cambridge, England. Phone: > > Copyright (c) 1997-2000 University of Cambridge > > Permission is granted to anyone to use this software for any purpose > on any > computer system, and to redistribute it freely, subject to the following > restrictions: > > 1. This software is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > 2. The origin of this software must not be misrepresented, either by > explicit claim or by omission. In practice, this means that if you use > PCRE in software which you distribute to others, commercially or > otherwise, you must put a sentence like this > > Regular expression support is provided by the PCRE library package, > which is open source software, written by Philip Hazel, and copyright > by the University of Cambridge, England. > > somewhere reasonably visible in your documentation and in any relevant > files or online help data or similar. A reference to the ftp site for > the source, that is, to > > ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ > > should also be given in the documentation. > > 3. Altered versions must be plainly marked as such, and must not be > misrepresented as being the original software. > > 4. If PCRE is embedded in any software that is released under the GNU > General Purpose Licence (GPL), then the terms of that licence shall > supersede any condition above with which it is incompatible. > > > I hate to keep harping on this, but I really do believe that it is > important. I solicited the opinion of Dr. Philip Hazel of > Cambridge University who as you probably know is the principal > author of Exim. I asked him if he would consider releasing Exim > under a difference license other than the GPL if doing so would > allow Sender-ID code to be included in it. His response was: > > /"The short answer is "No". / > > /I have no desire to change Exim's licence, and certainly not as a > result / > /from pressure of Microsoft's lawyers. Furthermore, some of the > other/ > /postings I've seen have said that developers using this "free" > licence/ > /must register with Microsoft. That is completely unacceptable."/ > > I believe that Dr. Hazel's response demonstrates two things. The > first is that one of the most popular MTAs in use will not be able > to include Sender-ID code. The second is that a very well > respected open source developer sees the IPR license terms as > "completely unacceptable". > > Kevin > From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 13:43:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12312 for ; Mon, 30 Aug 2004 13: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 i7UHGlLc065840; Mon, 30 Aug 2004 10:16: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 i7UHGloI065839; Mon, 30 Aug 2004 10:16:47 -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 i7UHGk5k065822 for ; Mon, 30 Aug 2004 10:16:46 -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 14D054149B; Mon, 30 Aug 2004 10:16:44 -0700 (PDT) Subject: Re: FW: on the topic of IPR From: Douglas Otis To: "Michael R. Brumm" Cc: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1093886202.5542.80.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 10:16:42 -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-08-27 at 09:27, Michael R. Brumm wrote: > Kevin Peuhkurinen wrote: > > It makes no sense to say "here we have some verifiably homegrown IP > > with no encumberances and here we have some encumbered IP. Let's use > > the encumbered IP rather than the unencumbered IP because otherwise we > > might get sued by parties unknown". > > Andrew Newton wrote: > > Is there a connection between "verifiably homegrown" and patent claims? > > > > You are correct that the parties are unknown. If this were an arcane > > subject area, it is most likely that they would remain unknown and > > probably non-existent. However e-mail and electronic messaging and > > anti-spam are hot areas of intellectual property. I did take a stroll > > through the USPTO database and there are numerous, numerous patents in > > this area. And these do not include the pending patents that cannot be > > seen. > > > > Also, if company XYZ came forward tomorrow and claimed covering IPR, > > should we ignore them? > > Ok, so now we have the *FEAR* of existing patents, the *UNCERTAINTY* of > future patents, and the *DOUBT* that the IETF and free/open source > communities could defend against the possible onslaught of submarine > patents. > > > Sounds to me like a good reason to go with Microsoft. We all know they have > our best welfare at heart, and they will protect us against this FUD. > > > We have at least one technology (SPF) which is in the public domain, is > superior at solving the problem this working group was chartered to solve, > and is widely deployed and tested on all the major MTAs. > > So, why are we spinning our wheels with an privately owned IP which is > encumbered by an onerous license, doesn't appear to solve the problem, and > has never been deployed or tested on any MTA? While I agree with this statement, I would also like to add there can be several improvements made to SPF. 1) The number of required lookups for describing the mail as being sent from disparately administered domains be confined to a single record. 2) Determine an identity without assumptions of the integrity of the mail channel upon which to establish defensible reputation services. 3) For sensitive mail, allow guarantees of the source of RFC2822 From. 4) Mark the mail channel list as restrictive or normative, but do not also use the list for the double purpose of authenticating the MTA, as this makes normative lists prone to being exploited. The single lookup becomes possible when, rather than using IP addresses to describe the permitted senders, authenticated names are used. This becomes another major bonus, as these authenticated names provides the certainty need for reputation services or enforcement. This then safely moves this effort into the realm of using names rather than addresses. By applying flags to indicate what mailbox fields this list restricts, both the MAIL FROM and From can be defended from spoofing. Leaving the list as being normative does not enable spam exploits made possible with "open-ended" authentication lists where the list is dual purposed, as with SPF. Yes, this becomes a two step process. Authenticate and authorize the MTA, and then add mail restrictions as desired. Authenticating and authorizing the MTA does not add to the number of DNS record lookups! But by being able to use names, delegating the sending of mail to other domains becomes a simple matter of specifying a name. Because mail restrictions are not part of the MTA authentication, they can be applied as needed. Because IP addresses are not used to define the permitted mail channel, there is no need to do subsequent DNS lookups to find these addresses. These lists can provide the normative mail channel used for the domain, in much the same manner an "open-end" list would have allowed. In the exceptional case, for superior protection from spoofing the From for financial institutions as example, a restriction on a header can be made, but this option does not burden normal mail use, as it does for SPF or Sender-ID. In addition, because these restrictions are not based upon the presents of other RFC2822 headers, this avoids the troubling IPR problem. If you want your From to only come from specific servers, this can be established. Sender-ID can never claim this ability. The forwarding problem created by going from a normative to restrictive list on the From header can be helped with public MAIL FROM signatures now being considered, that also locks the back-door left wide-open with Sender-ID. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 14:34:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15273 for ; Mon, 30 Aug 2004 14:34: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 i7UI4YEu073243; Mon, 30 Aug 2004 11:04:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UI4YNg073242; Mon, 30 Aug 2004 11:04:34 -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 i7UI4YFq073235 for ; Mon, 30 Aug 2004 11:04:34 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i7UI4bkW026950 for ; Mon, 30 Aug 2004 11:04:38 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "IETF-MXCOMP WG'" From: "Anne P. Mitchell, Esq." Subject: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) Date: Mon, 30 Aug 2004 11:04:37 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > 4) You have stated above that you believe Microsoft's claim is > "nebulous" with regard to rights being claimed. Your release notes > state "Implemented Sender Policy Framework checking on the From: > header. Be sure to read the documentation and understand the > implication." Since checking of the From: header is listed in the -pra > document, are you concluding that this is not encumbered by > Microsoft's claim? If so, how did you come to this conclusion? > This brings up a point which has been rolling around in the back of my head for a few days. We simply _don't_ know what is in the claim. In any other area where adoption of some program is to be impacted or encumbered in some way which could cause either a legal liability or an inability to actually implement on the part of the adopter - particularly such a potentially widely used program - it is inconceivable that people would be even considering adopting, or recommending, the program. In fact, if one had a professional license, and recommended adoption of such a program without a clear understanding of the encumberance, one could be guilty of malpractice. But I digress...what has been rolling around in the back of my head is this: Can anyone say with 100% certainty that there is *zero* technology, software, or process, which can be reasonably argued by Microsoft to belong to them, with regards to *checking*? Bear in mind that I have some experience in patenting this sort of technology (I have been involved in the patent work on the Habeas "technology", among others, and I put that word in quotes because if you look at the Habeas model I'm guessing many of you would be shocked to realize just how much *is* patentable as "technology"). Ok, I'm going to guess that some of you might say "yes" to the above. So, let's put it another way now: Is the method for checking under Sender I.D. *identical* to the method for checking for SPF? Imagine a world where some day you have to pay for a site license to be able to perform a check. Where the only receiver who *doesn't* have to pay to perform checks is Microsoft itself. Again, this is not Microsoft bashing - I personally believe that *any* large receiver owning the ultimate rights to an authentication system is a conflict of interest. And to be honest, for the life of me, I don't understand why SPF, which already had a lot of support from other corners, isn't what's being pushed now. Although, of course, for all we know (and I very much suspect) SPF is probably now in some way encumbered by MS anyways. It would be foolish of them to embrace and incorporate SPF technology without first making sure that they darned well owned it. Just like any other acquisition - you can either put the competitor under, or acquire them. Anne From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 15:13: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 PAA18752 for ; Mon, 30 Aug 2004 15:13: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 i7UIhKFC080567; Mon, 30 Aug 2004 11:43: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 i7UIhKkC080566; Mon, 30 Aug 2004 11:43:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UIhJ9c080558 for ; Mon, 30 Aug 2004 11:43:19 -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); Mon, 30 Aug 2004 11:43:23 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Aug 2004 11:43:23 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 11:43:23 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 11:43:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DOC-BUG: permitted use of PRA/submitter address Date: Mon, 30 Aug 2004 11:43:20 -0700 Message-ID: Thread-Topic: DOC-BUG: permitted use of PRA/submitter address thread-index: AcSOIkB6fIPhXRM9TTOox7G9e/PQrQAnhEkQ From: "Harry Katz" To: , "MARID" X-OriginalArrivalTime: 30 Aug 2004 18:43:21.0612 (UTC) FILETIME=[39674CC0:01C48EC1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7UIhK9c080559 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sunday, August 29, 2004 4:34 PM, mazieres@gmail.com wrote: > It's hard from the current drafts to figure out when exactly > it is appropriate to send mail to the PRA of a received mail > message. I'm guessing this is because the authors are > relying on previous RFCs for this. However, given that a lot > of people are already confused by the distinction between > envelope and From: address, there is a danger that the > introduction of a third address would lead to an even larger > number of broken vacation-type programs. > > I'd like to suggest that the Sender ID (or maybe the PRA or > SUBMITTER) document have somewhere a non-normative paragraph > that clues people in to how they can learn about appropriate > uses of the PRA. As an example, here are a bunch of > questions whose answers are not immediately obvious from > reading Sender ID and associated drafts: > > * Is it ever actually required that the PRA be a valid mailbox? Is it > legal to construct some mailbox whose domain has an SPF2 record but > not an MX or A record? I presume the answer is no, but that the > logic involves some other RFC I'm just not looking at. How would > you go about convincing an administrator this is wrong. > > * I am on vacation, and receive mail which lists my own address in the > To: or CC: fields, and does not have any indications such as > "Precedence: list/bulk/junk" that it is from a mailing list. I wish > for my filter to notify the sender that I will not be responding for > a week. Should I send the notification to the MAIL-FROM address, as > I currently do, or to the PRA? > > * I receive mail with an attachment that contains a virus. I wish to > configure my MUA or spam filter automatically to notify the sender > that his/her machine has a virus and the attachment has been > deleted. Should I send mail to the PRA? Can/should that mail come > from the empty envelope sender, or should/must it come from my real > email address? > > * I have been erroneously subscribed to a mailing list. Should I > complain directly to the PRA? Should I attempt to form a new > address by appending "-owner" or "-request" to the local part of the > PRA? Or should I complain to an address based on the envelope > sender, as I currently would. > > * I receive offensive and/or threatening mail from someone, and wish > to complain to their administrator. Should I complain to > postmaster/abuse at the domain name in the PRA, as opposed to the > domain in the From or envelope sender address? > > * In order to reduce spam, I currently perform an SMTP callback on the > envelope sender of mail, ensuring that any mail I accept could have > been bounced. (This is highly effective against spam from > virus-infected machines, because many machines infected by viruses > can make outgoing TCP connections but not accept incoming ones, and > thus are forced to use other people's often invalid envelope > senders.) In case of forgery, people can block these callbacks by > using SPFv1 records. Once we have Sender ID, should I instead > perform SMTP callbacks to validate the SUBMITTER or PRA address > rather than MAIL-FROM, so as to avoid wasting bandwidth of sites > whose addresses are being forged? The PRA doesn't replace or over-ride any of the semantics around mail replies or notifications. It is intended only as a mechanism to identify the entity most recently responsible for injecting the message into the mail system. If you normally send a bounce to the 2821 MAIL FROM address, you would continue to do so. If you normally send a reply to the 2822 From or Reply-To address, you would continue to do so. Section 4.2 of the submitter-03 draft has the following paragraph which addresses, at least in part, this very issue. Note that the presence of the SUBMITTER parameter on 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 section 3.7 of [SMTP] regardless of the presence of a SUBMITTER parameter. If the reverse-path is null, delivery status notifications MUST NOT be sent to the SUBMITTER address. From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 15:38: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 PAA20922 for ; Mon, 30 Aug 2004 15:38: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 i7UIxVAR085227; Mon, 30 Aug 2004 11: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 i7UIxV5Q085226; Mon, 30 Aug 2004 11:59:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UIxVsS085220 for ; Mon, 30 Aug 2004 11:59:31 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 6C3A7414C4 for ; Mon, 30 Aug 2004 11:59:35 -0700 (PDT) Subject: TECH-OMISSION: Security considerations and limit scope From: Douglas Otis To: IETF MARID WG In-Reply-To: <16682.31117.662266.736155@proton.pathname.com> References: <16682.31117.662266.736155@proton.pathname.com> Content-Type: text/plain Message-Id: <1093892373.5542.192.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 11:59:34 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Protocol & Core There is no security advice for using random source ports for DNS queries reaching the Internet. There is no advice regarding the potential presence of transparent inception of outbound SMTP traffic by ISPs. There is no advice waring against the use of "?all" in the case of shared outbound SMTP servers. There is no advice for the use of "+all". Jim Lyon explained this will lead to bad reputations. This implies the mailbox domain, used to resolve the MTA address, is also being used to establish reputations, even when the MTA is not authorized! There should be advice warning against establishing reputation information when the MTA address has not been authenticated, or when the SPF2 record uses "?all". It must not be presumed all MTAs check for the SPF2 permissions, or that the outbound MTA is not shared, nor can this checking and sharing be verified. There should be a caution that prohibits reputations based upon non-authorized MTAs. There should also be a warning for "?all" when the outbound path is shared. This sharing will "promote" mail from other domains as being fully validated and may lead to false assumptions with respect to the recipient, when the Mailbox domain is used to either obtain or record this information. There should be advice that only the IP address should be used to check reputations and to base complaints, as the Mailbox domain has not been adequately authenticated while it can not be presumed all MTA servers in the path of the message performed the requisite mail channel checks and that the MTA is not shared with other disparately administered domains. Don't limit the scope of the SPF record to just PRA plus others. Leave the record open to any scope that may exclude PRA. The use of exists and ptr record types adds a burden the recipient may not wish to endure. There should be a warning that this type of record may be rejected. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 15:40: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 PAA21047 for ; Mon, 30 Aug 2004 15: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 i7UJDLeU088320; Mon, 30 Aug 2004 12:13: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 i7UJDLDv088319; Mon, 30 Aug 2004 12:13:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UJDKlb088300 for ; Mon, 30 Aug 2004 12:13:20 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C1raf-0008JQ-00; Mon, 30 Aug 2004 12:13:17 -0700 To: Andrew Newton Cc: Sam Varshavchik , IETF MARID WG Subject: Re: DEPLOY: SPF/Sender ID support in Courier. References: From: Daniel Quinlan Date: 30 Aug 2004 12:13:17 -0700 In-Reply-To: Andrew Newton's message of "Mon, 30 Aug 2004 12:21:32 -0400" Message-ID: Lines: 74 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > The IETF does not require a royalty free license. Sure, but it seems evident that RF is practically a requirement for MARID acceptance and consensus. >> It appears that IETF's contemporary policies do not prevent the >> sponsor/advocates from including patented IP material into >> standards-track specifications, without even requiring the sponsor to >> actually enumerate and identify their intellectual property; a mere >> claim of the existence of some nebulous IP rights is sufficient, which >> can be revealed at any point in the future, at the sponsor's >> discretion. > I'm not sure what point you are trying to make here. Fill in the blanks. > 1) How do you base your decision on incompatibility? I ask this because > Courier uses OpenSSL and ships with a file called COPYING which states: >> This software is released under the GPL, version 2 (see COPYING.GPL). >> Additionally, compiling, linking, and/or using the OpenSSL toolkit in >> conjunction with this software is allowed. > According to the FSF, the OpenSSL license is also incompatible with > the GPL. Additionally, is the webmail part of Courier licensed in a > different way? I believe the Courier author could fix this by adding an exception to the license. Also, it's possible the usage of OpenSSL is okay if you consider OpenSSL to be part of the operating system, but that seems like a stretch from what I've read. Your message seems to boil down an ad hominem tu quoque that revolves around orthogonal issues. OpenSSL could be replaced by another library with the same API. OpenSSL or Courier could tweak their license. Patents often can't be worked around unless the owner changes their license... especially if you don't know what the patents cover. > Would there be issues using it with Apache since the FSF also > considers the Apache license to be incompatible with the GPL? The ASF believes that Apache License 2.0 is compatible with the GPL. http://www.apache.org/licenses/GPL-compatibility.html > 2) Based on my limited understanding of Courier, it seems that the only > document in the Sender ID docset that needs to be implemented directly > into Courier is the SUBMITTER ESMTP extension. The encumbered portions > of Sender ID, -core and -pra, could easily be implemented in a separate > module using the courierfilter interface. Are you unwilling to > incorporate the unencumbered SUBMITTER even if a core/pra courierfilter > were available? -core is the document that ties it all together so the unknown patents could cover ... well, I don't know what, but more than PRA. You may be right that the Courier author might be able to include enough of Sender-ID to support it and help make it a success. The separate module would not really be open source, though. > 3) If somebody were to patch Courier with Sender ID and distribute it > with such modifications, would you take legal action against them? That seems like a hard question to answer given that you can't predict the nature of a future license violation. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 16:04: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 QAA22147 for ; Mon, 30 Aug 2004 16:04: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 i7UJZHBq093812; Mon, 30 Aug 2004 12:35: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 i7UJZHSN093811; Mon, 30 Aug 2004 12:35:17 -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 i7UJZGlN093801 for ; Mon, 30 Aug 2004 12:35:17 -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 1C1rvz-00069q-00 for ietf-mxcomp@imc.org; Mon, 30 Aug 2004 20:35:20 +0100 Message-ID: <19a401c48ec8$1c98dd00$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <111001c48be5$ebaa1360$0200000a@ringo> <188c01c48e77$7d768bf0$0200000a@ringo> Subject: Re: TECH-OMISSION: Divergent assumptions about objectives Date: Mon, 30 Aug 2004 20:32:37 +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 Please correct my typing error. I sent: > > One particular form of lying involves forging the RFC 2821 'From:' header, so > that the recipient ascribes to the message an authority which it does not > actually have. Please replace 2821 by 2822 in the above. Chris From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 16:44: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 QAA28606 for ; Mon, 30 Aug 2004 16:44: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 i7UKDKlY002505; Mon, 30 Aug 2004 13:13: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 i7UKDKqR002504; Mon, 30 Aug 2004 13:13:20 -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 i7UKDJh6002489 for ; Mon, 30 Aug 2004 13:13:19 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 161A2E0534; Mon, 30 Aug 2004 16:13:20 -0400 (EDT) Date: Mon, 30 Aug 2004 16:13:20 -0400 From: John Leslie To: mazieres@gmail.com Cc: John Leslie , MXCOMP Subject: Re: Reputation services for SenderID Message-ID: <20040830201320.GN465@verdi> References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> <20040827231531.GI465@verdi> <94df60cf040829152232ce5533@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94df60cf040829152232ce5533@mail.gmail.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: mazieres@gmail.com wrote: > On Fri, 27 Aug 2004 19:15:31 -0400, John Leslie wrote: >> ... >> We then evaluate the list of IPs authorized by the SPF2 record, >> and run them against known IP blacklists; accumulating a score based >> on weighting the reputation of those blacklists for spam identified, >> false negatives, and false positives. > > This might usually work, but what do you do about the exists and ptr > mechanisms? In general there is no practical and 100% reliable way to > produce a list of IP addresses authorized by an SPF2 record. I didn't want to get into that level of detail -- and I especially don't want to tell reputation services how to run their business... But you are correct to note that exists and ptr are too close for comfort to the +all mechanism. IMHO, one would have to treat them as "+all" unless you have access to a large enough corpus of actual queries and replies to limit the set of IP addresses apparently authorized. (I don't believe monte carlo techniques are workable.) How large "large enough" is, I leave as an exercise to the student. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 16:44: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 QAA28627 for ; Mon, 30 Aug 2004 16:44: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 i7UKEgKg002741; Mon, 30 Aug 2004 13:14: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 i7UKEgT3002740; Mon, 30 Aug 2004 13:14:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKEf4k002733 for ; Mon, 30 Aug 2004 13:14:42 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so172636rnk for ; Mon, 30 Aug 2004 13:14:43 -0700 (PDT) Received: by 10.38.164.76 with SMTP id m76mr1139196rne; Mon, 30 Aug 2004 13:14:43 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Mon, 30 Aug 2004 13:14:43 -0700 (PDT) Message-ID: <94df60cf04083013141d0b9dc@mail.gmail.com> Date: Mon, 30 Aug 2004 16:14:43 -0400 From: Reply-To: To: Harry Katz Subject: Re: DOC-BUG: permitted use of PRA/submitter address Cc: MARID In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 30 Aug 2004 11:43:20 -0700, Harry Katz wrote: > > > On Sunday, August 29, 2004 4:34 PM, mazieres@gmail.com wrote: > > > It's hard from the current drafts to figure out when exactly > > it is appropriate to send mail to the PRA of a received mail > > message... > > ... > > The PRA doesn't replace or over-ride any of the semantics around mail > replies or notifications. It is intended only as a mechanism to > identify the entity most recently responsible for injecting the message > into the mail system. If you normally send a bounce to the 2821 MAIL > FROM address, you would continue to do so. If you normally send a reply > to the 2822 From or Reply-To address, you would continue to do so. > > Section 4.2 of the submitter-03 draft has the following paragraph which > addresses, at least in part, this very issue. > > Note that the presence of the SUBMITTER parameter on 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 section 3.7 of [SMTP] regardless of the presence > of a SUBMITTER parameter. If the reverse-path is null, delivery > status notifications MUST NOT be sent to the SUBMITTER address. One problem may be that when I read the words "delivery status notification", to me that has a very specific meaning (in the sense of RFC1891). Is that paragraph also supposed to cover auto-generated messages of the form "I'm on vacation and will read your message next week," or "Your attachment contained a virus and has been removed"? It also still doesn't address the question of whether the PRA must be a valid email address. I'm assuming that if the email address does exist, then the domain in the PRA is considered to offer mail service and must have RFC2142 mailbox names like abuse and postmaster. I don't see anything in the drafts that prevents someone from using the PRA simply as a non-functioning syntactic placeholder or level of indirection for authentication. (And of course, if I were a spammer, I certainly wouldn't be interested in setting up a working PRA.) I guess I'm particularly curious what people think about virus notifications. (I care a lot about this question because at times I get thousands of messages a day telling me my mail has been infected with a virus, when of course I didn't send the virus, but rather the virus forged my email address.) It seems to me that if you get mail with a virus, the person whose machine is infected is most likely the PRA, not the MAIL-FROM address. Therefore, I would be tempted to configure my mail filter to send automatic notifications to the PRA, instead of the MAIL-FROM address. So the questions are: 1. Is there anything in the drafts to prevent me from sending such notifications to the PRA? 2. Is the PRA required to exist/accept such notifications. Should the PRA be a human rather than an autoresponder? 3. Is the PRA required to accept mail from the empty envelope sender, even through any RFC1891-type DSNs/bounce messages should still be sent to the MAIL-FROM address? David From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 17:12: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 RAA02896 for ; Mon, 30 Aug 2004 17:12: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 i7UKpOju010033; Mon, 30 Aug 2004 13:51: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 i7UKpOnD010032; Mon, 30 Aug 2004 13:51:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKpNjU010018 for ; Mon, 30 Aug 2004 13:51:23 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so114028rnk for ; Mon, 30 Aug 2004 13:51:20 -0700 (PDT) Received: by 10.38.11.77 with SMTP id 77mr1150432rnk; Mon, 30 Aug 2004 13:51:19 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Mon, 30 Aug 2004 13:51:18 -0700 (PDT) Message-ID: <94df60cf0408301351c0551b0@mail.gmail.com> Date: Mon, 30 Aug 2004 16:51:18 -0400 From: Reply-To: To: Douglas Otis Subject: Re: TECH-OMISSION: Security considerations and limit scope Cc: IETF MARID WG In-Reply-To: <1093892373.5542.192.camel@ddev.mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16682.31117.662266.736155@proton.pathname.com> <1093892373.5542.192.camel@ddev.mail-abuse.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 30 Aug 2004 11:59:34 -0700, Douglas Otis wrote: > > The use of exists and ptr record types adds a burden the recipient may > not wish to endure. There should be a warning that this type of record > may be rejected. If you are going to do this, you should treat exists and ptr separately. ptr record types almost certainly don't add a burden to the recipient. The reason is that pretty much all MTAs do a reverse lookup on the client's IP address anyway for inclusion in the Received: header. The ptr check can therefore be implemented without an additional DNS lookup. The exists header can, of course, lead to extra DNS lookups. Note also that if you are worried about extra DNS lookups, the include directive can definitely be responsible for more DNS traffic. I think that the flexibility offered by exists and include is very useful in a number of situations, and so would rather not see "reasonable" use of the mechanisms deprecated, though clearly we would also like clients not to feel compelled to go through with "unreasonable" checks. Recursion limits are a step in the right direction; whether or not they suffice will be seen when we deploy this stuff... [I also believe that a few changes, like allowing the negation of operators, would significantly reduce (but not eliminate) the need for include and exists. However, I recognize such discussion is no longer in scope, and don't want to distract from the topic at hand...] David From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 17:49:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06366 for ; Mon, 30 Aug 2004 17:49:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULRVr7016758; Mon, 30 Aug 2004 14:27: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 i7ULRV57016757; Mon, 30 Aug 2004 14:27:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULRUg6016750 for ; Mon, 30 Aug 2004 14:27:30 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 936A24149B; Mon, 30 Aug 2004 14:27:35 -0700 (PDT) Subject: Re: Reputation services for SenderID From: Douglas Otis To: mazieres@gmail.com Cc: John Leslie , MXCOMP In-Reply-To: <94df60cf040829152232ce5533@mail.gmail.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> <20040827231531.GI465@verdi> <94df60cf040829152232ce5533@mail.gmail.com> Content-Type: text/plain Message-Id: <1093901254.5542.343.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 14:27:34 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-08-29 at 15:22, mazieres@gmail.com wrote: > On Fri, 27 Aug 2004 19:15:31 -0400, John Leslie wrote: > > ... > > We then evaluate the list of IPs authorized by the SPF2 record, > > and run them against known IP blacklists; accumulating a score based > > on weighting the reputation of those blacklists for spam identified, > > false negatives, and false positives. > > This might usually work, but what do you do about the exists and ptr > mechanisms? In general there is no practical and 100% reliable way to > produce a list of IP addresses authorized by an SPF2 record. Evaluating against a currently available IP address blacklist, for moving from an address scheme to a name scheme, by transferring existing address information found published in SPF2 records is not possible. If there was a black-listed IP address that authenticated as being within the Sender-ID mail-channel, then that name might be added to a RHSBL. Without other confirmation, this would erode reasons for using names rather than addresses. Most would drop the connection and not care what the Sender-ID identity was or whether the MTA authenticated. To build upon the IP address blacklist and correlate to a name can not make use of the SPF2 records directly. One can not trust the ownership of addresses published in the SPF2 records. Building information from an address black-list based upon what is published in SPF2 records is meaningless. Publishing addresses has demonstrated nothing with respect to being administratively responsible for them. Conversely, obtaining this address information from complex SPF2 records is impossible without message-based keys to build access labels. Sender-ID SPF2 records does not enable a safe correlation between the MTA address and the Mailbox Domain. If comparing an IP blacklist and the SPF2 records- Building: A spammer could make themselves appear to be using known good addresses, where actually different addresses are actually used by means of the labeling mechanism built upon unpublished information found only in the message. This is a good reason why a macro label mechanism is bad. The SPF2 record must be ignored. Reporting: A spammer could make known good addresses appear bad, if the published addresses are included in a reputation assessment. The SPF2 record must be ignored. Sender-ID SPF2 does not allow a safe bridge between IP address information and domain name information for reputation use. Spammers do whatever it takes to gum up the works and that means claiming IP addresses they don't administer. As you point out, the actual address may not be accessible, if reviewed independent of a message. The Sender-ID entity could reside behind a transparently intercepted or shared outbound SMTP server. This means assumptions regarding this Sender-ID identity being authentic may be in error. Sender-ID only gives the appearance of authenticating the sender, and may have the unfortunate outcome of being a useful ploy to enable spammers to promote themselves as being validated by this flawed system. It also means innocent parties will become "reputation" victims of these ploys. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 18:40: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 SAA10497 for ; Mon, 30 Aug 2004 18:40:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UMGRSG027150; Mon, 30 Aug 2004 15:16: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 i7UMGR9a027149; Mon, 30 Aug 2004 15:16:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UMGRQ3027123 for ; Mon, 30 Aug 2004 15:16:27 -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 (Email Firewall v6.0.0)); Mon, 30 Aug 2004 15:16:18 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Mon, 30 Aug 2004 15:16:07 -0700 Message-ID: From: "Daryl Odnert" To: "'Mark Lentczner'" , "IETF MARID WG" Subject: RE: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) Date: Mon, 30 Aug 2004 15:16:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D2D78B81QO832200-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48EDE.6106AE1E" 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_01C48EDE.6106AE1E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > There is nothing heuristic in the PRA > identity. It follows directly from the RFC 2822 definition of the > headers. This statement makes me wonder how anyone could validly claim a patent on an algorithm to find the PRA. Daryl Odnert ------_=_NextPart_001_01C48EDE.6106AE1E Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support = in Courier.)

Mark Lentczner wrote:
>          = ;            = ;    There is nothing heuristic in the PRA
> identity.  It follows directly from the = RFC 2822 definition of the
> headers.

This statement makes me wonder how anyone could = validly claim a
patent on an algorithm to find the PRA.

Daryl Odnert

------_=_NextPart_001_01C48EDE.6106AE1E-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 19:15: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 TAA13233 for ; Mon, 30 Aug 2004 19:15: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 i7UMnu2L033524; Mon, 30 Aug 2004 15:49:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UMnueH033523; Mon, 30 Aug 2004 15:49:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UMntY4033501 for ; Mon, 30 Aug 2004 15:49:56 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7UMnl77016223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 Aug 2004 18:49:58 -0400 Subject: Re: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages From: Mark Shewmaker To: MARID In-Reply-To: <72A8ABAC-F95A-11D8-881C-000A95B3BA44@hxr.us> References: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> <1093650303.3782.3839.camel@localhost.localdomain> <72A8ABAC-F95A-11D8-881C-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1093906313.3463.8385.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 18:51:53 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Mon, 30 Aug 2004 18:49:58 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2004-08-28 at 21:26, Andrew Newton wrote: > On Aug 27, 2004, at 7:45 PM, Mark Shewmaker wrote: > > > So, is that suggestion something that could be included within > > SenderID, perhaps in a security-considerations section? > > For clarity, can you give the text you would like included in the > security section? I think this would better help in understanding the > problem and better help people formulate an opinion. Sure. ===================================================================== 6.5 Vulnerability to unintended participation in Forged DSN attacks. This vulnerability exists if local policy settings allow for a situation in which all of the following are true: - An incoming message was sent to multiple recipients, - The message will ultimately be considered deliverable to some subset of its intended recipients, - The message will also be ultimately be considered undeliverable to some other subset of the initial recipients, and - The ultimate determination as to per-recipient deliverability cannot be made until after the SMTP transaction accepts the message for delivery. Normally a delivery status notification would be sent to the given MAIL FROM address, notifying it of the undeliverability of the message for its specific intended recipients. However, if the MAIL FROM address is forged, an innocent third party will be the recipient of this delivery service notification. A clever attacker can take advantage of this vulnerability by using any machine with detectably differing local policy settings as an apparent source of the attacker's forged DSNs. Not only does this mean the ultimate victims will receive forged DSNs, but the machine the attacker used to accomplish the forgery may become known as a source of forged DSNs. An MTA can completely avoid becoming a participant in a DSN attack in all cases by: Whenever all of the following is true: - An incoming message is addressed to multiple participants. - Those participants have local policy settings that, given the context of the specifics of the MTA transaction, mean that a per-recipient final determination of delivery cannot be made until after the message has been fully accepted. - The MTA has not positively validated the MAIL FROM address, Then: - The MTA should give temporary rejections at "RCPT TO:" time to all recipients with differing local policy settings and where the recipients have not already been temporarily or permanently rejected for other reasons, (and where the local policy setting difference can cause differing determinations of ultimate deliverability), thus accepting only a compatible subset of recipients and avoiding the need to create DSNs at all. It is suggested that the MTA reject these recipients with a return code of 4.7.6. (Note that the MTA is not rejecting on the basis of too many recipients, rather it is rejecting on the basis of a security-related incompatibility in the requested recipient list.) Given special-case conditions, there are simpler, alternative ways an MTA can completely avoid becoming a participant in a DSN attack: - If the client MTA sends a "SUBMITTER" parameter to the MAIL command, then no per-recipient policy that addresses functionality related to this standard can trigger this vulnerability. If per-recipient policy settings only extend to functionality related to this standard, then the above recipient-rejection workaround need not be used for that SMTP transaction. - If the server MTA obtains positive validation of the MAIL FROM address for a particular SMTP transaction, then for that SMTP transaction the server MTA need not use the recipient-rejection workaround given above. - If a future SMTP extension allows for per-recipient after-DATA rejects, and an SMTP session makes use of such an extension, then the above workaround is not needed for that session. Avoiding the receipt of forged DSNs is generally outside the scope of this document, however a domain that signs outgoing messages in a recognizable way can avoid at least some types of forged DSN attacks. ===================================================================== After writing all that, (and after seeing Chris Hayne's similar proposal which he sent earlier today), I'm actually starting to rethink my position as to whether this workaround should be listed within core at all. (!) The reason is that in addition to affecting Sender ID, the above vulnerability affects the general case of content-based filtering, so I'm wondering if something like the above would be better placed in a more general BCP as opposed to just being included within Sender ID. For the moment I'm not sure how to answer the above question. I think the warning/workaround needs to be *somewhere*, but whether it should be in core or in a more BCP, or both, I'm not sure: o If it should be in core, then I want to push for something like the above. o If it should be in a BCP, well, then I'll push for it there, (although I'm not clear on how to go about that.) As the above question doesn't much change the existence of the vulnerability and the necessity of the workaround though, I still submit my wording above for discussion, dissection, and joyful mutilation. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 19:28: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 TAA13875 for ; Mon, 30 Aug 2004 19:28:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UN34nw035187; Mon, 30 Aug 2004 16:03: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 i7UN34we035186; Mon, 30 Aug 2004 16:03:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UN34B1035176 for ; Mon, 30 Aug 2004 16:03:04 -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 (Email Firewall v6.0.0)); Mon, 30 Aug 2004 16:02:59 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Mon, 30 Aug 2004 16:02:47 -0700 Message-ID: From: "Daryl Odnert" To: "'Chris Haynes'" , "IETF MARID WG" Subject: RE: TECH-OMISSION: Security vulnerability - Malicious DSN attack s Date: Mon, 30 Aug 2004 16:02:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D2D6DA81QO835299-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48EE5.760C358A" 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_01C48EE5.760C358A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hello Chris, I still strongly disagree that the vulnerability you are concerned about is made worse by Sender ID. As you've explained, Sender ID does add a new way to get a recipient's MTA to reject a message. But there are already several ways to make this happen, so I just don't see this as a fair criticism of Sender ID. However, in the interest of clarity, I think that in your example, you need to make it explicit that the participant P does not perform any Sender ID test before accepting responsibility for relaying the message from A, nor does it add any RFC 2822 headers that would change the Purported Responsible Address of the message. I think you also need to make it clear that P would have to be configured such that it accepts mail from submitter's IP address where the MAIL FROM address is V and where the recipient address is in a different domain (R) that might perform a Sender ID test on inbound SMTP mail. Normally, only MTAs that are operated by (or trusted by) V for outbound SMTP mail processing would be configured this way. Therefore, the attack is only likely to occur if it can be launched from an IP address that normally submits mail from V to P. Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C48EE5.760C358A Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: TECH-OMISSION: Security vulnerability - Malicious DSN attacks

Hello Chris,

I still strongly disagree that the vulnerability you are concerned
about is made worse by Sender ID.  As you've explained, Sender ID
does add a new way to get a recipient's MTA to reject a message.
But there are already several ways to make this happen, so I just
don't see this as a fair criticism of Sender ID.

However, in the interest of clarity, I think that in your example,
you need to make it explicit that the participant P does not perform
any Sender ID test before accepting responsibility for relaying the
message from A, nor does it add any RFC 2822 headers that would change
the Purported Responsible Address of the message.

I think you also need to make it clear that P would have to be
configured such that it accepts mail from submitter's IP address where
the MAIL FROM address is V and where the recipient address is in a different
domain (R) that might perform a Sender ID test on inbound SMTP mail.
Normally, only MTAs that are operated by (or trusted by) V for outbound
SMTP mail processing would be configured this way.  Therefore, the attack
is only likely to occur if it can be launched from an IP address that
normally submits mail from V to P.

Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C48EE5.760C358A-- From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 20:25: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 UAA17024 for ; Mon, 30 Aug 2004 20:25: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 i7UNsXg8039452; Mon, 30 Aug 2004 16:54:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UNsXwQ039447; Mon, 30 Aug 2004 16:54:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UNsWcE039440 for ; Mon, 30 Aug 2004 16:54:32 -0700 (PDT) (envelope-from roy+dated+1096502068.2bcb51@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7UNx1Pu021027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Aug 2004 23:59:07 GMT (envelope-from roy+dated+1096502068.2bcb51@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7UNsTsr017450 for ; Tue, 31 Aug 2004 00:54:29 +0100 (BST) (envelope-from roy+dated+1096502068.2bcb51@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7UNsTd2017449 for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 00:54:29 +0100 (BST) (envelope-from roy+dated+1096502068.2bcb51@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 31 Aug 2004 00:54:27 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16691.48691.293391.406711@giles.gnomon.org.uk> Date: Tue, 31 Aug 2004 00:54:27 +0100 To: Paul Iadonisi Cc: ietf-mxcomp@imc.org Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) In-Reply-To: <1093720180.7023.148.camel@va.local.linuxlobbyist.org> References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> <1093720180.7023.148.camel@va.local.linuxlobbyist.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 >>>>> "Paul" == Paul Iadonisi writes: Paul> This makes no sense. MAIL FROM is most certainly at least Paul> as available to the MUA as Sender-ID via the Return-Path: Paul> header. Sadly non-compliant MTAs (which fail to add Return-Path on final delivery) are quite prevalent in the field. Hence my comment that an MUA cannot _reliably_ determine it. -roy From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 20:31: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 UAA17784 for ; Mon, 30 Aug 2004 20:31: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 i7V07qcQ040230; Mon, 30 Aug 2004 17:07: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 i7V07q80040229; Mon, 30 Aug 2004 17:07: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 i7V07pPZ040222 for ; Mon, 30 Aug 2004 17:07:51 -0700 (PDT) (envelope-from roy+dated+1096502869.f21b2e@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7V0CMpG022703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 31 Aug 2004 00:12:28 GMT (envelope-from roy+dated+1096502869.f21b2e@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7V07oQX017688 for ; Tue, 31 Aug 2004 01:07:50 +0100 (BST) (envelope-from roy+dated+1096502869.f21b2e@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7V07n7N017687 for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 01:07:49 +0100 (BST) (envelope-from roy+dated+1096502869.f21b2e@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 31 Aug 2004 01:07:49 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16691.49492.811055.57958@giles.gnomon.org.uk> Date: Tue, 31 Aug 2004 01:07:48 +0100 To: Paul Iadonisi Cc: ietf-mxcomp@imc.org Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) In-Reply-To: <1093720180.7023.148.camel@va.local.linuxlobbyist.org> References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> <1093720180.7023.148.camel@va.local.linuxlobbyist.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 >>>>> "Paul" == Paul Iadonisi writes: >> Even if Sender ID is incompatible with the GPL [2] -- and I'm >> skeptical that it is except under the most extreme >> interpretations -- Paul> And we have yet to see a convincing legal argument (or Paul> *any* legal argument) from an attorney posted to this list. Paul> I'd like to know what Anne Mitchell (on this list) thinks of Paul> her legal analysis being called extreme by a non-lawyer. Ok, here's my argument: (1) Imagine you don't sign the patent license. In that case, the license clearly has no effect on you. The question is, does the existence of a patent claim prevent you from distributing under the GPL anyway. It is possible to interpret the GPL such that it does, since you are not in a position to offer rights to redistribute, although it's not clear (to me) that this is what the GPL intends. This may even be the correct interpretation of the GPL, however I call it an 'extreme' position because under that position it is also unlawful to distribute the Linux kernel, since it seems likely from recent reparts that there are a substantial number of patent claims against it. In fact, this is likely to be true of most non-trivial GPL'd software. (2) Now imagine that you _have_ signed the Sender ID license. The Sender ID license doesn't require you to place any restrictions on the recipient of the software, as far as I can see the situation with GPL compliance is no different to (1) -roy From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 20:59: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 UAA19263 for ; Mon, 30 Aug 2004 20:59: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 i7V0ZU7G042598; Mon, 30 Aug 2004 17: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 i7V0ZUYE042597; Mon, 30 Aug 2004 17:35:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V0ZTVm042572 for ; Mon, 30 Aug 2004 17:35:29 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so200148rnk for ; Mon, 30 Aug 2004 17:35:22 -0700 (PDT) Received: by 10.38.3.57 with SMTP id 57mr1263252rnc; Mon, 30 Aug 2004 17:35:21 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Mon, 30 Aug 2004 17:35:21 -0700 (PDT) Message-ID: <94df60cf0408301735444d4a45@mail.gmail.com> Date: Mon, 30 Aug 2004 20:35:21 -0400 From: Reply-To: To: Mark Shewmaker Subject: Re: Re: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages Cc: MARID In-Reply-To: <1093906313.3463.8385.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> <1093650303.3782.3839.camel@localhost.localdomain> <72A8ABAC-F95A-11D8-881C-000A95B3BA44@hxr.us> <1093906313.3463.8385.camel@localhost.localdomain> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I strongly support including something along the lines of what you wrote, either in core or in some BCP document accepted at the same time. (Though I have to say the complexity of the explanation makes me appreciate plain-old SPF-classic a lot more, but I'll stick to issues that are in scope...) I just have a couple of comments. On Mon, 30 Aug 2004 18:51:53 -0400, Mark Shewmaker wrote: > This vulnerability exists if local policy settings allow for a situation > in which all of the following are true: > > - An incoming message was sent to multiple recipients, > - The message will ultimately be considered deliverable to some > subset of its intended recipients, > - The message will also be ultimately be considered undeliverable > to some other subset of the initial recipients, and > - The ultimate determination as to per-recipient deliverability > cannot be made until after the SMTP transaction accepts the > message for delivery. The last condition is not quite correct, because you can make the determination before replying to the "." at the end of the DATA command. Thus, I would recommend some wording along the lines of, "The ultimate determination as to per-recipient deliverability cannot be made before the SMTP DATA command." > A clever attacker can take advantage of this vulnerability by using any > machine with detectably differing local policy settings as an apparent > source of the attacker's forged DSNs. How about dropping the word "clever." From the point of view of a standards document, the attacker's intellect is irrelevant. (Plus, I would argue this attack isn't really all that clever, particularly once it's already been described in a standards document.) > An MTA can completely avoid becoming a participant in a DSN attack in > all cases by: > > Whenever all of the following is true: > > - An incoming message is addressed to multiple participants. > > - Those participants have local policy settings that, > given the context of the specifics of the MTA transaction, > mean that a per-recipient final determination of delivery > cannot be made until after the message has been fully accepted. > > - The MTA has not positively validated the MAIL FROM address, What exactly does positively validated the MAIL FROM address mean, unless you have something like SPF classic? Also, I would argue that you don't need to positively validate the MAIL FROM address. All you really need to know is that whoever would get a DSN is somehow involved in the sending of the message. Thus, one valid test would be to run a tentative check under the assumption that the MAIL FROM address is actually the PRA. If the test returns anything other than Pass or None, of course you don't reject the mail, but instead, proceed as you outlined below, including returning a 4.7.6 for multiple recipients. In the case that the MAIL FROM address does Pass the Sender ID check, then it is probably okay to go ahead and accept the mail, generating DSNs later on. Yes, it's still possible for an attacker to mount a joe job attack and flood you with bounces. But the attacker would need to control IP addresses from which he could use your address as a PRA, which is a lot harder than mounting the generic attack. In fact, while I don't fully understand the motivation for having different PRA and MAIL-FROM addresses, I gather from previous messages that the people who want this the most are large banks that send out bulk mail. Bulk mailers would probably benefit the most from being able to reach multiple recipients in a single SMTP transaction. David From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 21:25: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 VAA20868 for ; Mon, 30 Aug 2004 21: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 i7V0uX33044012; Mon, 30 Aug 2004 17:56:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V0uX9J044011; Mon, 30 Aug 2004 17:56:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V0uWmw044003 for ; Mon, 30 Aug 2004 17:56:32 -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); Mon, 30 Aug 2004 17:56:35 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Aug 2004 17:56:23 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 17:56:35 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 17:56:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DOC-BUG: permitted use of PRA/submitter address Date: Mon, 30 Aug 2004 17:56:18 -0700 Message-ID: Thread-Topic: DOC-BUG: permitted use of PRA/submitter address thread-index: AcSOzgCaDMTPgIiFRt6TLWyUololHQAIsYPg From: "Harry Katz" To: , "MARID" X-OriginalArrivalTime: 31 Aug 2004 00:56:34.0442 (UTC) FILETIME=[5C91FEA0:01C48EF5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7V0uWmw044006 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, August 30, 2004 1:15 PM, mazieres@gmail.com [mailto:mazieres@gmail.com] wrote: > On Mon, 30 Aug 2004 11:43:20 -0700, Harry Katz > wrote: > > > > > > On Sunday, August 29, 2004 4:34 PM, mazieres@gmail.com wrote: > > > > > It's hard from the current drafts to figure out when > exactly it is > > > appropriate to send mail to the PRA of a received mail message... > > > ... > > > > The PRA doesn't replace or over-ride any of the semantics > around mail > > replies or notifications. It is intended only as a mechanism to > > identify the entity most recently responsible for injecting the > > message into the mail system. If you normally send a bounce to the > > 2821 MAIL FROM address, you would continue to do so. If > you normally > > send a reply to the 2822 From or Reply-To address, you > would continue to do so. > > > > Section 4.2 of the submitter-03 draft has the following paragraph > > which addresses, at least in part, this very issue. > > > > Note that the presence of the SUBMITTER parameter on 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 section 3.7 of [SMTP] regardless of > the presence > > of a SUBMITTER parameter. If the reverse-path is null, delivery > > status notifications MUST NOT be sent to the SUBMITTER address. > > One problem may be that when I read the words "delivery > status notification", to me that has a very specific meaning > (in the sense of RFC1891). Is that paragraph also supposed > to cover auto-generated messages of the form "I'm on vacation > and will read your message next week," or "Your attachment > contained a virus and has been removed"? The above paragraph deals with DSNs. It could perhaps be amended to also include replies and auto-responder messages. I think this clarification isn't significant enough to warrant a rev of the spec, but I'd certainly be willing to bundle it up with other changes if a future rev is required. > > It also still doesn't address the question of whether the PRA > must be a valid email address. I'm assuming that if the > email address does exist, then the domain in the PRA is > considered to offer mail service and must have RFC2142 > mailbox names like abuse and postmaster. I don't see > anything in the drafts that prevents someone from using the > PRA simply as a non-functioning syntactic placeholder or > level of indirection for authentication. (And of course, if > I were a spammer, I certainly wouldn't be interested in > setting up a working PRA.) Correct. The PRA is derived from 2822 headers so the validity of the PRA address is likewise derived from the validity of those addresses. I expect the PRA to be a valid delivery address in the vast majority of (legitimate) cases, however, I do not believe this can or should be a requirement in the spec. See below for examples. > > I guess I'm particularly curious what people think about > virus notifications. (I care a lot about this question > because at times I get thousands of messages a day telling me > my mail has been infected with a virus, when of course I > didn't send the virus, but rather the virus forged my email > address.) It seems to me that if you get mail with a virus, > the person whose machine is infected is most likely the PRA, > not the MAIL-FROM address. Therefore, I would be tempted to > configure my mail filter to send automatic notifications to > the PRA, instead of the MAIL-FROM address. So the questions are: > > 1. Is there anything in the drafts to prevent me from sending > such notifications to the PRA? No. However the PRA is neither a bounce address, nor a reply-to address. And since the PRA only identifies the responsible sender of the most recent "hop" I think you cannot assume the virus originates from the PRA address. > > 2. Is the PRA required to exist/accept such notifications. > Should the PRA be a human rather than an autoresponder? No. The PRA could easily be the address of an application that sends but does not read mail. In fact, example 5.4 of the SUBMITTER spec contemplates exactly this in it's use of a generic service account on the SUBMITTER parameter. > > 3. Is the PRA required to accept mail from the empty envelope > sender, even through any RFC1891-type DSNs/bounce messages > should still be sent to the MAIL-FROM address? Not sure I understand this question. However, when an MTA sends a DSN with MAIL FROM <>, the PRA would typically be something like postmaster@example.com or mailer-daemon@example.com. See example 5.5 of the SUBMITTER spec. From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 21:48: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 VAA21735 for ; Mon, 30 Aug 2004 21:48:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V1KQoo046446; Mon, 30 Aug 2004 18:20:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V1KQ6b046445; Mon, 30 Aug 2004 18:20:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V1KP39046434 for ; Mon, 30 Aug 2004 18:20:26 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7V1JOQX005471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Aug 2004 21:19:27 -0400 Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) From: Paul Iadonisi To: ietf-mxcomp@imc.org In-Reply-To: <16691.49492.811055.57958@giles.gnomon.org.uk> References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> <1093720180.7023.148.camel@va.local.linuxlobbyist.org> <16691.49492.811055.57958@giles.gnomon.org.uk> Content-Type: text/plain Message-Id: <1093915092.3538.31.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 30 Aug 2004 21:18:13 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-08-30 at 20:07, Roy Badami wrote: > >>>>> "Paul" == Paul Iadonisi writes: > > >> Even if Sender ID is incompatible with the GPL [2] -- and I'm > >> skeptical that it is except under the most extreme > >> interpretations -- > > Paul> And we have yet to see a convincing legal argument (or > Paul> *any* legal argument) from an attorney posted to this list. > Paul> I'd like to know what Anne Mitchell (on this list) thinks of > Paul> her legal analysis being called extreme by a non-lawyer. > > Ok, here's my argument: Another honest question: Are you an attorney? We can go back and forth until we are blue in the face, if we really want to, but I was pretty clearly talking about analyses from attorneys, not armchair lawyers like ourselves ;-) Obviously, no lawyer is infallible, but with the tally so far being three lawyers finding the patent license incompatible, and zero finding it compatible, one has to wonder if the view that they are compatible carries any weight any more. Nevertheless, my response: > (1) Imagine you don't sign the patent license. In that case, the > license clearly has no effect on you. The question is, does the > existence of a patent claim prevent you from distributing under > the GPL anyway. > > It is possible to interpret the GPL such that it does, since you > are not in a position to offer rights to redistribute, although > it's not clear (to me) that this is what the GPL intends. > > This may even be the correct interpretation of the GPL, however I > call it an 'extreme' position because under that position it is > also unlawful to distribute the Linux kernel, since it seems > likely from recent reparts that there are a substantial number of > patent claims against it. In fact, this is likely to be true of > most non-trivial GPL'd software. Re-read the preamble and section 7 of the GPL. The phrase that stands out in section 7 is "court judgement or allegation of infringement" and the preamble acknowledges the constant threat of software patents. Beyond that, I'd need to defer to an attorney's opinion, but if I'm not mistaken -- and this is something I remember Linus Torvalds acknowledging, or should I say, asserting -- any attorney will tell you that willful infringement is much more likely to bring about a judgement against you than innocent infringement. In other words it is unwise for any developer of software to rummage through the USPTO database, because if you do it can be said that you got the idea there or discovered your 'invention' was already patented by somebody else and you went ahead and used that 'invention' in your code knowing full well it was infringing. Ignorance *is* bliss in this case. But here we have someone stating that they have IPR claims on a public mailing list on part of something that is being submitted as a standard that all the internet's MTAs will presumably need to implement. Plausible deniability just went out the window, methinks. > (2) Now imagine that you _have_ signed the Sender ID license. The > Sender ID license doesn't require you to place any restrictions on > the recipient of the software, as far as I can see the situation > with GPL compliance is no different to (1) Incorrect. This one's easy. Just reread section 2.2 of the patent license. It is clearly non-sublicenseable which makes it quite obviously incompatible with section 6 of the GPL. I could find other conflicts, but I believe that is sufficient. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 21: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 VAA22153 for ; Mon, 30 Aug 2004 21: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 i7V1WtKw047539; Mon, 30 Aug 2004 18:32: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 i7V1Wt2u047538; Mon, 30 Aug 2004 18:32: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 i7V1WtIF047532 for ; Mon, 30 Aug 2004 18:32: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 B05694149B; Mon, 30 Aug 2004 18:33:01 -0700 (PDT) Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) From: Douglas Otis To: Roy Badami Cc: Paul Iadonisi , MARID In-Reply-To: <16691.49492.811055.57958@giles.gnomon.org.uk> References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> <1093720180.7023.148.camel@va.local.linuxlobbyist.org> <16691.49492.811055.57958@giles.gnomon.org.uk> Content-Type: text/plain Message-Id: <1093915980.5542.404.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 18:33: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 Mon, 2004-08-30 at 17:07, Roy Badami wrote: > >>>>> "Paul" == Paul Iadonisi writes: > >> Even if Sender ID is incompatible with the GPL [2] -- and I'm > >> skeptical that it is except under the most extreme > >> interpretations -- > > Paul> And we have yet to see a convincing legal argument (or > Paul> *any* legal argument) from an attorney posted to this list. > Paul> I'd like to know what Anne Mitchell (on this list) thinks of > Paul> her legal analysis being called extreme by a non-lawyer. > > Ok, here's my argument: > > (1) Imagine you don't sign the patent license. In that case, the > license clearly has no effect on you. The question is, does the > existence of a patent claim prevent you from distributing under > the GPL anyway. > > It is possible to interpret the GPL such that it does, since you > are not in a position to offer rights to redistribute, although > it's not clear (to me) that this is what the GPL intends. > > This may even be the correct interpretation of the GPL, however I > call it an 'extreme' position because under that position it is > also unlawful to distribute the Linux kernel, since it seems > likely from recent reparts that there are a substantial number of > patent claims against it. In fact, this is likely to be true of > most non-trivial GPL'd software. > > (2) Now imagine that you _have_ signed the Sender ID license. The > Sender ID license doesn't require you to place any restrictions on > the recipient of the software, as far as I can see the situation > with GPL compliance is no different to (1) To be cynical there is a difference, as Sender-ID can not be transferred and requires an individual agreement for its use: Imagine Microsoft acquires 49% of the shares for company 'V'. Microsoft then transfers Sender-ID patent rights to company 'V' with a private agreement for unlimited use of this algorithm. Are the licenses with Microsoft still valid when rights are now held by company 'V'? The license was with Microsoft, but now Microsoft says "Sorry, company 'V' now owns the rights for that algorithm, and we gave them the list of companies we know to be using this technology." You will be receiving their demands in the mail. -or- Imagine Microsoft no longer feels generous and changes these agreements to be the equivalent of the third-world debt. Does this make Exchange with Microsoft clients look better? Sender-ID by itself may break both SMTP and DNS with clumsy TXT lookups and complex macro scripts, but with the legal wrench thrown in, Bob's your uncle. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 22:31: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 WAA24088 for ; Mon, 30 Aug 2004 22:31: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 i7V26ksP051025; Mon, 30 Aug 2004 19:06:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V26kYO051024; Mon, 30 Aug 2004 19:06:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V26jAs051016 for ; Mon, 30 Aug 2004 19:06:45 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so130374rnl for ; Mon, 30 Aug 2004 19:06:48 -0700 (PDT) Received: by 10.38.73.36 with SMTP id v36mr1302261rna; Mon, 30 Aug 2004 19:06:48 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Mon, 30 Aug 2004 19:06:48 -0700 (PDT) Message-ID: <94df60cf04083019063ef33297@mail.gmail.com> Date: Mon, 30 Aug 2004 22:06:48 -0400 From: Reply-To: To: Harry Katz Subject: Re: DOC-BUG: permitted use of PRA/submitter address Cc: MARID In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 30 Aug 2004 17:56:18 -0700, Harry Katz wrote: > On Monday, August 30, 2004 1:15 PM, mazieres@gmail.com > [mailto:mazieres@gmail.com] wrote: > > > I guess I'm particularly curious what people think about > > virus notifications. (I care a lot about this question > > because at times I get thousands of messages a day telling me > > my mail has been infected with a virus, when of course I > > didn't send the virus, but rather the virus forged my email > > address.) It seems to me that if you get mail with a virus, > > the person whose machine is infected is most likely the PRA, > > not the MAIL-FROM address. Therefore, I would be tempted to > > configure my mail filter to send automatic notifications to > > the PRA, instead of the MAIL-FROM address. So the questions are: > > > > 1. Is there anything in the drafts to prevent me from sending > > such notifications to the PRA? > > No. However the PRA is neither a bounce address, nor a reply-to > address. And since the PRA only identifies the responsible sender of > the most recent "hop" I think you cannot assume the virus originates > from the PRA address. Okay, so basically is it the case that Sender ID (in its present form) isn't designed to help with these kinds of viruses and virus notifiers? At this point, is there any possible action the MARID group could take that would allow more intelligent virus rejection? I care a lot about this problem, and was hoping the outcome of this working group could help. If addressing the virus/bounce problem is no longer within scope, I don't want to dwell on the issue. However, I hope that at least people have such extensions in mind for future work. The fact that SPF2 records have a ver-ext field is a good sign. (However, I wonder why not make pra a required extension, instead of part of the version string, so that version strings like "spf2.0/blah,pra" would also be acceptable. Not very important, though, just means there will be a slight asymmetry if extensions become common.) > No. The PRA could easily be the address of an application that sends > but does not read mail. In fact, example 5.4 of the SUBMITTER spec > contemplates exactly this in it's use of a generic service account on > the SUBMITTER parameter. Okay, from the example, I didn't know what guest.services@email.hotel.com was supposed to mean. guest.services sounds kind of like a help desk address, so it could be interpreted to mean the help desk is essentially lending their address to guests. I guess I object to the term "generic account". If guest.services isn't a real mailbox, then I would argue it's not an account either. The reason I think this stuff is worth clarifying is for sites like rfc-ignorant.org that publish lists of domains that fail to supply mailboxes for various addresses like abuse and postmaster. I now gather that the intent of these drafts is that someone who uses an invalid mailbox (including a mailbox with an invalid domain) as a submitter is NOT in fact "RFC-ignorant." > > 3. Is the PRA required to accept mail from the empty envelope > > sender, even through any RFC1891-type DSNs/bounce messages > > should still be sent to the MAIL-FROM address? > > Not sure I understand this question. However, when an MTA sends a DSN > with MAIL FROM <>, the PRA would typically be something like > postmaster@example.com or mailer-daemon@example.com. See example 5.5 of > the SUBMITTER spec. Sorry, my question was about receiving, not sending bounces. Let me elaborate. Suppose I have two email addresses: me@myschool.edu me-bounces-2004@myschool.edu Because of the number of bounces I get from viruses, the address me@myschool.edu does not accept DSNs. Therefore, I always use me-bounces-2004@myschool.edu as the envelope sender. So far so good. The next question is which address I should use as the PRA. If I don't do anything, the PRA will be me@myschool.edu, which I would probably prefer. However, given that that address refuses DSNs, the question is whether there would be grounds for listing me in the rfc-ignorant RBL: http://www.rfc-ignorant.org/policy-dsn.php David From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 22:48: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 WAA25114 for ; Mon, 30 Aug 2004 22:48: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 i7V2Kcoi052061; Mon, 30 Aug 2004 19:20:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V2Kcue052060; Mon, 30 Aug 2004 19:20:38 -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 i7V2KcvQ052053 for ; Mon, 30 Aug 2004 19:20:38 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i7V2KCcE002648 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 30 Aug 2004 22:20:13 -0400 Date: Mon, 30 Aug 2004 22:20:12 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Roy Badami cc: Paul Iadonisi , Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) In-Reply-To: <16691.49492.811055.57958@giles.gnomon.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is all somewhat hypothetical, because I don't think the technology works yet, and won't be adopted widely enough for patent issues to be a concern. On Tue, 31 Aug 2004, Roy Badami wrote: > > >>>>> "Paul" == Paul Iadonisi writes: > > >> Even if Sender ID is incompatible with the GPL [2] -- and I'm > >> skeptical that it is except under the most extreme > >> interpretations -- > > Paul> And we have yet to see a convincing legal argument (or > Paul> *any* legal argument) from an attorney posted to this list. > Paul> I'd like to know what Anne Mitchell (on this list) thinks of > Paul> her legal analysis being called extreme by a non-lawyer. > > Ok, here's my argument: > > (1) Imagine you don't sign the patent license. In that case, the > license clearly has no effect on you. This is completely wrong. You are confusing a license with a contract. Patent laws in various countries prohibit use of patented technology and intentional violations have severe penalties, where unintentional violations have economic penalties and injunction. The details vary slightly from country to country but the variance is being addressed by the GATT Treaty and other accords for patent law harmonization. The broad outlines are pretty much the same throughout the developed world, and like it or not, it is getting more and more harmonized. > The question is, does the > existence of a patent claim prevent you from distributing under > the GPL anyway. Yes. That _could_ be infringement: http://www4.law.cornell.edu/uscode/35/271.html There is an exception but it is thin and untested. (US) patent law allows others to patent enhancements and improvements to existing patents. You cannot patent hypotheticals, so there is an exception for research. The original patent holder cannot prevent your patent filing by claiming you aren't licenced to use the patented technology necessary for your improvement, nor can they stop your research by injunction and refusal of a license. They can only prevent you from using it commercially (and non-commercially). Of course, the improvement holder can prevent them from using the improvement, so cross-licensing is a likely outcome. So, there is a little wiggle for research. However, I've spoken to lawyers who think that you cannot share patent infringing source code with others __at__all__Period. This is untested so far as I know. The main weakness is that there is often little argument that you _must_ share code in order to patent enhancements or perform research. There is some realistic argument, but certainly limited to research. Unlicenced __use__ is definitely out. Some years ago, I decided to have my company be a US mirror for OpenSSL (ssleay) before the patents expired. I did have some adverse legal contact, but no one wanted to litigate the issue and we continued to operate the mirror. Other factors were that we were licenced to use the patent, and that our mirroring certainly wasn't commercially beneficial, and arguably facilitated research. However, unlicenced __Users__ of the code would have no such defenses. I think it would have been difficult to resist a subpoena for the download logs, but that never came. Such logs aren't protected by the ECPA. It was a risky position to take because if the research exception and other arguments were rejected, we risked being found to be inducing infringement. This was similar to Kazaa, etc which were sued for inducing copyright violations. Fortunately, the courts found their activities to have enough non-infringing purpose that they weren't found to induce copyright infringement. What is important to understand is that certain things skate by on what amounts to technicalities. In general, that isn't the case. > It is possible to interpret the GPL such that it does, since you > are not in a position to offer rights to redistribute, although > it's not clear (to me) that this is what the GPL intends. No, this isn't right either. The GPL is a copyright statement and a permission with conditions. It is not a contract, and it covers only one aspect of the program. The GPL is orthogonal to the licensing of patents. A source code license does not equate to patent licence. A good example is the G.723 codec. The ITU provides a sample implmentation, but this cannot be used without a licence from the consortium that handles the licensing. > This may even be the correct interpretation of the GPL, however I > call it an 'extreme' position because under that position it is > also unlawful to distribute the Linux kernel, since it seems > likely from recent reparts that there are a substantial number of > patent claims against it. In fact, this is likely to be true of > most non-trivial GPL'd software. This is wrong. The GPL allows redistribution of source code. You can even charge money, so long as you provide source code for free, though you are not required to provide media for free. I am not aware of any patent claims against Linux in particular, (yet). We are rather expecting bogus software patents to be problem for free software in general. I have been advocating a legislative effort to exempt free software from software patent infringement. If you mean the SCO V. IBM suit, that concerns copyright, not patents. Last I heard, it didn't look too good for SCO on the merits, but of course, we probably won't know the real scoop on the merits until after the case is over. --Dean From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 23:27:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27445 for ; Mon, 30 Aug 2004 23:27: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 i7V31cQr054778; Mon, 30 Aug 2004 20:01: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 i7V31c3S054777; Mon, 30 Aug 2004 20:01:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V31ctp054760 for ; Mon, 30 Aug 2004 20:01:38 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [206.223.20.241] (24.152.199.18.res-cmts.eph.ptd.net[24.152.199.18]) by comcast.net (rwcrmhc13) with ESMTP id <2004083103013901500lhnmbe> (Authid: dhlii); Tue, 31 Aug 2004 03:01:39 +0000 Message-ID: <4133EA12.2010300@comcast.net> Date: Mon, 30 Aug 2004 23:01:38 -0400 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IETF-MXCOMP WG'" Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> In-Reply-To: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne P. Mitchell, Esq. wrote: > > This brings up a point which has been rolling around in the back of my > head for a few days. > > We simply _don't_ know what is in the claim. In any other area where > adoption of some program is to be impacted or encumbered in some way > which could cause either a legal liability or an inability to actually > implement on the part of the adopter - particularly such a potentially > widely used program - it is inconceivable that people would be even > considering adopting, or recommending, the program. In fact, if one > had a professional license, and recommended adoption of such a program > without a clear understanding of the encumberance, one could be guilty > of malpractice. But I digress...what has been rolling around in the > back of my head is this: Regardless of whether software should be patentable (or business methods, or ...) and regardless of the fact that trivial "improvements" should not be patentable no matter what. We live in a world where they are. Aparently we have no idea what parts of the current draft Microsoft thinks they have an IP claim on. While that is slightly scary from a practical perspective despite aparent IETF policies othewise, I think that must mean that Microsoft's claim and their proposed license should be given little weight. They are only slightly more significant that the possibility that some other entity also has IPR claims against parts of the current draft and has not come forward. Certainly there is much to fear, but fearing the mostly unknow is not significantly different from fearing the totally unknown, and almost equally pointless. While I would personally prefer that MARID adopt classic SPF and move forward - regardless of other merits it might have Caller-ID is Microsoft's baby and I personally beleive that if they truly wish to participate in the standards process they need to be open about their IPR. They can insist on whatever license they wish and the MARID group can decide if that is acceptable AFTER knowing what it is that is being licensed. I understand that may not be the policy of the IETF - though I beleive it should be. We are discussing changes to a core internet technology. I am not personally aware of any internet core technology that is encumbered in the way Microsoft is looking to encumber Sender-ID. I would advocate for moving forward with Classic SPF, because although I beleive that whatever Microsoft's IP that it is not likely to stand up to rigorous scrutiny, nor do I think it would be politically wise from Microsoft to force the issue - Microsoft has a reputation for being aggressively litigous in defense, but with few exceptions it has not really been offensively litigous. However I do not beleive the FOSS comunity would deploy Sender-ID if a patent did finally materialize, until that patent was nullified and that could take alot of valuable time. I beleive the FOSS community and a significant portion of the comercial SMTP comunity would deploy Classic SPF - even in the face of a possible Microsoft patent threat, it is easier and clearer to argue that SPF is prior art. There is also a moral and ethical difference, between going forward with SPF and going forward with Sender-ID in the face of a possible claim from Microsoft. Regardless of the validity of Microsoft's patent claim a fight over SPF would be fighting with Microsoft for trying to patent what somebody else developed. Fighting over Sender-IP would appear more like trying to steal something from Microsoft. I would love to see a result that included everyone. Sender-ID, with Microsoft on board, and FOSS on board would likely be the most effective solution. But the FOSS comunity is not going to sacrifice core principles for that and thus far it appears that Microsoft has drawn their line in the sand too. Absent Microsoft putting forth a License that is compatible with FOSS licenses, or just contributing their IPR freely, I think Sender-ID should die here. That is a bad choice - just better than the rest. I would rather no standard than one that is "owned" by anyone no matter how good the terms of ownership. Being forced to choose who to exclude I would choose to exclude Microsoft before excluding the FOSS community. Though success without both is questionable. While I personally beleive there is a public value served by killing any patent and a high public value for killing stupid patents, there are other institutions that serve that purpose. While I think many of the IETF's policies on IPR are poor, in this particular instance wide and quick acceptance is critical and the more IPR issues there are the longer that will take. From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 23:45: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 XAA28444 for ; Mon, 30 Aug 2004 23:45: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 i7V3OHR6057009; Mon, 30 Aug 2004 20:24:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V3OHYZ057008; Mon, 30 Aug 2004 20:24:17 -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 i7V3OGYS057000 for ; Mon, 30 Aug 2004 20:24:16 -0700 (PDT) (envelope-from dhlii@comcast.net) Received: from [206.223.20.241] (24.152.199.18.res-cmts.eph.ptd.net[24.152.199.18]) by comcast.net (sccrmhc13) with ESMTP id <2004083103241801600h99uee> (Authid: dhlii); Tue, 31 Aug 2004 03:24:18 +0000 Message-ID: <4133EF60.6030008@comcast.net> Date: Mon, 30 Aug 2004 23:24:16 -0400 From: "David H. Lynch Jr." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: In favour of Sender ID References: <16687.55940.84075.510780@giles.gnomon.org.uk> <16688.33456.768519.664243@giles.gnomon.org.uk> <20040828140114.GC3684@dumbo.pobox.com> <16688.52538.55612.753445@giles.gnomon.org.uk> <1093720180.7023.148.camel@va.local.linuxlobbyist.org> <16691.49492.811055.57958@giles.gnomon.org.uk> In-Reply-To: <16691.49492.811055.57958@giles.gnomon.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy Badami wrote: >Ok, here's my argument: > >(1) Imagine you don't sign the patent license. In that case, the > license clearly has no effect on you. The question is, does the > existence of a patent claim prevent you from distributing under > the GPL anyway. > > It is possible to interpret the GPL such that it does, since you > are not in a position to offer rights to redistribute, although > it's not clear (to me) that this is what the GPL intends. > > This may even be the correct interpretation of the GPL, however I > call it an 'extreme' position because under that position it is > also unlawful to distribute the Linux kernel, since it seems > likely from recent reparts that there are a substantial number of > patent claims against it. In fact, this is likely to be true of > most non-trivial GPL'd software. > >(2) Now imagine that you _have_ signed the Sender ID license. The > Sender ID license doesn't require you to place any restrictions on > the recipient of the software, as far as I can see the situation > with GPL compliance is no different to (1) > > > While my understanding of the principles behind the GPL makes it perfectly clear to me that most any license is going to run afoul of it. I do not see how it is my understanding of the GPL or yours that matter's. What matters is: whether the authors of the GPL or other FOSS license beleive they have a problem, whether the authors of FOSS licensed MTA's beleive they have a problem whether those distributing software under the GPL or other FOSS license beleive there is a problem. This is not a game - atleast not for those of us who are not lawyers. Finding a "loophole" is something well meaning people do after they have unintentionally gotten themselves into a bind. I would like to sucker Microsoft into a fight they can't win, but trying to push a standard into that position is irresponsible. From owner-ietf-mxcomp@mail.imc.org Mon Aug 30 23:59: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 XAA29205 for ; Mon, 30 Aug 2004 23: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 i7V3aF5v057942; Mon, 30 Aug 2004 20:36: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 i7V3aFHq057940; Mon, 30 Aug 2004 20:36:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V3aAuF057908 for ; Mon, 30 Aug 2004 20:36:11 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7V3Zl77021834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 Aug 2004 23:36:08 -0400 Subject: Re: Re: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages From: Mark Shewmaker To: MARID Cc: mazieres@gmail.com In-Reply-To: <94df60cf0408301735444d4a45@mail.gmail.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> <1093650303.3782.3839.camel@localhost.localdomain> <72A8ABAC-F95A-11D8-881C-000A95B3BA44@hxr.us> <1093906313.3463.8385.camel@localhost.localdomain> <94df60cf0408301735444d4a45@mail.gmail.com> Content-Type: text/plain Message-Id: <1093923481.3782.8749.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 23:38:01 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Mon, 30 Aug 2004 23:36:09 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-08-30 at 20:35, mazieres@gmail.com wrote: > I just have a couple of comments. Great! > On Mon, 30 Aug 2004 18:51:53 -0400, Mark Shewmaker wrote: > > This vulnerability exists if local policy settings allow for a situation > > in which all of the following are true: > > > > - An incoming message was sent to multiple recipients, > > - The message will ultimately be considered deliverable to some > > subset of its intended recipients, > > - The message will also be ultimately be considered undeliverable > > to some other subset of the initial recipients, and > > - The ultimate determination as to per-recipient deliverability > > cannot be made until after the SMTP transaction accepts the > > message for delivery. > > The last condition is not quite correct, because you can make the > determination before replying to the "." at the end of the DATA > command. Not an ultimate per-recipient determination, unless the answer is reject-for-everyone. > Thus, I would recommend some wording along the lines of, > "The ultimate determination as to per-recipient deliverability cannot > be made before the SMTP DATA command." I'm under the impression that those two wordings are currently equivalent, in that giving a 250 response to the end of SMTP data means that you've accepted the message for delivery. The reason I went with more convoluted wording that probably comes to the same thing at the moment was merely to be compatible with any future SMTP extension that allows for something I've long wanted--a way to do post-DATA per-recipient rejects. So it's sort of a personal bias that was at the root of the convoluted wording. Begin Minor rant: (I hope I'm not stepping too far out of bounds ----------------- by posting this skim-able rant here.) If there had been a requirement back in RFC821 for both the client and server MTAs to support pre- and post-DATA per-recipient rejects, then we'd not have this vulnerability at all, as MTAs could do separate and incompatible body checks that differ per recipient, and yet still reject for individual recipients depending on their individual settings of acceptable body content. Unfortunately, not only do we not currently have such an extension at all, we especially don't have one that can be considered from a practical point of view as fundamental requirement for SMTP servers. So for the time being, in order to avoid this security vulnerability, IMHO MTA's will need to implement this sort of bothersome, burdensome workaround. But were an extension supporting post-data per-recipient rejects to come into being, I would imagine that the larger volume MTAs would put it in deployment within a couple years, meaning that from a practical point of view the workaround would become much less burdensome, only needing to be used when communicating with MTAs that have not (yet) been upgraded, or MTAs that are trying to perform an active attack, the latter presumably learning to give up upon getting an EHLO response showing support of such an extension. End minor rant: --------------- So while the implementation of such an extension is beyond the scope of Sender ID, (though perhaps there are interested parties here that would want to more appropriately push for such an extension), I was wanting to use wording that was generic enough to still "fit" were such an extension ever to come about and be put into use. Although I don't see much talk of such an extension anywhere, I tend to think it will come about at some point, and so I wanted to workaround's wording to be compatible with the sort of thing I expect to later exist. But a less convoluted way of wording it would be great, or, if folks think I'm being overly picky by wanting compatibility with something that doesn't yet exist, your wording is fine too. > > A clever attacker can take advantage of this vulnerability by using any > > machine with detectably differing local policy settings as an apparent > > source of the attacker's forged DSNs. > > How about dropping the word "clever." From the point of view of a > standards document, the attacker's intellect is irrelevant. (Plus, I > would argue this attack isn't really all that clever, particularly > once it's already been described in a standards document.) Absolutely agreed. Thanks. > > An MTA can completely avoid becoming a participant in a DSN attack in > > all cases by: > > > > Whenever all of the following is true: > > > > - An incoming message is addressed to multiple participants. > > > > - Those participants have local policy settings that, > > given the context of the specifics of the MTA transaction, > > mean that a per-recipient final determination of delivery > > cannot be made until after the message has been fully accepted. > > > > - The MTA has not positively validated the MAIL FROM address, > > What exactly does positively validated the MAIL FROM address mean, > unless you have something like SPF classic? It means whatever the admin of the MTA wants it to mean. :-) Or even more vaguely, it means whatever that admin wants to use as a "good enough" algorithm for bouncability. :-) I don't think it's a good idea to specify any particular algorithm. While an SPF pass, an SES CBV verification, and a BATV CBV verification would presumably all work well, as would a full set of Unified-SPF tests that included MAIL FROM tests, and as would your excellent idea of a close-enough test of SenderID testing the MAIL FROM, I'd still rather not suggest any specific test--we don't now know what the "winning" methods of bouncability verification will turn out to be, and there's no need to tie anything down to something that may well become obsolete in six months. Testing the validity of a bounce address is a problem that's theoretically uncoupled with the problem of testing the validity of the PRA, so I don't want a document that's concerned with PRA tests to have a security workaround to reference or require specific bounce address tests. It's a separate issue that the admin will have to handle, well, separately. I just want to mention that for any SMTP transaction where they think they've validated the bounce address, that this workaround isn't necessary. > Also, I would argue that you don't need to positively validate the > MAIL FROM address. All you really need to know is that whoever would > get a DSN is somehow involved in the sending of the message. > > Thus, one valid test would be to run a tentative check under the > assumption that the MAIL FROM address is actually the PRA. If the > test returns anything other than Pass or None, of course you don't > reject the mail, but instead, proceed as you outlined below, including > returning a 4.7.6 for multiple recipients. That's an excellent idea. Even though I'm personally biased towards Unified SPF, thinking the PRA tests and MAIL FROM tests should be able to be scoped differently if the domain wants, etc., and even though this wouldn't be using the records quite as intended, from a practical point of view I'd be fine with doing that test as a "good enough" test myself. I'm just still not sure if the warning/workaround mentioned should refer to any specific way of testing the MAIL FROM address. > In fact, while I don't fully understand the motivation for having > different PRA and MAIL-FROM addresses, I gather from previous messages > that the people who want this the most are large banks that send out > bulk mail. Somewhat off-topic, but here's one reason: There are some legal requirements to send some EFT notifications, (and things like those yearly account-rules-and-conditions-and-information things), that can be satisfied by emails if you then send paper documents if the email bounces. I can see where companies might want to outsource the sending of notifications like this, trusting the outsourced sender to notify them of rejects, but yet possibly wanting to handle the bounce processing separately. (Or perhaps the outsourced company might want to do that--having a bounce-handling machine that is set up to handle bounces for a week after the mail is sent, which might be long after the originating machine knows anything about the bulk mail sending session.) -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 01:14: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 BAA05374 for ; Tue, 31 Aug 2004 01:14: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 i7V4nrXE063079; Mon, 30 Aug 2004 21:49: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 i7V4nrMb063078; Mon, 30 Aug 2004 21:49:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V4nqtF063045 for ; Mon, 30 Aug 2004 21:49:52 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so223420rnk for ; Mon, 30 Aug 2004 21:49:54 -0700 (PDT) Received: by 10.38.83.80 with SMTP id g80mr687281rnb; Mon, 30 Aug 2004 21:49:54 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Mon, 30 Aug 2004 21:49:54 -0700 (PDT) Message-ID: <94df60cf040830214924086f53@mail.gmail.com> Date: Tue, 31 Aug 2004 00:49:54 -0400 From: Reply-To: To: Mark Shewmaker Subject: Re: Re: Re: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages Cc: MARID In-Reply-To: <1093923481.3782.8749.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> <1093650303.3782.3839.camel@localhost.localdomain> <72A8ABAC-F95A-11D8-881C-000A95B3BA44@hxr.us> <1093906313.3463.8385.camel@localhost.localdomain> <94df60cf0408301735444d4a45@mail.gmail.com> <1093923481.3782.8749.camel@localhost.localdomain> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 30 Aug 2004 23:38:01 -0400, Mark Shewmaker wrote: > > > - The ultimate determination as to per-recipient deliverability > > > cannot be made until after the SMTP transaction accepts the > > > message for delivery. > > > > The last condition is not quite correct, because you can make the > > determination before replying to the "." at the end of the DATA > > command. > > Not an ultimate per-recipient determination, unless the answer is > reject-for-everyone. Ah, I see the confusion. By "make the determination", I read decide whether or not each recipient wants to accept the mail. I think what you meant is notify the client of whatever that decision is. Basically imagine the following session: ==> rcpt to: <== 250 ok ==> rcpt to: <== 250 ok ==> data <== 354 ==> [mail message] ==> . Now the MTA has to decide what to reply to the "." at the end of the data command. At this point, even though the SMTP transaction is not yet complete (still awaiting a reply from the MTA), the MTA has the entire message body, and thus can certainly determine that user a wants the mail, and user b doesn't want the mail. The determination is made before the end of the SMTP transaction. The problem is there is no way to notify the client. So I think it's clearer to say you can't determine per-recipient deliverability at the time of the RCPT command, and even if you can determine it during the DATA command, without another SMTP extension it is not possible to reject the message for a subset of recipients. > > In fact, while I don't fully understand the motivation for having > > different PRA and MAIL-FROM addresses, I gather from previous messages > > that the people who want this the most are large banks that send out > > bulk mail. > > Somewhat off-topic, but here's one reason: There are some legal > requirements to send some EFT notifications, (and things like those > yearly account-rules-and-conditions-and-information things), that can be > satisfied by emails if you then send paper documents if the email > bounces. I can see where companies might want to outsource the sending > of notifications like this, trusting the outsourced sender to notify > them of rejects, but yet possibly wanting to handle the bounce > processing separately. (Or perhaps the outsourced company might want to > do that--having a bounce-handling machine that is set up to handle > bounces for a week after the mail is sent, which might be long after the > originating machine knows anything about the bulk mail sending session.) Sorry, I know this is a bit off topic, but I really wish I understood this point better. I understand that the bank and the sender are two different institutions. I also understand that whatever part of the mail is authenticated should end with "bank.com", so that MUAs can display a golden padlock or somesuch. What do you mean by "handling bounce processing separately"? Presumably this is the major function of the outsourced sender, so the sender is getting the bounces. So in a PRA-based scheme, the bank does something like: bank.com IN SPF2 "spf2.0/pra ... include:spf2.sender.com -all" Then mail would go out with: Mail-From: bank-bounce-1234@sender.com From: eft-notifications@bank.com In a mail-from based scheme, you would need both an SPF or TXT record, and an MX record (though a single CNAME would work, too). Something like: sender.bank.com IN MX 10 bounces.sender.com sender.bank.com IN TXT "v=spf1 redirect=spf.sender.com" Now the mail might go out: Mail-From: notification-1234@sender.bank.com From: eft-notifications@sender.bank.com Are these roughly the scenarios you had in mind? If so, is there really a huge difference between PRA and mail-from? Is the big objection just the fact that the mail comes from "sender.bank.com" instead of just "bank.com"? In practice, it seems like you might want to do that anyway if you have multiple outsourced senders, because a screw-up by sender.com, say if spf2.sender.com doesn't exist, would throw an exception and mess up SPF processing for all subsequent mechanisms, possibly interfering with other senders. Maybe what we need is a global modifier "display=domain" that says what domain to display in the golden padlock. Obviously domain must be a suffix of the current domain, but it could be a strict suffix to avoid confusing users with extra clutter like the "sender" in "sender.bank.com." Something like: sender.bank.com IN TXT "v=spf1 display=%{d2} redirect=spf.sender.com" It just seems like mail-from-based schemes could be hugely more beneficial to virus filtering and joe-job prevention than PRA-based schemes, while I don't really see a comparable (or any) advantage to PRA-based schemes. Probably I'm just missing the actual "killer" scenario that really requires PRA. David From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 01:40: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 BAA06486 for ; Tue, 31 Aug 2004 01:40: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 i7V5C6bG067837; Mon, 30 Aug 2004 22:12:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V5C6FT067836; Mon, 30 Aug 2004 22:12:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V5C5rw067828 for ; Mon, 30 Aug 2004 22:12:05 -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); Mon, 30 Aug 2004 22:12:12 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Aug 2004 22:12:13 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 22:12:13 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 22:12:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DOC-BUG: permitted use of PRA/submitter address Date: Mon, 30 Aug 2004 22:12:11 -0700 Message-ID: Thread-Topic: DOC-BUG: permitted use of PRA/submitter address thread-index: AcSO/zG63O3OEcYKTlaB7TDAWxKgXgAF/7eA From: "Harry Katz" To: , "MARID" X-OriginalArrivalTime: 31 Aug 2004 05:12:12.0188 (UTC) FILETIME=[12944DC0:01C48F19] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7V5C5rw067830 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, August 30, 2004 7:07 PM, mazieres@gmail.com [mailto:mazieres@gmail.com] wrote: > Okay, so basically is it the case that Sender ID (in its > present form) isn't designed to help with these kinds of > viruses and virus notifiers? At this point, is there any > possible action the MARID group could take that would allow > more intelligent virus rejection? I care a lot about this > problem, and was hoping the outcome of this working group could help. I think Sender ID will help with viruses, though perhaps not in the way you're suggesting. As I understand it, many viruses today are tranmitted from infected zombie machines, often home computers connected via cable modem or DSL lines. The IP addresses of these home computers will not likely be listed by their owning ISPs as legitimate sources of outbound e-mail. Thus a receiver performing the Sender ID check should be able to detect "foul play" and reject the message, presumably with a 5xx type return code rather than by sending an actual bounce message. > > Not sure I understand this question. However, when an MTA > sends a DSN > > with MAIL FROM <>, the PRA would typically be something like > > postmaster@example.com or mailer-daemon@example.com. See > example 5.5 > > of the SUBMITTER spec. > > Sorry, my question was about receiving, not sending bounces. > Let me elaborate. Suppose I have two email addresses: > > me@myschool.edu > me-bounces-2004@myschool.edu > > Because of the number of bounces I get from viruses, the > address me@myschool.edu does not accept DSNs. Therefore, I > always use me-bounces-2004@myschool.edu as the envelope sender. > > So far so good. The next question is which address I should > use as the PRA. If I don't do anything, the PRA will be > me@myschool.edu, which I would probably prefer. However, > given that that address refuses DSNs, the question is whether > there would be grounds for listing me in the rfc-ignorant RBL: > > http://www.rfc-ignorant.org/policy-dsn.php > Thanks for clarifying. Bounces go to the return-path address, not to the PRA. If you want bounces to go to a specific address you need to set the MAIL FROM address to the desired address when you send mail. From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 02:00: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 CAA07284 for ; Tue, 31 Aug 2004 02:00: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 i7V5c6Jw079443; Mon, 30 Aug 2004 22:38:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V5c6n9079442; Mon, 30 Aug 2004 22:38:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V5c5jT079377 for ; Mon, 30 Aug 2004 22:38:06 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so228236rnk for ; Mon, 30 Aug 2004 22:38:08 -0700 (PDT) Received: by 10.38.171.20 with SMTP id t20mr1376017rne; Mon, 30 Aug 2004 22:38:08 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Mon, 30 Aug 2004 22:38:08 -0700 (PDT) Message-ID: <94df60cf04083022383d5bd9f7@mail.gmail.com> Date: Tue, 31 Aug 2004 01:38:08 -0400 From: Reply-To: To: Harry Katz Subject: Re: DOC-BUG: permitted use of PRA/submitter address Cc: MARID In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 30 Aug 2004 22:12:11 -0700, Harry Katz wrote: > On Monday, August 30, 2004 7:07 PM, mazieres@gmail.com > [mailto:mazieres@gmail.com] wrote: > > > Okay, so basically is it the case that Sender ID (in its > > present form) isn't designed to help with these kinds of > > viruses and virus notifiers? At this point, is there any > > possible action the MARID group could take that would allow > > more intelligent virus rejection? I care a lot about this > > problem, and was hoping the outcome of this working group could help. > > I think Sender ID will help with viruses, though perhaps not in the way > you're suggesting. As I understand it, many viruses today are > tranmitted from infected zombie machines, often home computers connected > via cable modem or DSL lines. The IP addresses of these home computers > will not likely be listed by their owning ISPs as legitimate sources of > outbound e-mail. Thus a receiver performing the Sender ID check should > be able to detect "foul play" and reject the message, presumably with a > 5xx type return code rather than by sending an actual bounce message. I'm not sure I see how the owning ISP of the virus-infected machine comes into play, as the problem is that the machines are forging mail in my name. (If viruses all claimed to be from the owning ISP, I'd already be a lot happier.) It's true that if I publish an SPF2 record, it would probably help with today's viruses, because the From: address would be the PRA, and thus would be goverened by my SPF2 record. However, if Sender-ID were adopted, I'm sure the virus writers would just start including a line like: Resent-Sender: virus@com in each email. This would guarantee a SenderID result of None (since com has NS but no TXT/SPF2 records), and thus for sites that don't do virus checking before responding to the DATA command, would still result in a flood of bounce messages to me. From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 02:07: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 CAA15282 for ; Tue, 31 Aug 2004 02: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 i7V5gSsn082319; Mon, 30 Aug 2004 22:42: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 i7V5gSuY082318; Mon, 30 Aug 2004 22:42:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (adsl-69-225-172-218.dsl.pltn13.pacbell.net [69.225.172.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V5gSfO082297 for ; Mon, 30 Aug 2004 22:42:28 -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 861721D651 for ; Mon, 30 Aug 2004 22:42:35 -0700 (PDT) Date: Mon, 30 Aug 2004 22:42:35 -0700 From: Greg Connor To: MARID Subject: Re: DOC-BUG: permitted use of PRA/submitter address Message-ID: <21626487.1093905754@[192.168.0.2]> In-Reply-To: <94df60cf04083019063ef33297@mail.gmail.com> References: <94df60cf04083019063ef33297@mail.gmail.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 --mazieres@gmail.com wrote: > > On Mon, 30 Aug 2004 17:56:18 -0700, Harry Katz > wrote: >> On Monday, August 30, 2004 1:15 PM, mazieres@gmail.com >> [mailto:mazieres@gmail.com] wrote: >> >> > I guess I'm particularly curious what people think about >> > virus notifications. (I care a lot about this question >> > because at times I get thousands of messages a day telling me >> > my mail has been infected with a virus, when of course I >> > didn't send the virus, but rather the virus forged my email >> > address.) It seems to me that if you get mail with a virus, >> > the person whose machine is infected is most likely the PRA, >> > not the MAIL-FROM address. Therefore, I would be tempted to >> > configure my mail filter to send automatic notifications to >> > the PRA, instead of the MAIL-FROM address. So the questions are: >> > >> > 1. Is there anything in the drafts to prevent me from sending >> > such notifications to the PRA? >> >> No. However the PRA is neither a bounce address, nor a reply-to >> address. And since the PRA only identifies the responsible sender of >> the most recent "hop" I think you cannot assume the virus originates >> from the PRA address. To add to what Harry is saying, remember that the PRA can often be an address affiliated with the receiver's forwarding arrangement, and nothing to do with the sender at all. For example, if all my mail is forwarded via pobox.com, then the authenticated PRA will probably be gconnor@pobox.com for all my mail, even mail that was received without an authenticated PRA by pobox. For this reason (and taking into account what Harry said too) I would not want Sender ID to have anything to do with where notifications go (except to say "do not send notifications to PRA that should not be used for DSN, virus warnings, auto-replies, vacation messages or whatever). > Okay, so basically is it the case that Sender ID (in its present form) > isn't designed to help with these kinds of viruses and virus > notifiers? At this point, is there any possible action the MARID > group could take that would allow more intelligent virus rejection? I > care a lot about this problem, and was hoping the outcome of this > working group could help. > > If addressing the virus/bounce problem is no longer within scope, I > don't want to dwell on the issue. However, I hope that at least > people have such extensions in mind for future work. The fact that > SPF2 records have a ver-ext field is a good sign. (However, I wonder > why not make pra a required extension, instead of part of the version > string, so that version strings like "spf2.0/blah,pra" would also be > acceptable. Not very important, though, just means there will be a > slight asymmetry if extensions become common.) I think that Sender ID will be good for detecting and blocking spoofed messages (including viruses) but that should not extend to providing accurate trace-back. At least not in its current form. The current rev of Sender ID only identifies one PRA and is focused on a single hop. It doesn't define a way to trace back the chain of hops all the way. However, I could see something like that happening in a future extension. For example, if (the PRA is checked and valid) *and* (PRA is an entity that the receiver knows and trusts) then { scan for the Received lines added by the trusted forwarder find the previous IP address recorded by that agent scan the message from that point down to find/validate 2nd PRA } I am willing to bet that a large chunk of mail I receive could be validated this way to verify the From: or Sender: even if the Sender ID would not otherwise work this way. BUT all this hinges on how well you trust your agents (such as mailing lists, which are acting as agents for the sender *and* the receiver :) so it's probably too much to ask the current rev of Sender ID to work this way. Even if we do all that we probably still don't have enough info to trace back a virus to its true owner, especially not a deliberately forged one. But hopefully blocking them is added incentive for people to publish their Sender ID info so that their domain won't be abused as often... > >> > 3. Is the PRA required to accept mail from the empty envelope >> > sender, even through any RFC1891-type DSNs/bounce messages >> > should still be sent to the MAIL-FROM address? >> >> Not sure I understand this question. However, when an MTA sends a DSN >> with MAIL FROM <>, the PRA would typically be something like >> postmaster@example.com or mailer-daemon@example.com. See example 5.5 of >> the SUBMITTER spec. > > Sorry, my question was about receiving, not sending bounces. Let me > elaborate. Suppose I have two email addresses: > > me@myschool.edu > me-bounces-2004@myschool.edu > > Because of the number of bounces I get from viruses, the address > me@myschool.edu does not accept DSNs. Therefore, I always use > me-bounces-2004@myschool.edu as the envelope sender. > > So far so good. The next question is which address I should use as > the PRA. If I don't do anything, the PRA will be me@myschool.edu, > which I would probably prefer. However, given that that address > refuses DSNs, the question is whether there would be grounds for > listing me in the rfc-ignorant RBL: > > http://www.rfc-ignorant.org/policy-dsn.php > > David I don't have a direct answer to this, but remember that the PRA *always* appears in some 2822 header before it is picked out by this algorithm. So, if you use some non-functioning address in your outgoing mail as either From:, Sender:, Resent-From: or Resent-Sender: there may already be rules that cover those types of uses. My opinion is that Sender ID should probably not make any attempt to say whether this is legal or not, because it would probably be different depending on which header was the source of the PRA. But, if there are already some rules in 2822 or 2476 that say stuff about these headers, we could make a reference to them. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 03:26:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25527 for ; Tue, 31 Aug 2004 03:26: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 i7V6trbt011799; Mon, 30 Aug 2004 23:55: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 i7V6trI4011798; Mon, 30 Aug 2004 23:55:53 -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 i7V6tq0u011762 for ; Mon, 30 Aug 2004 23:55:52 -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 i7V6tkjH012903 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 30 Aug 2004 23:55:47 -0700 Received: from [10.0.6.136] ([12.45.39.199]) (authenticated bits=0) by righton.sendmail.com (8.13.1.Beta1/8.13.1.Beta1) with ESMTP id i7V6tjOA076100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Aug 2004 23:55:46 -0700 (PDT) Message-ID: <41341DD0.7010008@sendmail.com> Date: Mon, 30 Aug 2004 23:42:24 -0700 From: Rand Wacker User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Sendmail releases open source Sender ID milter for testing 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 As part of our broad-reaching effort to spur the testing and eventual broad adoption of sender-based email authentication to address fraud and spam in email, Sendmail, Inc. is releasing an open source implementation of the IETF's Sender ID specification for testing on the Internet. This implementation, part of the Sendmail Messaging Integrity Pilot Program, utilizes the milter interface to plug directly into the sendmail MTA. Sender ID is a standards-track proposal that merges Meng Wong's SPF and Microsoft's Caller ID for email. Authorizations records are published in DNS in an SPF-like format, and then used to validate user-visible message headers using the Caller ID "Purported Responsible Address". This sid-milter release implements the marid-protocol and marid-core draft standards, leaving the marid-submitter SMTP Extension to be implemented directly by the sendmail MTA. To speed the adoption of sender-based messaging authentication schemes, Sendmail is aggressively testing these implementations in the Messaging Integrity Pilot Program. The goals of this program are to: * Deploy and test milter-based implementations of sender authentication schemes like Sender ID and DomainKeys. * Encourage diverse user communities to thoroughly test different sender authentication approaches using real-world use cases. * Share and publish results in a community forum purpose-built to share ideas about email authentication. Sendmail is actively seeking participants and feedback for this Pilot Program. For more information about how you or your organization can get involved in piloting the next generation in fraud and spam protection software, please visit: http://sendmail.net/ The milter for testing Sender ID is available at: http://sendmail.net/sid-milter/ The MARID Working Group charter, along with links to all Sender ID related proposals is at: http://www.ietf.org/html.charters/marid-charter.html The SPF web site is located at: http://spf.pobox.com/ Microsoft's Sender ID page is located at: http://www.microsoft.com/senderid From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 04:46: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 EAA29419 for ; Tue, 31 Aug 2004 04:46:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V8NTQt033881; Tue, 31 Aug 2004 01:23: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 i7V8NTZV033880; Tue, 31 Aug 2004 01:23:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V8NSEd033850 for ; Tue, 31 Aug 2004 01:23:28 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1C23vI-0009by-00 for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 09:23:24 +0100 Message-ID: <1b5f01c48f33$6a7ce2d0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: TECH-OMISSION: Testing following SMTP message acceptance Date: Tue, 31 Aug 2004 09:20:44 +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 In draft-ietf-marid-core-03.txt change the second paragraph of Section 3 to read: vvvvvvvvvvvvvv This question will usually be asked by an SMTP server as part of deciding whether to accept an incoming mail message. However this question could also be asked later, after the server has accepted the message, or by a different party. An MUA, for example, could use the result of this question to determine how to file or present a message. ^^^^^^^^^^^^^^ and insert immediately below that paragraph a new paragraph... vvvvvvvvvvvvvvv Where the question is asked by an SMTP MTA server after that MTA has accepted the message for onward transmission, the server shall itself generate and send non-delivery messages ( in accordance with RFC3464) derived from the rejection codes detailed in section 5 below. ^^^^^^^^^^^^^^^^^^^ and add a normative reference to RFC3464 in section 10.1 ======================= Rationale The existing draft describes tests as being undertaken during the RFC 2811 message-acceptance process. There may be MTAs in which it is desired to accept the message when offered, and then undertake the tests at a later time, perhaps after reputation sources have been consulted and other tests applied. The current draft leaves MTA behaviour in post-acceptance tests undefined. It seems right-and-proper to require that the overall handling of a message by the MTA-chain be consistent, regardless of whether pre- or post-acceptance testing is chosen. These proposed changes to the draft are intended to ensure that, so long as the message is still within the SMTP transportation process, coherent behaviour is exhibited, regardless of when the Sender-ID test is actually undertaken. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 05:26: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 FAA01297 for ; Tue, 31 Aug 2004 05:26: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 i7V953sY043595; Tue, 31 Aug 2004 02:05: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 i7V953h8043594; Tue, 31 Aug 2004 02:05:03 -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 i7V9527p043566 for ; Tue, 31 Aug 2004 02:05: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 1C24ZY-000Iok-00; Tue, 31 Aug 2004 10:05:00 +0100 Message-ID: <1b9b01c48f39$3a3387e0$0200000a@ringo> From: "Chris Haynes" To: "Daryl Odnert" , "IETF MARID WG" References: Subject: Re: TECH-OMISSION: Security vulnerability - Malicious DSN attack s Date: Tue, 31 Aug 2004 10:02:12 +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 RE: TECH-OMISSION: Security vulnerability - Malicious DSN attacksHello again Daryl, Daryl Odnert commented: > > Hello Chris, > I still strongly disagree that the vulnerability you are concerned > about is made worse by Sender ID. In this TECH-OMISSION I am just asking that the _fact_ of this distinct vulnerability be recorded in the draft. My personal judgements about how bad it is remain as expressed in my ealier DEPLOY threads. > As you've explained, Sender ID > does add a new way to get a recipient's MTA to reject a message. > But there are already several ways to make this happen, It's my belief that when a distinct security vulnerability is determined, it MUST be recorded. Suppose someone found a solution to the other, related vulnerabilities (e.g. the 'non-existent recipient'). This one would still remain. > so I just > don't see this as a fair criticism of Sender ID. Again, I don't see the full and accurate recording of security vulnerabilities as being 'fair' or 'unfair'; these are factual assertions - to be proved or disproved. There is another, more positive comment I can make. This MARID activity is part of a sysematic sweep through the entire mail system to counteract the many abuses that have become prevalent. It's my belief that, as we uncover and analyse problems we should record them, recognise them within the RFC process, and then produce documented, tested solutions to them. So even if the earlier, related vulnerabilities have not yet been formally recorded, that's no reason to ignore ones we do come across in the course of this clean-up operation. > However, in the interest of clarity, I think that in your example, > you need to make it explicit that the participant P does not perform > any Sender ID test before accepting responsibility for relaying the > message from A, Actually, I chose my words very carefully, to describe 'both' situations - test failure during and after SMTP phase. I know that it is a different host which actually sends the bounce in each case, but the overall effect is the same (with the one difference in whose reputation is possibly suffering by being the actual sender of the bounce). > nor does it add any RFC 2822 headers that would change > the Purported Responsible Address of the message. I said that the attack is conditional on the attacker being able to chose a PRA which will certainly fail. Changes in PRA along the chain which mean the message test no longer fails are therefore outside of the scope of this vulnerability. > I think you also need to make it clear that P would have to be > configured such that it accepts mail from submitter's IP address where > the MAIL FROM address is V and where the recipient address is in a different > domain (R) that might perform a Sender ID test on inbound SMTP mail. Ah! I think we are getting stuck on this issue of when in the SMTP process cycle the Sender-ID test is undertaken. In preparing for this reply I re-read the 'core' draft and realised that they have left undefined the behaviour if the test is undertaken in an MTA _after_ it has accepted the message for onward transmission. I have therefore just posted a TECH-OMISSION to the list correcting this omission. This message (and my original starting this thread) should be read as if I had _previously_ posted that correction, so that testing before and after SMTP message acceptance produced the same externally-visible behaviour (even though the bounce may be send by different hosts in the two cases). > Normally, only MTAs that are operated by (or trusted by) V for outbound > SMTP mail processing would be configured this way. Therefore, the attack > is only likely to occur if it can be launched from an IP address that > normally submits mail from V to P. I'm very sorry, I just don't understand this point. Dues it change in the light of my comments / draft amendments above? > Daryl Odnert > Tumbleweed Communications > Redwood City, California > Chris Haynes From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 05:42: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 FAA01873 for ; Tue, 31 Aug 2004 05:42:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9KgZ2046141; Tue, 31 Aug 2004 02:20: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 i7V9Kgc7046140; Tue, 31 Aug 2004 02:20:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9KeDL046113 for ; Tue, 31 Aug 2004 02:20:41 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:18:27 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 31 Aug 2004 10:42:01 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 10:44:26 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 Aug 2004 10:36:07 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V8NTQt033881; Tue, 31 Aug 2004 01:23: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 i7V8NTZV033880; Tue, 31 Aug 2004 01:23:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V8NSEd033850 for ; Tue, 31 Aug 2004 01:23:28 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1C23vI-0009by-00 for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 09:23:24 +0100 Message-ID: <1b5f01c48f33$6a7ce2d0$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" Subject: TECH-OMISSION: Testing following SMTP message acceptance Date: Tue, 31 Aug 2004 09:20:44 +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 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 31 Aug 2004 08:36:08.0130 (UTC) FILETIME=[8FC4E220:01C48F35] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In draft-ietf-marid-core-03.txt change the second paragraph of Section 3 to read: vvvvvvvvvvvvvv This question will usually be asked by an SMTP server as part of deciding whether to accept an incoming mail message. However this question could also be asked later, after the server has accepted the message, or by a different party. An MUA, for example, could use the result of this question to determine how to file or present a message. ^^^^^^^^^^^^^^ and insert immediately below that paragraph a new paragraph... vvvvvvvvvvvvvvv Where the question is asked by an SMTP MTA server after that MTA has accepted the message for onward transmission, the server shall itself generate and send non-delivery messages ( in accordance with RFC3464) derived from the rejection codes detailed in section 5 below. ^^^^^^^^^^^^^^^^^^^ and add a normative reference to RFC3464 in section 10.1 ======================= Rationale The existing draft describes tests as being undertaken during the RFC 2811 message-acceptance process. There may be MTAs in which it is desired to accept the message when offered, and then undertake the tests at a later time, perhaps after reputation sources have been consulted and other tests applied. The current draft leaves MTA behaviour in post-acceptance tests undefined. It seems right-and-proper to require that the overall handling of a message by the MTA-chain be consistent, regardless of whether pre- or post-acceptance testing is chosen. These proposed changes to the draft are intended to ensure that, so long as the message is still within the SMTP transportation process, coherent behaviour is exhibited, regardless of when the Sender-ID test is actually undertaken. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 05:56: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 FAA02523 for ; Tue, 31 Aug 2004 05:56: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 i7V9SosL047137; Tue, 31 Aug 2004 02:28: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 i7V9SoYY047136; Tue, 31 Aug 2004 02:28:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9Sml2047123 for ; Tue, 31 Aug 2004 02:28:49 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:24:35 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 09:31:07 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 31 Aug 2004 07:54:23 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 07:56:54 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 Aug 2004 07:55:22 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V5gSsn082319; Mon, 30 Aug 2004 22:42: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 i7V5gSuY082318; Mon, 30 Aug 2004 22:42:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (adsl-69-225-172-218.dsl.pltn13.pacbell.net [69.225.172.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V5gSfO082297 for ; Mon, 30 Aug 2004 22:42:28 -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 861721D651 for ; Mon, 30 Aug 2004 22:42:35 -0700 (PDT) Date: Mon, 30 Aug 2004 22:42:35 -0700 From: Greg Connor To: MARID Subject: Re: DOC-BUG: permitted use of PRA/submitter address Message-ID: <21626487.1093905754@[192.168.0.2]> In-Reply-To: <94df60cf04083019063ef33297@mail.gmail.com> References: <94df60cf04083019063ef33297@mail.gmail.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 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 31 Aug 2004 05:55:22.0330 (UTC) FILETIME=[1A6C9BA0:01C48F1F] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --mazieres@gmail.com wrote: > > On Mon, 30 Aug 2004 17:56:18 -0700, Harry Katz > wrote: >> On Monday, August 30, 2004 1:15 PM, mazieres@gmail.com >> [mailto:mazieres@gmail.com] wrote: >> >> > I guess I'm particularly curious what people think about >> > virus notifications. (I care a lot about this question >> > because at times I get thousands of messages a day telling me >> > my mail has been infected with a virus, when of course I >> > didn't send the virus, but rather the virus forged my email >> > address.) It seems to me that if you get mail with a virus, >> > the person whose machine is infected is most likely the PRA, >> > not the MAIL-FROM address. Therefore, I would be tempted to >> > configure my mail filter to send automatic notifications to >> > the PRA, instead of the MAIL-FROM address. So the questions are: >> > >> > 1. Is there anything in the drafts to prevent me from sending >> > such notifications to the PRA? >> >> No. However the PRA is neither a bounce address, nor a reply-to >> address. And since the PRA only identifies the responsible sender of >> the most recent "hop" I think you cannot assume the virus originates >> from the PRA address. To add to what Harry is saying, remember that the PRA can often be an address affiliated with the receiver's forwarding arrangement, and nothing to do with the sender at all. For example, if all my mail is forwarded via pobox.com, then the authenticated PRA will probably be gconnor@pobox.com for all my mail, even mail that was received without an authenticated PRA by pobox. For this reason (and taking into account what Harry said too) I would not want Sender ID to have anything to do with where notifications go (except to say "do not send notifications to PRA that should not be used for DSN, virus warnings, auto-replies, vacation messages or whatever). > Okay, so basically is it the case that Sender ID (in its present form) > isn't designed to help with these kinds of viruses and virus > notifiers? At this point, is there any possible action the MARID > group could take that would allow more intelligent virus rejection? I > care a lot about this problem, and was hoping the outcome of this > working group could help. > > If addressing the virus/bounce problem is no longer within scope, I > don't want to dwell on the issue. However, I hope that at least > people have such extensions in mind for future work. The fact that > SPF2 records have a ver-ext field is a good sign. (However, I wonder > why not make pra a required extension, instead of part of the version > string, so that version strings like "spf2.0/blah,pra" would also be > acceptable. Not very important, though, just means there will be a > slight asymmetry if extensions become common.) I think that Sender ID will be good for detecting and blocking spoofed messages (including viruses) but that should not extend to providing accurate trace-back. At least not in its current form. The current rev of Sender ID only identifies one PRA and is focused on a single hop. It doesn't define a way to trace back the chain of hops all the way. However, I could see something like that happening in a future extension. For example, if (the PRA is checked and valid) *and* (PRA is an entity that the receiver knows and trusts) then { scan for the Received lines added by the trusted forwarder find the previous IP address recorded by that agent scan the message from that point down to find/validate 2nd PRA } I am willing to bet that a large chunk of mail I receive could be validated this way to verify the From: or Sender: even if the Sender ID would not otherwise work this way. BUT all this hinges on how well you trust your agents (such as mailing lists, which are acting as agents for the sender *and* the receiver :) so it's probably too much to ask the current rev of Sender ID to work this way. Even if we do all that we probably still don't have enough info to trace back a virus to its true owner, especially not a deliberately forged one. But hopefully blocking them is added incentive for people to publish their Sender ID info so that their domain won't be abused as often... > >> > 3. Is the PRA required to accept mail from the empty envelope >> > sender, even through any RFC1891-type DSNs/bounce messages >> > should still be sent to the MAIL-FROM address? >> >> Not sure I understand this question. However, when an MTA sends a DSN >> with MAIL FROM <>, the PRA would typically be something like >> postmaster@example.com or mailer-daemon@example.com. See example 5.5 of >> the SUBMITTER spec. > > Sorry, my question was about receiving, not sending bounces. Let me > elaborate. Suppose I have two email addresses: > > me@myschool.edu > me-bounces-2004@myschool.edu > > Because of the number of bounces I get from viruses, the address > me@myschool.edu does not accept DSNs. Therefore, I always use > me-bounces-2004@myschool.edu as the envelope sender. > > So far so good. The next question is which address I should use as > the PRA. If I don't do anything, the PRA will be me@myschool.edu, > which I would probably prefer. However, given that that address > refuses DSNs, the question is whether there would be grounds for > listing me in the rfc-ignorant RBL: > > http://www.rfc-ignorant.org/policy-dsn.php > > David I don't have a direct answer to this, but remember that the PRA *always* appears in some 2822 header before it is picked out by this algorithm. So, if you use some non-functioning address in your outgoing mail as either From:, Sender:, Resent-From: or Resent-Sender: there may already be rules that cover those types of uses. My opinion is that Sender ID should probably not make any attempt to say whether this is legal or not, because it would probably be different depending on which header was the source of the PRA. But, if there are already some rules in 2822 or 2476 that say stuff about these headers, we could make a reference to them. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:03: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 GAA02778 for ; Tue, 31 Aug 2004 06:03:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9bNCx048064; Tue, 31 Aug 2004 02:37: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 i7V9bNIe048063; Tue, 31 Aug 2004 02:37:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9bM11048057 for ; Tue, 31 Aug 2004 02:37:22 -0700 (PDT) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i7V9b077028881 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 31 Aug 2004 05:37:21 -0400 Subject: Re: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages From: Mark Shewmaker To: MARID Cc: mazieres@gmail.com In-Reply-To: <94df60cf040830214924086f53@mail.gmail.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> <1093650303.3782.3839.camel@localhost.localdomain> <72A8ABAC-F95A-11D8-881C-000A95B3BA44@hxr.us> <1093906313.3463.8385.camel@localhost.localdomain> <94df60cf0408301735444d4a45@mail.gmail.com> <1093923481.3782.8749.camel@localhost.localdomain> <94df60cf040830214924086f53@mail.gmail.com> Content-Type: text/plain Message-Id: <1093945156.2379.9503.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 31 Aug 2004 05:39:16 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Tue, 31 Aug 2004 05:37:22 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-31 at 00:49, mazieres@gmail.com wrote: > On Mon, 30 Aug 2004 23:38:01 -0400, Mark Shewmaker wrote: > > > > - The ultimate determination as to per-recipient deliverability > > > > cannot be made until after the SMTP transaction accepts the > > > > message for delivery. > > > > > > The last condition is not quite correct, because you can make the > > > determination before replying to the "." at the end of the DATA > > > command. > > > > Not an ultimate per-recipient determination, unless the answer is > > reject-for-everyone. > > Ah, I see the confusion. By "make the determination", I read decide > whether or not each recipient wants to accept the mail. I think what > you meant is notify the client of whatever that decision is. Yes, that's exactly what I meant, even though I insisted on wording which communicated something else. > The determination > is made before the end of the SMTP transaction. The problem is there > is no way to notify the client. Then let me reword: ===================================================================== 6.5 Vulnerability to unintended participation in Forged DSN attacks. This vulnerability exists if local policy settings allow for a situation in which all of the following are true: - A message is sent to multiple recipients, - The recipients have differing local policy settings with respect to message body requirements, - An ultimate determination of per-recipient nondeliverability cannot be communicated within the SMTP session after the receipt of message data, and - The Return Path is forged, An attacker can take advantage of this vulnerability by using any machine with detectably differing local policy settings as an apparent source of the attacker's forged DSNs. Not only does this mean the ultimate victims will receive forged DSNs, but the machine the attacker used to accomplish the forgery may become known as a source of forged DSNs. An MTA can completely avoid becoming a participant in this type of DSN attack by preventing any of the above listed requirements from occuring. That is, it could do any of the following: - Disallow some message recipients. - Disallow local policy settings which depend on message contents. - Disable sending of DSNs. Each option has downsides. The first option would require addition message transmission attempts, the second option would limit desirable functionality, and the third would hide email to become less reliable by hiding legitimate email problems. However, the first option is the only one which does not actually limit mail system functionality, making it the only real option to consider. To expand upon the first option, an MTA can completely avoid becoming a participant in this type of DSN attack in all cases by: Whenever all of the following is true: - An incoming message is addressed to multiple participants. - Those participants have local policy settings that, given the context of the specifics of the MTA transaction mean that per-recipient final determinations of nondeliverability cannot be communicated until after the message has been accepted for delivery. - The MTA has not positively validated the MAIL FROM address to its satisfaction, Then: - The MTA should give temporary rejections at "RCPT TO:" time to all recipients with differing message-body-related local policy settings and where the recipients have not already been temporarily or permanently rejected for other reasons, thus accepting only a compatible subset of recipients and avoiding the need to create DSNs at all. It is suggested that the MTA reject these recipients with a return code of 4.7.6. (Note that the MTA is not rejecting on the basis of too many recipients, rather it is rejecting on the basis of a security-related incompatibility in the requested recipient list.) Given special-case conditions, there are simpler, alternative ways an MTA can completely avoid becoming a participant in a DSN attack: - If the client MTA sends a "SUBMITTER" parameter to the MAIL command, then no per-recipient policy that addresses functionality related to this standard can trigger this vulnerability. If per-recipient policy settings only extend to functionality related to this standard, then the above recipient-rejection workaround need not be used for that SMTP transaction. - If the server MTA obtains positive validation of the MAIL FROM address for a particular SMTP transaction, then for that SMTP transaction the server MTA need not use the recipient-rejection workaround given above. - If a future SMTP extension allows for per-recipient after-DATA rejects, and an SMTP session makes use of such an extension, then the above workaround is not needed for that session. Avoiding the receipt of forged DSNs is generally outside the scope of this document, however a domain that signs outgoing messages in a recognizable way can avoid at least some types of forged DSN attacks. Note that this workaround will not prevent DSN attacks if your domain authorizes messages to be received by any other MTA, such as a border or secondary MTA, and that other MTA does not do the exact set of checks as the final MTA or checks more stringent than the final MTA. The reason is that when the border MTA relays the message to final MTA, even if it rejects the message, the border MTA will then create a DSN which would be sent to an inappropriate party if the Return Path is forged. This second type of forged DSN attack can be avoided by ensuring that all other MTAs your domain authorizes to receive mail do the same set of checks. Border and secondary MTAs can do a more stringent set of checks than final MTAs, as long as there is never a relay from an MTA with less-stringent tests to an MTA with more-stringent tests. ===================================================================== > > > In fact, while I don't fully understand the motivation for having > > > different PRA and MAIL-FROM addresses, I gather from previous messages > > > that the people who want this the most are large banks that send out > > > bulk mail. > > > > Somewhat off-topic, but here's one reason: There are some legal > > requirements to send some EFT notifications, (and things like those > > yearly account-rules-and-conditions-and-information things), that can be > > satisfied by emails if you then send paper documents if the email > > bounces. I can see where companies might want to outsource the sending > > of notifications like this, trusting the outsourced sender to notify > > them of rejects, but yet possibly wanting to handle the bounce > > processing separately. > What do you mean by "handling > bounce processing separately"? Presumably this is the major function > of the outsourced sender, so the sender is getting the bounces. I was thinking more social (almost dilbertish) reasons as opposed to reasons borne out of utter technical necessity. For instance, I was imagining a situation in which one machine is temporarily set up for a day or so to send semi-secure eft notifications, after which it is wiped of all the secure-ish info necessary for the bulk sending, (or the capability to access the secure-ish info), and then set up for another bulk sending session of another customer, with the bulk sender or bank or what-have-you making a big deal about secure wipes or deletions. And then if you don't need as much secure info to handle bounce processing, the bounce-handling machine might be another machine entirely, and thus might be allowed the necessary access longer. So you might have: Mail-From: mybank-bounce-1234@bounces.bulksender.mybank.com From: eft-notification@bulksender.mybank.com So if you're the big bank in question, and you want to prove to federal regulators that you're performing your due diligence for the regs, even though technically clued in people will understand that having separate bounce-handling machines isn't necessary and is quite possibly counterproductive, (and causing you to be more likely to make mistakes), I'm guessing that big bank folks would like to be able to jump up and down, point at a machine that's dedicated to only receiving bounce messages, has been doing that exclusively for xxx amount of time, etc., "prove" it by talking about bounce addresses, and thus completely (hopefully) avoid any question about their behavior in that respect. It's not really logical, and I admit I'm stretching things, but my guess is that that's the sort of reason people want that sort of difference. It's just a guess, and it requires marketing-type interests to override saner technical decisions. (Though then again I admit having thought of doing that sort of separate-domain automated bounce processing myself, merely out of convenience and, err, laziness.) In any event, the fact that such requirements are so unusual, in the only situations I could think of, put me squarely in the "keep spf1 semantics, no spf2 strings" camp. > Maybe what we need is a global modifier "display=domain" that says > what domain to display in the golden padlock. Obviously domain must > be a suffix of the current domain, but it could be a strict suffix to > avoid confusing users with extra clutter like the "sender" in > "sender.bank.com." To me sender_agents is a better solution to all that. :-) (I still need to write that up again for under a TECH-OMISSION document.) -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:11: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 GAA03203 for ; Tue, 31 Aug 2004 06:11: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 i7V9pp79049631; Tue, 31 Aug 2004 02:51:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V9pp0L049629; Tue, 31 Aug 2004 02:51:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9pnHt049609 for ; Tue, 31 Aug 2004 02:51:50 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:41:20 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:24:31 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 09:31:11 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 31 Aug 2004 07:51:07 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 07:53:38 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 Aug 2004 07:52:18 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V5c6Jw079443; Mon, 30 Aug 2004 22:38:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V5c6n9079442; Mon, 30 Aug 2004 22:38:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V5c5jT079377 for ; Mon, 30 Aug 2004 22:38:06 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so228236rnk for ; Mon, 30 Aug 2004 22:38:08 -0700 (PDT) Received: by 10.38.171.20 with SMTP id t20mr1376017rne; Mon, 30 Aug 2004 22:38:08 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Mon, 30 Aug 2004 22:38:08 -0700 (PDT) Message-ID: <94df60cf04083022383d5bd9f7@mail.gmail.com> Date: Tue, 31 Aug 2004 01:38:08 -0400 From: Reply-To: To: Harry Katz Subject: Re: DOC-BUG: permitted use of PRA/submitter address Cc: MARID In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 31 Aug 2004 05:52:18.0415 (UTC) FILETIME=[ACCD67F0:01C48F1E] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 30 Aug 2004 22:12:11 -0700, Harry Katz wrote: > On Monday, August 30, 2004 7:07 PM, mazieres@gmail.com > [mailto:mazieres@gmail.com] wrote: > > > Okay, so basically is it the case that Sender ID (in its > > present form) isn't designed to help with these kinds of > > viruses and virus notifiers? At this point, is there any > > possible action the MARID group could take that would allow > > more intelligent virus rejection? I care a lot about this > > problem, and was hoping the outcome of this working group could help. > > I think Sender ID will help with viruses, though perhaps not in the way > you're suggesting. As I understand it, many viruses today are > tranmitted from infected zombie machines, often home computers connected > via cable modem or DSL lines. The IP addresses of these home computers > will not likely be listed by their owning ISPs as legitimate sources of > outbound e-mail. Thus a receiver performing the Sender ID check should > be able to detect "foul play" and reject the message, presumably with a > 5xx type return code rather than by sending an actual bounce message. I'm not sure I see how the owning ISP of the virus-infected machine comes into play, as the problem is that the machines are forging mail in my name. (If viruses all claimed to be from the owning ISP, I'd already be a lot happier.) It's true that if I publish an SPF2 record, it would probably help with today's viruses, because the From: address would be the PRA, and thus would be goverened by my SPF2 record. However, if Sender-ID were adopted, I'm sure the virus writers would just start including a line like: Resent-Sender: virus@com in each email. This would guarantee a SenderID result of None (since com has NS but no TXT/SPF2 records), and thus for sites that don't do virus checking before responding to the DATA command, would still result in a flood of bounce messages to me. From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:11: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 GAA03226 for ; Tue, 31 Aug 2004 06:11: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 i7V9sl6i050015; Tue, 31 Aug 2004 02:54: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 i7V9slHt050014; Tue, 31 Aug 2004 02:54:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9sj1b050006 for ; Tue, 31 Aug 2004 02:54:46 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:52:28 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:41 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 20:18:48 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 20:21:20 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 20:20:35 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UI4YEu073243; Mon, 30 Aug 2004 11:04:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UI4YNg073242; Mon, 30 Aug 2004 11:04:34 -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 i7UI4YFq073235 for ; Mon, 30 Aug 2004 11:04:34 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i7UI4bkW026950 for ; Mon, 30 Aug 2004 11:04:38 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "IETF-MXCOMP WG'" From: "Anne P. Mitchell, Esq." Subject: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) Date: Mon, 30 Aug 2004 11:04:37 -0700 X-Mailer: Apple Mail (2.619) List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 18:20:36.0108 (UTC) FILETIME=[0B7FECC0:01C48EBE] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > 4) You have stated above that you believe Microsoft's claim is > "nebulous" with regard to rights being claimed. Your release notes > state "Implemented Sender Policy Framework checking on the From: > header. Be sure to read the documentation and understand the > implication." Since checking of the From: header is listed in the -pra > document, are you concluding that this is not encumbered by > Microsoft's claim? If so, how did you come to this conclusion? > This brings up a point which has been rolling around in the back of my head for a few days. We simply _don't_ know what is in the claim. In any other area where adoption of some program is to be impacted or encumbered in some way which could cause either a legal liability or an inability to actually implement on the part of the adopter - particularly such a potentially widely used program - it is inconceivable that people would be even considering adopting, or recommending, the program. In fact, if one had a professional license, and recommended adoption of such a program without a clear understanding of the encumberance, one could be guilty of malpractice. But I digress...what has been rolling around in the back of my head is this: Can anyone say with 100% certainty that there is *zero* technology, software, or process, which can be reasonably argued by Microsoft to belong to them, with regards to *checking*? Bear in mind that I have some experience in patenting this sort of technology (I have been involved in the patent work on the Habeas "technology", among others, and I put that word in quotes because if you look at the Habeas model I'm guessing many of you would be shocked to realize just how much *is* patentable as "technology"). Ok, I'm going to guess that some of you might say "yes" to the above. So, let's put it another way now: Is the method for checking under Sender I.D. *identical* to the method for checking for SPF? Imagine a world where some day you have to pay for a site license to be able to perform a check. Where the only receiver who *doesn't* have to pay to perform checks is Microsoft itself. Again, this is not Microsoft bashing - I personally believe that *any* large receiver owning the ultimate rights to an authentication system is a conflict of interest. And to be honest, for the life of me, I don't understand why SPF, which already had a lot of support from other corners, isn't what's being pushed now. Although, of course, for all we know (and I very much suspect) SPF is probably now in some way encumbered by MS anyways. It would be foolish of them to embrace and incorporate SPF technology without first making sure that they darned well owned it. Just like any other acquisition - you can either put the competitor under, or acquire them. Anne From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:12: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 GAA03335 for ; Tue, 31 Aug 2004 06:12: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 i7V9snNJ050023; Tue, 31 Aug 2004 02:54:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V9snjf050022; Tue, 31 Aug 2004 02:54:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9sj1d050006 for ; Tue, 31 Aug 2004 02:54:48 -0700 (PDT) (envelope-from daryl.odnert@tumbleweed.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:52:27 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:41 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 31 Aug 2004 00:29:35 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 00:32:08 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 Aug 2004 00:31:28 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UMGRSG027150; Mon, 30 Aug 2004 15:16: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 i7UMGR9a027149; Mon, 30 Aug 2004 15:16:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UMGRQ3027123 for ; Mon, 30 Aug 2004 15:16:27 -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 (Email Firewall v6.0.0)); Mon, 30 Aug 2004 15:16:18 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Mon, 30 Aug 2004 15:16:07 -0700 Message-ID: From: "Daryl Odnert" To: "'Mark Lentczner'" , "IETF MARID WG" Subject: RE: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) Date: Mon, 30 Aug 2004 15:16:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D2D78B81QO832200-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48EDE.6106AE1E" List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 22:31:29.0073 (UTC) FILETIME=[17C41A10:01C48EE1] 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_01C48EDE.6106AE1E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > There is nothing heuristic in the PRA > identity. It follows directly from the RFC 2822 definition of the > headers. This statement makes me wonder how anyone could validly claim a patent on an algorithm to find the PRA. Daryl Odnert ------_=_NextPart_001_01C48EDE.6106AE1E Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support = in Courier.)

Mark Lentczner wrote:
>          = ;            = ;    There is nothing heuristic in the PRA
> identity.  It follows directly from the = RFC 2822 definition of the
> headers.

This statement makes me wonder how anyone could = validly claim a
patent on an algorithm to find the PRA.

Daryl Odnert

------_=_NextPart_001_01C48EDE.6106AE1E-- From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:22: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 GAA03745 for ; Tue, 31 Aug 2004 06:22: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 i7V9v1vQ050355; Tue, 31 Aug 2004 02:57: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 i7V9v1HQ050354; Tue, 31 Aug 2004 02:57:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9uwdf050340 for ; Tue, 31 Aug 2004 02:57:00 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:52:21 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:36 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 23:39:34 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 23:42:06 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 23:41:10 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULRVr7016758; Mon, 30 Aug 2004 14:27: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 i7ULRV57016757; Mon, 30 Aug 2004 14:27:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULRUg6016750 for ; Mon, 30 Aug 2004 14:27:30 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 936A24149B; Mon, 30 Aug 2004 14:27:35 -0700 (PDT) Subject: Re: Reputation services for SenderID From: Douglas Otis To: mazieres@gmail.com Cc: John Leslie , MXCOMP In-Reply-To: <94df60cf040829152232ce5533@mail.gmail.com> References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> <20040827231531.GI465@verdi> <94df60cf040829152232ce5533@mail.gmail.com> Content-Type: text/plain Message-Id: <1093901254.5542.343.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 14:27:34 -0700 Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 21:41:10.0863 (UTC) FILETIME=[10C5CDF0:01C48EDA] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-08-29 at 15:22, mazieres@gmail.com wrote: > On Fri, 27 Aug 2004 19:15:31 -0400, John Leslie wrote: > > ... > > We then evaluate the list of IPs authorized by the SPF2 record, > > and run them against known IP blacklists; accumulating a score based > > on weighting the reputation of those blacklists for spam identified, > > false negatives, and false positives. > > This might usually work, but what do you do about the exists and ptr > mechanisms? In general there is no practical and 100% reliable way to > produce a list of IP addresses authorized by an SPF2 record. Evaluating against a currently available IP address blacklist, for moving from an address scheme to a name scheme, by transferring existing address information found published in SPF2 records is not possible. If there was a black-listed IP address that authenticated as being within the Sender-ID mail-channel, then that name might be added to a RHSBL. Without other confirmation, this would erode reasons for using names rather than addresses. Most would drop the connection and not care what the Sender-ID identity was or whether the MTA authenticated. To build upon the IP address blacklist and correlate to a name can not make use of the SPF2 records directly. One can not trust the ownership of addresses published in the SPF2 records. Building information from an address black-list based upon what is published in SPF2 records is meaningless. Publishing addresses has demonstrated nothing with respect to being administratively responsible for them. Conversely, obtaining this address information from complex SPF2 records is impossible without message-based keys to build access labels. Sender-ID SPF2 records does not enable a safe correlation between the MTA address and the Mailbox Domain. If comparing an IP blacklist and the SPF2 records- Building: A spammer could make themselves appear to be using known good addresses, where actually different addresses are actually used by means of the labeling mechanism built upon unpublished information found only in the message. This is a good reason why a macro label mechanism is bad. The SPF2 record must be ignored. Reporting: A spammer could make known good addresses appear bad, if the published addresses are included in a reputation assessment. The SPF2 record must be ignored. Sender-ID SPF2 does not allow a safe bridge between IP address information and domain name information for reputation use. Spammers do whatever it takes to gum up the works and that means claiming IP addresses they don't administer. As you point out, the actual address may not be accessible, if reviewed independent of a message. The Sender-ID entity could reside behind a transparently intercepted or shared outbound SMTP server. This means assumptions regarding this Sender-ID identity being authentic may be in error. Sender-ID only gives the appearance of authenticating the sender, and may have the unfortunate outcome of being a useful ploy to enable spammers to promote themselves as being validated by this flawed system. It also means innocent parties will become "reputation" victims of these ploys. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:23: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 GAA03773 for ; Tue, 31 Aug 2004 06:23: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 i7VA0ATK050737; Tue, 31 Aug 2004 03:00: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 i7VA0Awt050736; Tue, 31 Aug 2004 03:00:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VA0834050699 for ; Tue, 31 Aug 2004 03:00:09 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:52:12 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:29 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 22:26:55 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 22:29:27 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 22:28:42 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKEgKg002741; Mon, 30 Aug 2004 13:14: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 i7UKEgT3002740; Mon, 30 Aug 2004 13:14:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKEf4k002733 for ; Mon, 30 Aug 2004 13:14:42 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so172636rnk for ; Mon, 30 Aug 2004 13:14:43 -0700 (PDT) Received: by 10.38.164.76 with SMTP id m76mr1139196rne; Mon, 30 Aug 2004 13:14:43 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Mon, 30 Aug 2004 13:14:43 -0700 (PDT) Message-ID: <94df60cf04083013141d0b9dc@mail.gmail.com> Date: Mon, 30 Aug 2004 16:14:43 -0400 From: Reply-To: To: Harry Katz Subject: Re: DOC-BUG: permitted use of PRA/submitter address Cc: MARID In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 20:28:42.0350 (UTC) FILETIME=[F0DB60E0:01C48ECF] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 30 Aug 2004 11:43:20 -0700, Harry Katz wrote: > > > On Sunday, August 29, 2004 4:34 PM, mazieres@gmail.com wrote: > > > It's hard from the current drafts to figure out when exactly > > it is appropriate to send mail to the PRA of a received mail > > message... > > ... > > The PRA doesn't replace or over-ride any of the semantics around mail > replies or notifications. It is intended only as a mechanism to > identify the entity most recently responsible for injecting the message > into the mail system. If you normally send a bounce to the 2821 MAIL > FROM address, you would continue to do so. If you normally send a reply > to the 2822 From or Reply-To address, you would continue to do so. > > Section 4.2 of the submitter-03 draft has the following paragraph which > addresses, at least in part, this very issue. > > Note that the presence of the SUBMITTER parameter on 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 section 3.7 of [SMTP] regardless of the presence > of a SUBMITTER parameter. If the reverse-path is null, delivery > status notifications MUST NOT be sent to the SUBMITTER address. One problem may be that when I read the words "delivery status notification", to me that has a very specific meaning (in the sense of RFC1891). Is that paragraph also supposed to cover auto-generated messages of the form "I'm on vacation and will read your message next week," or "Your attachment contained a virus and has been removed"? It also still doesn't address the question of whether the PRA must be a valid email address. I'm assuming that if the email address does exist, then the domain in the PRA is considered to offer mail service and must have RFC2142 mailbox names like abuse and postmaster. I don't see anything in the drafts that prevents someone from using the PRA simply as a non-functioning syntactic placeholder or level of indirection for authentication. (And of course, if I were a spammer, I certainly wouldn't be interested in setting up a working PRA.) I guess I'm particularly curious what people think about virus notifications. (I care a lot about this question because at times I get thousands of messages a day telling me my mail has been infected with a virus, when of course I didn't send the virus, but rather the virus forged my email address.) It seems to me that if you get mail with a virus, the person whose machine is infected is most likely the PRA, not the MAIL-FROM address. Therefore, I would be tempted to configure my mail filter to send automatic notifications to the PRA, instead of the MAIL-FROM address. So the questions are: 1. Is there anything in the drafts to prevent me from sending such notifications to the PRA? 2. Is the PRA required to exist/accept such notifications. Should the PRA be a human rather than an autoresponder? 3. Is the PRA required to accept mail from the empty envelope sender, even through any RFC1891-type DSNs/bounce messages should still be sent to the MAIL-FROM address? David From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:24: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 GAA03823 for ; Tue, 31 Aug 2004 06:24: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 i7VA4pYd052102; Tue, 31 Aug 2004 03:04: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 i7VA4pON052101; Tue, 31 Aug 2004 03:04:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VA4je1052071 for ; Tue, 31 Aug 2004 03:04:48 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:52:01 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:20 +0200 Received: from MAILFAXSRV.gfimalta.com ([10.130.130.13]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 20:25:16 +0200 Received: from mail pickup service by MAILFAXSRV.gfimalta.com with Microsoft SMTPSVC; Mon, 30 Aug 2004 20:25:04 +0200 Received: from mailgate.gfifax.com ([10.130.130.110]) by MAILFAXSRV.gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 18:25:03 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 18:24:16 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 18:26:47 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 18:23:40 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UG2ZFe055790; Mon, 30 Aug 2004 09:02: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 i7UG2Zlw055789; Mon, 30 Aug 2004 09:02:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UG2Y0l055782 for ; Mon, 30 Aug 2004 09:02:34 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7UG2ZMO014312; Mon, 30 Aug 2004 09:02:36 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 30 Aug 2004 09:02:35 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Peuhkurinen, Kevin'" , ietf-mxcomp@imc.org Subject: RE: More on Exim, GPL and the IPR license Date: Mon, 30 Aug 2004 09:02:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48EAA.C329C5EB" List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 16:23:40.0510 (UTC) FILETIME=[B5E09FE0:01C48EAD] 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_01C48EAA.C329C5EB Content-Type: text/plain; charset="iso-8859-1" T here is a rule in the House of Commons that whenever a document is referred to the entirety of the document must be lodged in the house library, rather than just the portions that are quoted. What was the letter sent to Dr Hazel? What are the grounds on which his statement is based? What is the context of the excerpt? It seems somewhat strange that Dr Hazel would take this position when he has in the past taken a much more open approach to licensing: Written by: Philip Hazel < address@bogus.example.com> University of Cambridge Computing Service, Cambridge, England. Phone: Copyright (c) 1997-2000 University of Cambridge Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions: 1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 2. The origin of this software must not be misrepresented, either by explicit claim or by omission. In practice, this means that if you use PCRE in software which you distribute to others, commercially or otherwise, you must put a sentence like this Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. somewhere reasonably visible in your documentation and in any relevant files or online help data or similar. A reference to the ftp site for the source, that is, to ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ should also be given in the documentation. 3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. 4. If PCRE is embedded in any software that is released under the GNU General Purpose Licence (GPL), then the terms of that licence shall supersede any condition above with which it is incompatible. I hate to keep harping on this, but I really do believe that it is important. I solicited the opinion of Dr. Philip Hazel of Cambridge University who as you probably know is the principal author of Exim. I asked him if he would consider releasing Exim under a difference license other than the GPL if doing so would allow Sender-ID code to be included in it. His response was: "The short answer is "No". I have no desire to change Exim's licence, and certainly not as a result from pressure of Microsoft's lawyers. Furthermore, some of the other postings I've seen have said that developers using this "free" licence must register with Microsoft. That is completely unacceptable." I believe that Dr. Hazel's response demonstrates two things. The first is that one of the most popular MTAs in use will not be able to include Sender-ID code. The second is that a very well respected open source developer sees the IPR license terms as "completely unacceptable". Kevin ------_=_NextPart_001_01C48EAA.C329C5EB Content-Type: text/html; charset="iso-8859-1" More on Exim, GPL and the IPR license
T here is a rule in the House of Commons that whenever a document is referred to the entirety of the document must be lodged in the house library, rather than just the portions that are quoted.
 
What was the letter sent to Dr Hazel? What are the grounds on which his statement is based? What is the context of the excerpt?
 
It seems somewhat strange that Dr Hazel would take this position when he has in the past taken a much more open approach to licensing:
 
 
Written by: Philip Hazel <address@bogus.example.com>

University of Cambridge Computing Service,
Cambridge, England. Phone:  <redacted> 

Copyright (c) 1997-2000 University of Cambridge

Permission is granted to anyone to use this software for any purpose on any
computer system, and to redistribute it freely, subject to the following
restrictions:

1. This software is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

2. The origin of this software must not be misrepresented, either by
   explicit claim or by omission. In practice, this means that if you use
   PCRE in software which you distribute to others, commercially or
   otherwise, you must put a sentence like this

     Regular expression support is provided by the PCRE library package,
     which is open source software, written by Philip Hazel, and copyright
     by the University of Cambridge, England.

   somewhere reasonably visible in your documentation and in any relevant
   files or online help data or similar. A reference to the ftp site for
   the source, that is, to

     ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

   should also be given in the documentation.

3. Altered versions must be plainly marked as such, and must not be
   misrepresented as being the original software.

4. If PCRE is embedded in any software that is released under the GNU
   General Purpose Licence (GPL), then the terms of that licence shall
   supersede any condition above with which it is incompatible.


I hate to keep harping on this, but I really do believe that it is important.   I solicited the opinion of Dr. Philip Hazel of Cambridge University who as you probably know is the principal author of Exim.   I asked him if he would consider releasing Exim under a difference license other than the GPL if doing so would allow Sender-ID code to be included in it.   His response was:

"The short answer is "No".

I have no desire to change Exim's licence, and certainly not as a result
from pressure of Microsoft's lawyers. Furthermore, some of the other
postings I've seen have said that developers using this "free" licence
must register with Microsoft. That is completely unacceptable."

I believe that Dr. Hazel's response demonstrates two things.   The first is that one of the most popular MTAs in use will not be able to include Sender-ID code.   The second is that a very well respected open source developer sees the IPR license terms as "completely unacceptable".

Kevin

------_=_NextPart_001_01C48EAA.C329C5EB-- From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:24: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 GAA03843 for ; Tue, 31 Aug 2004 06: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 i7VA4mxU052084; Tue, 31 Aug 2004 03:04: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 i7VA4mcn052083; Tue, 31 Aug 2004 03:04:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VA4jdx052071 for ; Tue, 31 Aug 2004 03:04:46 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:52:01 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:20 +0200 Received: from MAILFAXSRV.gfimalta.com ([10.130.130.13]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 20:25:17 +0200 Received: from mail pickup service by MAILFAXSRV.gfimalta.com with Microsoft SMTPSVC; Mon, 30 Aug 2004 20:25:04 +0200 Received: from mailgate.gfifax.com ([10.130.130.110]) by MAILFAXSRV.gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 18:25:03 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 18:24:16 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 18:26:47 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 18:23:40 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UG2ZFe055790; Mon, 30 Aug 2004 09:02: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 i7UG2Zlw055789; Mon, 30 Aug 2004 09:02:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UG2Y0l055782 for ; Mon, 30 Aug 2004 09:02:34 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7UG2ZMO014312; Mon, 30 Aug 2004 09:02:36 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 30 Aug 2004 09:02:35 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Peuhkurinen, Kevin'" , ietf-mxcomp@imc.org Subject: RE: More on Exim, GPL and the IPR license Date: Mon, 30 Aug 2004 09:02:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48EAA.C329C5EB" List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 16:23:40.0510 (UTC) FILETIME=[B5E09FE0:01C48EAD] 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_01C48EAA.C329C5EB Content-Type: text/plain; charset="iso-8859-1" T here is a rule in the House of Commons that whenever a document is referred to the entirety of the document must be lodged in the house library, rather than just the portions that are quoted. What was the letter sent to Dr Hazel? What are the grounds on which his statement is based? What is the context of the excerpt? It seems somewhat strange that Dr Hazel would take this position when he has in the past taken a much more open approach to licensing: Written by: Philip Hazel < address@bogus.example.com> University of Cambridge Computing Service, Cambridge, England. Phone: Copyright (c) 1997-2000 University of Cambridge Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions: 1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 2. The origin of this software must not be misrepresented, either by explicit claim or by omission. In practice, this means that if you use PCRE in software which you distribute to others, commercially or otherwise, you must put a sentence like this Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. somewhere reasonably visible in your documentation and in any relevant files or online help data or similar. A reference to the ftp site for the source, that is, to ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ should also be given in the documentation. 3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. 4. If PCRE is embedded in any software that is released under the GNU General Purpose Licence (GPL), then the terms of that licence shall supersede any condition above with which it is incompatible. I hate to keep harping on this, but I really do believe that it is important. I solicited the opinion of Dr. Philip Hazel of Cambridge University who as you probably know is the principal author of Exim. I asked him if he would consider releasing Exim under a difference license other than the GPL if doing so would allow Sender-ID code to be included in it. His response was: "The short answer is "No". I have no desire to change Exim's licence, and certainly not as a result from pressure of Microsoft's lawyers. Furthermore, some of the other postings I've seen have said that developers using this "free" licence must register with Microsoft. That is completely unacceptable." I believe that Dr. Hazel's response demonstrates two things. The first is that one of the most popular MTAs in use will not be able to include Sender-ID code. The second is that a very well respected open source developer sees the IPR license terms as "completely unacceptable". Kevin ------_=_NextPart_001_01C48EAA.C329C5EB Content-Type: text/html; charset="iso-8859-1" More on Exim, GPL and the IPR license
T here is a rule in the House of Commons that whenever a document is referred to the entirety of the document must be lodged in the house library, rather than just the portions that are quoted.
 
What was the letter sent to Dr Hazel? What are the grounds on which his statement is based? What is the context of the excerpt?
 
It seems somewhat strange that Dr Hazel would take this position when he has in the past taken a much more open approach to licensing:
 
 
Written by: Philip Hazel <address@bogus.example.com>

University of Cambridge Computing Service,
Cambridge, England. Phone:  <redacted> 

Copyright (c) 1997-2000 University of Cambridge

Permission is granted to anyone to use this software for any purpose on any
computer system, and to redistribute it freely, subject to the following
restrictions:

1. This software is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

2. The origin of this software must not be misrepresented, either by
   explicit claim or by omission. In practice, this means that if you use
   PCRE in software which you distribute to others, commercially or
   otherwise, you must put a sentence like this

     Regular expression support is provided by the PCRE library package,
     which is open source software, written by Philip Hazel, and copyright
     by the University of Cambridge, England.

   somewhere reasonably visible in your documentation and in any relevant
   files or online help data or similar. A reference to the ftp site for
   the source, that is, to

     ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

   should also be given in the documentation.

3. Altered versions must be plainly marked as such, and must not be
   misrepresented as being the original software.

4. If PCRE is embedded in any software that is released under the GNU
   General Purpose Licence (GPL), then the terms of that licence shall
   supersede any condition above with which it is incompatible.


I hate to keep harping on this, but I really do believe that it is important.   I solicited the opinion of Dr. Philip Hazel of Cambridge University who as you probably know is the principal author of Exim.   I asked him if he would consider releasing Exim under a difference license other than the GPL if doing so would allow Sender-ID code to be included in it.   His response was:

"The short answer is "No".

I have no desire to change Exim's licence, and certainly not as a result
from pressure of Microsoft's lawyers. Furthermore, some of the other
postings I've seen have said that developers using this "free" licence
must register with Microsoft. That is completely unacceptable."

I believe that Dr. Hazel's response demonstrates two things.   The first is that one of the most popular MTAs in use will not be able to include Sender-ID code.   The second is that a very well respected open source developer sees the IPR license terms as "completely unacceptable".

Kevin

------_=_NextPart_001_01C48EAA.C329C5EB-- From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:29: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 GAA04042 for ; Tue, 31 Aug 2004 06:29: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 i7V9wiGR050567; Tue, 31 Aug 2004 02:58: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 i7V9wiUH050566; Tue, 31 Aug 2004 02:58:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V9wf7T050545 for ; Tue, 31 Aug 2004 02:58:42 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:52:17 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:33 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 23:02:55 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 23:05:24 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 23:04:41 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKpOju010033; Mon, 30 Aug 2004 13:51: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 i7UKpOnD010032; Mon, 30 Aug 2004 13:51:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKpNjU010018 for ; Mon, 30 Aug 2004 13:51:23 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so114028rnk for ; Mon, 30 Aug 2004 13:51:20 -0700 (PDT) Received: by 10.38.11.77 with SMTP id 77mr1150432rnk; Mon, 30 Aug 2004 13:51:19 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Mon, 30 Aug 2004 13:51:18 -0700 (PDT) Message-ID: <94df60cf0408301351c0551b0@mail.gmail.com> Date: Mon, 30 Aug 2004 16:51:18 -0400 From: Reply-To: To: Douglas Otis Subject: Re: TECH-OMISSION: Security considerations and limit scope Cc: IETF MARID WG In-Reply-To: <1093892373.5542.192.camel@ddev.mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16682.31117.662266.736155@proton.pathname.com> <1093892373.5542.192.camel@ddev.mail-abuse.org> List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 21:04:41.0605 (UTC) FILETIME=[F7DF8B50:01C48ED4] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 30 Aug 2004 11:59:34 -0700, Douglas Otis wrote: > > The use of exists and ptr record types adds a burden the recipient may > not wish to endure. There should be a warning that this type of record > may be rejected. If you are going to do this, you should treat exists and ptr separately. ptr record types almost certainly don't add a burden to the recipient. The reason is that pretty much all MTAs do a reverse lookup on the client's IP address anyway for inclusion in the Received: header. The ptr check can therefore be implemented without an additional DNS lookup. The exists header can, of course, lead to extra DNS lookups. Note also that if you are worried about extra DNS lookups, the include directive can definitely be responsible for more DNS traffic. I think that the flexibility offered by exists and include is very useful in a number of situations, and so would rather not see "reasonable" use of the mechanisms deprecated, though clearly we would also like clients not to feel compelled to go through with "unreasonable" checks. Recursion limits are a step in the right direction; whether or not they suffice will be seen when we deploy this stuff... [I also believe that a few changes, like allowing the negation of operators, would significantly reduce (but not eliminate) the need for include and exists. However, I recognize such discussion is no longer in scope, and don't want to distract from the topic at hand...] David From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:30: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 GAA04086 for ; Tue, 31 Aug 2004 06:30: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 i7VA3KJU051502; Tue, 31 Aug 2004 03:03: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 i7VA3KwP051500; Tue, 31 Aug 2004 03:03:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VA3E3N051459 for ; Tue, 31 Aug 2004 03:03:16 -0700 (PDT) (envelope-from hkatz@exchange.microsoft.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:52:05 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:23 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 20:57:32 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 21:00:04 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 20:59:23 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UIhKFC080567; Mon, 30 Aug 2004 11:43: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 i7UIhKkC080566; Mon, 30 Aug 2004 11:43:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UIhJ9c080558 for ; Mon, 30 Aug 2004 11:43:19 -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); Mon, 30 Aug 2004 11:43:23 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Aug 2004 11:43:23 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 11:43:23 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 11:43:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DOC-BUG: permitted use of PRA/submitter address Date: Mon, 30 Aug 2004 11:43:20 -0700 Message-ID: Thread-Topic: DOC-BUG: permitted use of PRA/submitter address thread-index: AcSOIkB6fIPhXRM9TTOox7G9e/PQrQAnhEkQ From: "Harry Katz" To: , "MARID" X-OriginalArrivalTime: 30 Aug 2004 18:43:21.0612 (UTC) FILETIME=[39674CC0:01C48EC1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7UIhK9c080559 List-Archive: List-Unsubscribe: List-ID: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sunday, August 29, 2004 4:34 PM, mazieres@gmail.com wrote: > It's hard from the current drafts to figure out when exactly > it is appropriate to send mail to the PRA of a received mail > message. I'm guessing this is because the authors are > relying on previous RFCs for this. However, given that a lot > of people are already confused by the distinction between > envelope and From: address, there is a danger that the > introduction of a third address would lead to an even larger > number of broken vacation-type programs. > > I'd like to suggest that the Sender ID (or maybe the PRA or > SUBMITTER) document have somewhere a non-normative paragraph > that clues people in to how they can learn about appropriate > uses of the PRA. As an example, here are a bunch of > questions whose answers are not immediately obvious from > reading Sender ID and associated drafts: > > * Is it ever actually required that the PRA be a valid mailbox? Is it > legal to construct some mailbox whose domain has an SPF2 record but > not an MX or A record? I presume the answer is no, but that the > logic involves some other RFC I'm just not looking at. How would > you go about convincing an administrator this is wrong. > > * I am on vacation, and receive mail which lists my own address in the > To: or CC: fields, and does not have any indications such as > "Precedence: list/bulk/junk" that it is from a mailing list. I wish > for my filter to notify the sender that I will not be responding for > a week. Should I send the notification to the MAIL-FROM address, as > I currently do, or to the PRA? > > * I receive mail with an attachment that contains a virus. I wish to > configure my MUA or spam filter automatically to notify the sender > that his/her machine has a virus and the attachment has been > deleted. Should I send mail to the PRA? Can/should that mail come > from the empty envelope sender, or should/must it come from my real > email address? > > * I have been erroneously subscribed to a mailing list. Should I > complain directly to the PRA? Should I attempt to form a new > address by appending "-owner" or "-request" to the local part of the > PRA? Or should I complain to an address based on the envelope > sender, as I currently would. > > * I receive offensive and/or threatening mail from someone, and wish > to complain to their administrator. Should I complain to > postmaster/abuse at the domain name in the PRA, as opposed to the > domain in the From or envelope sender address? > > * In order to reduce spam, I currently perform an SMTP callback on the > envelope sender of mail, ensuring that any mail I accept could have > been bounced. (This is highly effective against spam from > virus-infected machines, because many machines infected by viruses > can make outgoing TCP connections but not accept incoming ones, and > thus are forced to use other people's often invalid envelope > senders.) In case of forgery, people can block these callbacks by > using SPFv1 records. Once we have Sender ID, should I instead > perform SMTP callbacks to validate the SUBMITTER or PRA address > rather than MAIL-FROM, so as to avoid wasting bandwidth of sites > whose addresses are being forged? The PRA doesn't replace or over-ride any of the semantics around mail replies or notifications. It is intended only as a mechanism to identify the entity most recently responsible for injecting the message into the mail system. If you normally send a bounce to the 2821 MAIL FROM address, you would continue to do so. If you normally send a reply to the 2822 From or Reply-To address, you would continue to do so. Section 4.2 of the submitter-03 draft has the following paragraph which addresses, at least in part, this very issue. Note that the presence of the SUBMITTER parameter on 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 section 3.7 of [SMTP] regardless of the presence of a SUBMITTER parameter. If the reverse-path is null, delivery status notifications MUST NOT be sent to the SUBMITTER address. From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:33:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04357 for ; Tue, 31 Aug 2004 06:33: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 i7VADMOY053787; Tue, 31 Aug 2004 03:13:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VADME3053785; Tue, 31 Aug 2004 03:13:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VADKsF053758 for ; Tue, 31 Aug 2004 03:13:21 -0700 (PDT) (envelope-from chris@harvington.org.uk) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:51:44 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:47 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 21:49:40 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 21:52:12 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 21:51:19 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UJZHBq093812; Mon, 30 Aug 2004 12:35: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 i7UJZHSN093811; Mon, 30 Aug 2004 12:35:17 -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 i7UJZGlN093801 for ; Mon, 30 Aug 2004 12:35:17 -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 1C1rvz-00069q-00 for ietf-mxcomp@imc.org; Mon, 30 Aug 2004 20:35:20 +0100 Message-ID: <19a401c48ec8$1c98dd00$0200000a@ringo> From: "Chris Haynes" To: "IETF MARID WG" References: <111001c48be5$ebaa1360$0200000a@ringo> <188c01c48e77$7d768bf0$0200000a@ringo> Subject: Re: TECH-OMISSION: Divergent assumptions about objectives Date: Mon, 30 Aug 2004 20:32:37 +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 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 19:51:19.0695 (UTC) FILETIME=[B82161F0:01C48ECA] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Please correct my typing error. I sent: > > One particular form of lying involves forging the RFC 2821 'From:' header, so > that the recipient ascribes to the message an authority which it does not > actually have. Please replace 2821 by 2822 in the above. Chris From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:34: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 GAA04432 for ; Tue, 31 Aug 2004 06:34: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 i7VABSur053521; Tue, 31 Aug 2004 03:11: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 i7VABS4u053520; Tue, 31 Aug 2004 03:11:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VABQP1053497 for ; Tue, 31 Aug 2004 03:11:27 -0700 (PDT) (envelope-from john@jlc.net) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:51:48 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:50 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 22:27:25 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 22:29:56 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 22:29:07 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKDKlY002505; Mon, 30 Aug 2004 13:13: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 i7UKDKqR002504; Mon, 30 Aug 2004 13:13:20 -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 i7UKDJh6002489 for ; Mon, 30 Aug 2004 13:13:19 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 161A2E0534; Mon, 30 Aug 2004 16:13:20 -0400 (EDT) Date: Mon, 30 Aug 2004 16:13:20 -0400 From: John Leslie To: mazieres@gmail.com Cc: John Leslie , MXCOMP Subject: Re: Reputation services for SenderID Message-ID: <20040830201320.GN465@verdi> References: <81AC085044D04B429F5FB883D94FA1AF8FAFE3@df-fido-msg.exchange.corp.microsoft.com> <20040827231531.GI465@verdi> <94df60cf040829152232ce5533@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94df60cf040829152232ce5533@mail.gmail.com> User-Agent: Mutt/1.4.1i List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 20:29:08.0087 (UTC) FILETIME=[00328870:01C48ED0] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: mazieres@gmail.com wrote: > On Fri, 27 Aug 2004 19:15:31 -0400, John Leslie wrote: >> ... >> We then evaluate the list of IPs authorized by the SPF2 record, >> and run them against known IP blacklists; accumulating a score based >> on weighting the reputation of those blacklists for spam identified, >> false negatives, and false positives. > > This might usually work, but what do you do about the exists and ptr > mechanisms? In general there is no practical and 100% reliable way to > produce a list of IP addresses authorized by an SPF2 record. I didn't want to get into that level of detail -- and I especially don't want to tell reputation services how to run their business... But you are correct to note that exists and ptr are too close for comfort to the +all mechanism. IMHO, one would have to treat them as "+all" unless you have access to a large enough corpus of actual queries and replies to limit the set of IP addresses apparently authorized. (I don't believe monte carlo techniques are workable.) How large "large enough" is, I leave as an exercise to the student. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:38:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04736 for ; Tue, 31 Aug 2004 06:38:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VAEtXq054015; Tue, 31 Aug 2004 03: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 i7VAEtZW054014; Tue, 31 Aug 2004 03:14:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VAEnXe053986 for ; Tue, 31 Aug 2004 03:14:53 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:51:36 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:45 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 21:28:42 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 21:31:14 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 21:30:18 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UJDLeU088320; Mon, 30 Aug 2004 12:13: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 i7UJDLDv088319; Mon, 30 Aug 2004 12:13:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from proton.pathname.com (proton.pathname.com [209.204.178.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UJDKlb088300 for ; Mon, 30 Aug 2004 12:13:20 -0700 (PDT) (envelope-from quinlan@pathname.com) Received: from quinlan by proton.pathname.com with local (Exim 3.35 #1 (Debian)) id 1C1raf-0008JQ-00; Mon, 30 Aug 2004 12:13:17 -0700 To: Andrew Newton Cc: Sam Varshavchik , IETF MARID WG Subject: Re: DEPLOY: SPF/Sender ID support in Courier. References: From: Daniel Quinlan Date: 30 Aug 2004 12:13:17 -0700 In-Reply-To: Andrew Newton's message of "Mon, 30 Aug 2004 12:21:32 -0400" Message-ID: Lines: 74 X-Mailer: Gnus v5.7/Emacs 20.7 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 19:30:18.0221 (UTC) FILETIME=[C83BB9D0:01C48EC7] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew Newton writes: > The IETF does not require a royalty free license. Sure, but it seems evident that RF is practically a requirement for MARID acceptance and consensus. >> It appears that IETF's contemporary policies do not prevent the >> sponsor/advocates from including patented IP material into >> standards-track specifications, without even requiring the sponsor to >> actually enumerate and identify their intellectual property; a mere >> claim of the existence of some nebulous IP rights is sufficient, which >> can be revealed at any point in the future, at the sponsor's >> discretion. > I'm not sure what point you are trying to make here. Fill in the blanks. > 1) How do you base your decision on incompatibility? I ask this because > Courier uses OpenSSL and ships with a file called COPYING which states: >> This software is released under the GPL, version 2 (see COPYING.GPL). >> Additionally, compiling, linking, and/or using the OpenSSL toolkit in >> conjunction with this software is allowed. > According to the FSF, the OpenSSL license is also incompatible with > the GPL. Additionally, is the webmail part of Courier licensed in a > different way? I believe the Courier author could fix this by adding an exception to the license. Also, it's possible the usage of OpenSSL is okay if you consider OpenSSL to be part of the operating system, but that seems like a stretch from what I've read. Your message seems to boil down an ad hominem tu quoque that revolves around orthogonal issues. OpenSSL could be replaced by another library with the same API. OpenSSL or Courier could tweak their license. Patents often can't be worked around unless the owner changes their license... especially if you don't know what the patents cover. > Would there be issues using it with Apache since the FSF also > considers the Apache license to be incompatible with the GPL? The ASF believes that Apache License 2.0 is compatible with the GPL. http://www.apache.org/licenses/GPL-compatibility.html > 2) Based on my limited understanding of Courier, it seems that the only > document in the Sender ID docset that needs to be implemented directly > into Courier is the SUBMITTER ESMTP extension. The encumbered portions > of Sender ID, -core and -pra, could easily be implemented in a separate > module using the courierfilter interface. Are you unwilling to > incorporate the unencumbered SUBMITTER even if a core/pra courierfilter > were available? -core is the document that ties it all together so the unknown patents could cover ... well, I don't know what, but more than PRA. You may be right that the Courier author might be able to include enough of Sender-ID to support it and help make it a success. The separate module would not really be open source, though. > 3) If somebody were to patch Courier with Sender ID and distribute it > with such modifications, would you take legal action against them? That seems like a hard question to answer given that you can't predict the nature of a future license violation. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/ From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 06:43:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04983 for ; Tue, 31 Aug 2004 06:43:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VAJDQT054757; Tue, 31 Aug 2004 03:19: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 i7VAJDxH054756; Tue, 31 Aug 2004 03:19:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailgate.gfifax.com (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VAJBkK054739 for ; Tue, 31 Aug 2004 03:19:12 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 11:51:25 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 10:37:44 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Aug 2004 21:13:51 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 21:16:22 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 30 Aug 2004 21:15:29 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UIxVAR085227; Mon, 30 Aug 2004 11: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 i7UIxV5Q085226; Mon, 30 Aug 2004 11:59:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UIxVsS085220 for ; Mon, 30 Aug 2004 11:59:31 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 6C3A7414C4 for ; Mon, 30 Aug 2004 11:59:35 -0700 (PDT) Subject: TECH-OMISSION: Security considerations and limit scope From: Douglas Otis To: IETF MARID WG In-Reply-To: <16682.31117.662266.736155@proton.pathname.com> References: <16682.31117.662266.736155@proton.pathname.com> Content-Type: text/plain Message-Id: <1093892373.5542.192.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 11:59:34 -0700 Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Aug 2004 19:15:29.0233 (UTC) FILETIME=[B65AEC10:01C48EC5] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Protocol & Core There is no security advice for using random source ports for DNS queries reaching the Internet. There is no advice regarding the potential presence of transparent inception of outbound SMTP traffic by ISPs. There is no advice waring against the use of "?all" in the case of shared outbound SMTP servers. There is no advice for the use of "+all". Jim Lyon explained this will lead to bad reputations. This implies the mailbox domain, used to resolve the MTA address, is also being used to establish reputations, even when the MTA is not authorized! There should be advice warning against establishing reputation information when the MTA address has not been authenticated, or when the SPF2 record uses "?all". It must not be presumed all MTAs check for the SPF2 permissions, or that the outbound MTA is not shared, nor can this checking and sharing be verified. There should be a caution that prohibits reputations based upon non-authorized MTAs. There should also be a warning for "?all" when the outbound path is shared. This sharing will "promote" mail from other domains as being fully validated and may lead to false assumptions with respect to the recipient, when the Mailbox domain is used to either obtain or record this information. There should be advice that only the IP address should be used to check reputations and to base complaints, as the Mailbox domain has not been adequately authenticated while it can not be presumed all MTA servers in the path of the message performed the requisite mail channel checks and that the MTA is not shared with other disparately administered domains. Don't limit the scope of the SPF record to just PRA plus others. Leave the record open to any scope that may exclude PRA. The use of exists and ptr record types adds a burden the recipient may not wish to endure. There should be a warning that this type of record may be rejected. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 08:02: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 IAA10851 for ; Tue, 31 Aug 2004 08:02: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 i7VBSuVI066143; Tue, 31 Aug 2004 04:28: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 i7VBSuBm066142; Tue, 31 Aug 2004 04:28:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VBStWE066127 for ; Tue, 31 Aug 2004 04:28:55 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1C26ok-0005s2-2W for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 06:28:54 -0500 To: "IETF MARID WG" References: <41341DD0.7010008@sendmail.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 31 Aug 2004 06:28:35 -0500 In-Reply-To: <41341DD0.7010008@sendmail.com> (Rand Wacker's message of "Mon, 30 Aug 2004 23:42:24 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Sendmail releases open source Sender ID milter for testing Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <41341DD0.7010008@sendmail.com> Rand Wacker writes: > The milter for testing Sender ID is available at: > > http://sendmail.net/sid-milter/ Actually, the download is hosted on sourceforge. Have you made sure that sourceforge is aware that all of there dozens of mirror sites will have to sign a license in order to distribute this code? -wayne From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 11:55: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 LAA27243 for ; Tue, 31 Aug 2004 11:55: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 i7VFPS34023766; Tue, 31 Aug 2004 08:25:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VFPShP023765; Tue, 31 Aug 2004 08:25:28 -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 i7VFPRVW023754 for ; Tue, 31 Aug 2004 08:25:27 -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 i7VFPRvu004944 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 31 Aug 2004 08:25:27 -0700 Message-ID: <081401c48f6e$c6777ab0$3201a8c0@rasta> From: "Harold A'Hole" To: "IETF MARID WG" References: <41341DD0.7010008@sendmail.com> Subject: Re: Sendmail releases open source Sender ID milter for testing Date: Tue, 31 Aug 2004 08:25:34 -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 > Actually, the download is hosted on sourceforge. Have you made sure > that sourceforge is aware that all of there dozens of mirror sites > will have to sign a license in order to distribute this code? There's no need to sign a license because there's no evidence that MSFT owns anything that requires such a license. MSFT may have preliminary claims, but until they prove they own it, nobody should bother with the license. It's like buying a license from SCO for Linux. Only a fool would fall for such a trick. Harry From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 11:57: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 LAA27393 for ; Tue, 31 Aug 2004 11:57: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 i7VFUHRh024636; Tue, 31 Aug 2004 08:30: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 i7VFUHaW024635; Tue, 31 Aug 2004 08:30:17 -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 i7VFUGdl024627 for ; Tue, 31 Aug 2004 08:30:16 -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 1C2AWY-0000Sh-RM for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 10:30:18 -0500 To: "IETF MARID WG" Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> From: wayne Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Tue, 31 Aug 2004 10:26:18 -0500 In-Reply-To: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> (Anne P. Mitchell's message of "Mon, 30 Aug 2004 11:04:37 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com X-SA-Exim-Scanned: No (on backbone.midwestcs.com); SA Timed out after 240 secs Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> "Anne P. Mitchell, Esq." writes: > Can anyone say with 100% certainty that there is *zero* technology, > software, or process, which can be reasonably argued by Microsoft to > belong to them, with regards to *checking*? [...] IANAL and I feel a little nervous providing answers to a lawyer, but here it goes anway. I believe that MS's claims do not cover the marid-protocol draft, which is basically SPF checks, with only the identity used by SPF removed. First off, this question was explicitly asked at the IETF-60 MARID session and the answer that Harry Katz gave was that the patents applied to only marid-core. (marid-core has since been broken into two I-Ds, both of which have the MS IPR claim.) See the timestamp around 17:25. psa was the jabber scribe. http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html Audio archives of this session are also, so if you poke around to find the right spot, you can hear Harry's answers directly. Secondly, by participating in the MARID mailing list, you are required to read the "NOTE WELL" IETF information (see http://www.ietf.org/NOTEWELL.html ). This refers you to RFC3667 and RFC3668. In RFC3667 section 5.1, says that people who submit I-Ds must disclose IPR claims, although it is not clear tome if this means for all I-Ds that they know of, or only the one that they are submitting. RFC3668 section 6 is much clear and explicitly says that you must disclose IPR that you know of that are contributed by others. See: http://www.ietf.org/rfc/rfc3668.txt Since MS has not give such notices on the marid-protocl I-D, I am 99% certain that MS is not claiming any IPR on it. *PLEASE* correct me if I'm wrong. > Is the method for checking under Sender I.D. *identical* to the method > for checking for SPF? Well, there have been some changes in the marid-protocol spec compared with earlier SPF specs, but they are pretty minor. (e.g., marid-protocl uses a different version string.) So, I think for all practical purposes, the answer is "yes". > And to be honest, for the life of me, I don't understand why SPF, > which already had a lot of support from other corners, isn't what's > being pushed now. The two main claimed reasons for using the PRA algorithm in the merged SPF and CallerID proposals are: 1) The PRA "protects what users see, e.g. the From: header". (Never mind that the PRA really just protects the Resent-Sender: header which almost no one sees.) 2) Using the PRA makes it easier for mail forwarders to comply. (Never mind that support for mail forwarders on many open source MTAs has been around for a fair while now. OTOH, I know of *no* support for forwarders to add the headers required for the PRA. Even the just announced milter from Sendmail doesn't appear have the required support.) While those are the claimed reasons, I think it is quite clear from talking to quite a few people involved with this working group that the REAL reason is: * People want MS on board because it would *really* help deployment and MS *really* wants their PRA algorithm. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 11:59: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 LAA27758 for ; Tue, 31 Aug 2004 11:59:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFRhIQ024214; Tue, 31 Aug 2004 08:27: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 i7VFRhGN024213; Tue, 31 Aug 2004 08:27:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFRgMq024203 for ; Tue, 31 Aug 2004 08:27:42 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2AXu-0007CK-0o for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 11:27:43 -0400 Message-ID: <413498DF.9090008@solidmatrix.com> Date: Tue, 31 Aug 2004 11:27:27 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Sendmail releases open source Sender ID milter for testing References: <41341DD0.7010008@sendmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > In <41341DD0.7010008@sendmail.com> Rand Wacker writes: > > >>The milter for testing Sender ID is available at: >> >> http://sendmail.net/sid-milter/ > > > Actually, the download is hosted on sourceforge. Have you made sure > that sourceforge is aware that all of there dozens of mirror sites > will have to sign a license in order to distribute this code? > The patent license only affects implementors, the code can be freely distributed. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 12:07: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 MAA28651 for ; Tue, 31 Aug 2004 12:07:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFdvl0026485; Tue, 31 Aug 2004 08:39: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 i7VFdvNu026484; Tue, 31 Aug 2004 08:39:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7VFduX9026433 for ; Tue, 31 Aug 2004 08:39:56 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 885 invoked by uid 1013); 31 Aug 2004 15:39:45 -0000 Date: Tue, 31 Aug 2004 17:39:45 +0200 From: Markus Stumpf To: IETF MARID WG Subject: Re: Sendmail releases open source Sender ID milter for testing Message-ID: <20040831153945.GC96404@Space.Net> References: <41341DD0.7010008@sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 31, 2004 at 06:28:35AM -0500, wayne wrote: > Actually, the download is hosted on sourceforge. Have you made sure > that sourceforge is aware that all of there dozens of mirror sites > will have to sign a license in order to distribute this code? And all e.g. ISPs that deploy it on hosts they manage for customers will have to sign the license, too. \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 Tue Aug 31 12:13: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 MAA29245 for ; Tue, 31 Aug 2004 12:13: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 i7VFpi0n028638; Tue, 31 Aug 2004 08:51: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 i7VFpiW2028637; Tue, 31 Aug 2004 08:51:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFphHn028631 for ; Tue, 31 Aug 2004 08:51:43 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2AvA-0008J5-14 for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 11:51:46 -0400 Message-ID: <41349E85.2030101@solidmatrix.com> Date: Tue, 31 Aug 2004 11:51:33 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "IETF MXCOMP (E-mail)" Subject: DOC-BUG: Acknowledgements Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I want to point that the acknowledgments section in the various drafts differs greatly. For example, in draft-ietf-marid-protocol-02.txt the acknowledgment section thanks hundreds of people, while in in draft-ietf-marid-core-03.txt it only mentions MARID participants and some previous drafts. Perhaps it might be useful to synchronize some of these among the various drafts. I personally like the one in draft-ietf-marid-protocol-02.txt as it covers majority of people. Also, in draft-ietf-marid-submitter-03.txt credit should be given to Nick Shelness. This idea was also mentioned on the ASRG list a few times, for example: http://www1.ietf.org/mail-archive/web/asrg/current/msg09245.html Also, in draft-ietf-marid-rationale-00.txt not only the acknowledgment section is missing but the references section is incomplete and the entire draft is raw. It needs more editing. In draft-ietf-marid-protocol-02.txt, a previous draft by David Green is not mentioned, as well as no mention of the SPF and ASRG communities like the protocol draft does. Considering that the ASRG contributed all the drafts to the MARID group and the SPF community worked on SPF, some mention might be proper. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 12:14: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 MAA29364 for ; Tue, 31 Aug 2004 12:14: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 i7VFjYaL027394; Tue, 31 Aug 2004 08:45: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 i7VFjYre027393; Tue, 31 Aug 2004 08:45:34 -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 i7VFjWPl027378 for ; Tue, 31 Aug 2004 08:45:32 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 1126 invoked by uid 1013); 31 Aug 2004 15:45:34 -0000 Date: Tue, 31 Aug 2004 17:45:34 +0200 From: Markus Stumpf To: "Anne P. Mitchell, Esq." Cc: "IETF-MXCOMP WG'" Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) Message-ID: <20040831154534.GD96404@Space.Net> References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.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 Mon, Aug 30, 2004 at 11:04:37AM -0700, Anne P. Mitchell, Esq. wrote: > We simply _don't_ know what is in the claim. In any other area where > adoption of some program is to be impacted or encumbered in some way > which could cause either a legal liability or an inability to actually > implement on the part of the adopter - particularly such a potentially > widely used program - it is inconceivable that people would be even > considering adopting, or recommending, the program. In fact, if one > had a professional license, and recommended adoption of such a program > without a clear understanding of the encumberance, one could be guilty > of malpractice. IANAL and not even a native english speaker. What really puzzles me is the term "perpetual" in the license and the meaning. My dictionary has some possibilities like eternal but also for an unlimited period The first would be not too big a problem, the second would be an immense problem as MS could in one year from now terminate the existing license contracts and formulate a new one with a fee, right? \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 Tue Aug 31 12:19:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00129 for ; Tue, 31 Aug 2004 12:19: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 i7VFrRPs028920; Tue, 31 Aug 2004 08:53: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 i7VFrRII028919; Tue, 31 Aug 2004 08:53:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFrQjr028912 for ; Tue, 31 Aug 2004 08:53:26 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2Awq-0008Mx-2Y for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 11:53:29 -0400 Message-ID: <41349EEC.8000407@solidmatrix.com> Date: Tue, 31 Aug 2004 11:53:16 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "IETF MXCOMP (E-mail)" Subject: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit (This message got stuck originally because of my own stupidity, I am resending it to the list) > Andrew Newton wrote: > >> 4) You have stated above that you believe Microsoft's claim is >> "nebulous" with regard to rights being claimed. Your release notes >> state "Implemented Sender Policy Framework checking on the From: >> header. Be sure to read the documentation and understand the >> implication." Since checking of the From: header is listed in the -pra >> document, are you concluding that this is not encumbered by Microsoft's >> claim? If so, how did you come to this conclusion? >> > > The ASRG archive runs several thousand messages. They start with a > discussion on RMX. There is more than one message in there talking about > the use of "From" headers for RMX lookup. If someone has the time to go > through it, prior art is certain to be found. Perhaps someone should > tell the lawyers. > > IMHO, in light of the possible prior art, it may be very probably that > the potential patent application is invalid or will not approved. > Therefore, it might be feasible to ignore the IPR claim all together and > preceed with approval of Sender-ID. > > > In any case, for example, here is a is a message posted to the ASRG list > on May 7th, 2003 > (http://www1.ietf.org/mail-archive/web/asrg/current/msg04390.html): > > -----snip---- > On Wed, May 07, 2003 at 07:43:10AM -0700, Daniel Erat wrote: > > I understand why RMX is not able to examine RFC 822 headers. My point > > was that RMX does nothing to curtail the sending of messages with > > forged 822 From: addresses. Since this is the only sender address > > that most users see, and the address that replies go to (in absence of > > a Reply-To: or related header), I disagree with the assertion that > > this is not a severe problem. > > Well, RMX could be used to verify the From: address as well. > Feel free to ask your MTA to do another RMX lookup after > receiving the message body (and before sending the reply code). > If you like it, you can do it. > -----snip---- > > Another message as a reply to Bob Atkinson, the author of Caller-ID, > talks about parsing "Received" lines: > http://www1.ietf.org/mail-archive/web/asrg/current/msg04321.html > > Another messaging discussing headers: > http://www1.ietf.org/mail-archive/web/asrg/current/msg04591.html > > A snippet of actual code that compares headers against DNSBLs in the > context of the RMX discussion: > http://www1.ietf.org/mail-archive/web/asrg/current/msg00686.html > =========================================== > On a related note, here is a message posted on May 5th, 2003 by Bob > Atkinson, the author of the Caller-ID draft talking about "domain > purportedly responsible for a message: > http://www1.ietf.org/mail-archive/web/asrg/current/msg04231.html > > Another message from Bob dated May 6th, 2003 talking about the use of > XML for RMX records and enhancing the RMX proposal: > http://www1.ietf.org/mail-archive/web/asrg/current/msg04302.html > > Another message talking about "From" headers, also from Bob: > http://www1.ietf.org/mail-archive/web/asrg/current/msg04333.html > > Here is a message from another Microsoft employee dated March 6th, 2003 > regarding RMX: > http://www1.ietf.org/mail-archive/web/asrg/current/msg00608.html > > Another few messages from a Microsoft employee critisizing RMX: > http://www1.ietf.org/mail-archive/web/asrg/current/msg00646.html > http://www1.ietf.org/mail-archive/web/asrg/current/msg00671.html > > ==================================================================== > If we take a look in RFC 2014, we find the following in section 1: > > "Participation is by individual contributors, rather than by > representatives of organizations." > > We also find that the ASRG adopted an following IPR policy on June 12th, > 2003, requiring disclosure of IPR: > http://www1.ietf.org/mail-archive/web/asrg/current/msg05378.html > > At least one message was posted from Bob Atkinson after this policy was > adapted without disclosing any IPR information: > http://www1.ietf.org/mail-archive/web/asrg/current/msg07090.html > > Here is another one discussing reputation systems from Bob Atkinson on > October 31st, 2003: > http://www1.ietf.org/mail-archive/web/asrg/current/msg07875.html > > Frequent readers of the ASRG list will note that Phil Hallam-Baker of > Verisign explicitly stated a few times that his company may claim IPR on > specific ideas he shared with the ASRG list. To my knowledge, none of > the Microsoft employees ever did that. > > Also, the ASRG list is hosted at the IETF domain. We find the following > notice at IETF's mailing list page (http://www.ietf.org/maillist.html): > > ----------------------------------------------------------------------- --- > Any submission to the IETF intended by the Contributor for publication > as all or part of an IETF Internet-Draft or RFC and any statement made > within the context of an IETF activity is considered an "IETF > Contribution". Such statements include oral statements in IETF sessions, > as well as written and electronic communications made at any time or > place, which are addressed to: > the IETF plenary session, > any IETF working group or portion thereof, > the IESG, or any member thereof on behalf of the IESG, > the IAB or any member thereof on behalf of the IAB, > any IETF mailing list, including the IETF list itself, any working group > or design team list, or any other list functioning under IETF auspices, > the RFC Editor or the Internet-Drafts function > ----------------------------------------------------------------------- --- > > The ASRG list maybe considered "any other list functioning under IETF > auspices" and posting to it may be considered "any statement made within > the context of an IETF activity is considered an "IETF Contribution". > However, it is unclear whether IRTF lists fall under that. If the ASRG > list does in fact fall under that, than postings to it are considered > "Contributions to the IETF" and are covered under RFC 3667 and 3668: > > Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 12:45:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03662 for ; Tue, 31 Aug 2004 12:45: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 i7VGPuTa032438; Tue, 31 Aug 2004 09:25: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 i7VGPuwT032437; Tue, 31 Aug 2004 09:25:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGPtnG032430 for ; Tue, 31 Aug 2004 09:25:55 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1C2BSC-0001Ag-BM for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 11:25:58 -0500 To: "IETF MARID WG" References: <41341DD0.7010008@sendmail.com> <413498DF.9090008@solidmatrix.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 31 Aug 2004 11:25:48 -0500 In-Reply-To: <413498DF.9090008@solidmatrix.com> (Yakov Shafranovich's message of "Tue, 31 Aug 2004 11:27:27 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Sendmail releases open source Sender ID milter for testing Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.6 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <413498DF.9090008@solidmatrix.com> Yakov Shafranovich writes: > wayne wrote: > >> Actually, the download is hosted on sourceforge. Have you made sure >> that sourceforge is aware that all of there dozens of mirror sites >> will have to sign a license in order to distribute this code? > > The patent license only affects implementors, the code can be freely > distributed. Really? From the SenderID licenses: 2.2 _Source_Code_Distribution_ You also have [...] a perpetual, non-exclusive, royalty-free, nontransferable, non-sublicenseable, personal, worldwide license to distribute or otherwise disclose source code copies of such Licensed Implementation licensed in Section 2.1 only if You [...] 'This source code may incorporate intellectual property owned by Microsoft Corporation that is necessary to implement the IETF Sender ID Specification. [...] Our provision of this source code does not include any licenses or any other rights to you under any Microsoft intellectual property. If you would like a license from Microsoft (e.g. rebrand, redistribute), you need to contact Microsoft directly.' This seems pretty clear, if you want to rebrand or redistribute the source code, you need to contact MS and get a license. Sourceforge is *not* the implementor, Sendmail is. Souceforge is just redistributing the source code. For clarification, this Agreement does not impose any obligation on You to require the recipients of Your source code implementations of such Licensed Implementations to accept this or any other Agreement with Microsoft. Your End Users may use the Licensed Implementations licensed in this section 2.2 or in section 2.1 that they receive directly or indirectly from You without executing this Agreement. [...] Sourceforge is not an "End User", therefore I don't think Sendmail's license for their implementation applies to SF. Please explain what I'm missing. This subject has been discussed a fair amount on this list, and I haven't seen anyone say that ftp mirrors and such would not be required to sign a license. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 12:47:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03898 for ; Tue, 31 Aug 2004 12:47: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 i7VGMtJA032228; Tue, 31 Aug 2004 09:22: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 i7VGMtbo032227; Tue, 31 Aug 2004 09:22:55 -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 i7VGMs9a032220 for ; Tue, 31 Aug 2004 09:22:54 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 2135 invoked by uid 1013); 31 Aug 2004 16:22:56 -0000 Date: Tue, 31 Aug 2004 18:22:56 +0200 From: Markus Stumpf To: IETF MARID WG Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) Message-ID: <20040831162256.GE96404@Space.Net> References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 31, 2004 at 10:26:18AM -0500, wayne wrote: > While those are the claimed reasons, I think it is quite clear from > talking to quite a few people involved with this working group that > the REAL reason is: > * People want MS on board because it would *really* help deployment > and MS *really* wants their PRA algorithm. Why will that help deployment? The latest surveys state that MS SMTP servers have less than 10% market share. I'd say having sendmail + qmail + postfix + exim will help more than having MS on board for whatever solution. \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 Tue Aug 31 12:53: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 MAA04494 for ; Tue, 31 Aug 2004 12:53: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 i7VGRHj8032544; Tue, 31 Aug 2004 09:27: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 i7VGRHee032543; Tue, 31 Aug 2004 09:27:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGRGCI032537 for ; Tue, 31 Aug 2004 09:27:16 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2BTX-00028P-Km for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 12:27:17 -0400 Message-ID: <4134A6D7.8050503@solidmatrix.com> Date: Tue, 31 Aug 2004 12:27:03 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > In <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> "Anne P. Mitchell, Esq." writes: > > >>Can anyone say with 100% certainty that there is *zero* technology, >>software, or process, which can be reasonably argued by Microsoft to >>belong to them, with regards to *checking*? [...] > > > IANAL and I feel a little nervous providing answers to a lawyer, but > here it goes anway. > > I believe that MS's claims do not cover the marid-protocol draft, > which is basically SPF checks, with only the identity used by SPF > removed. > > First off, this question was explicitly asked at the IETF-60 > MARID session and the answer that Harry Katz gave was that the patents > applied to only marid-core. (marid-core has since been broken into > two I-Ds, both of which have the MS IPR claim.) > > See the timestamp around 17:25. psa was the jabber scribe. > http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-08-04.html > > Audio archives of this session are also, so if you poke around to find > the right spot, you can hear Harry's answers directly. > To play devil's advocate, it really doesn't matter what he said until we see it in writing from Microsoft's lawyers. > > Secondly, by participating in the MARID mailing list, you are required > to read the "NOTE WELL" IETF information (see > http://www.ietf.org/NOTEWELL.html ). This refers you to RFC3667 and > RFC3668. In RFC3667 section 5.1, says that people who submit I-Ds > must disclose IPR claims, although it is not clear tome if this means > for all I-Ds that they know of, or only the one that they are > submitting. RFC3668 section 6 is much clear and explicitly says that > you must disclose IPR that you know of that are contributed by > others. See: http://www.ietf.org/rfc/rfc3668.txt > > Since MS has not give such notices on the marid-protocl I-D, I am 99% > certain that MS is not claiming any IPR on it. > > *PLEASE* correct me if I'm wrong. > Lets add to that that the note well information may apply to list postings, including the ASRG list which is hosted at ietf.org, and you got yourself a can of legal worms. To my knowledge, Microsoft employees have never disclosed any potential IPR information on the ASRG list unlike what Phil Hallam-Baker and others have done. >>And to be honest, for the life of me, I don't understand why SPF, >>which already had a lot of support from other corners, isn't what's >>being pushed now. > > > The two main claimed reasons for using the PRA algorithm in the merged > SPF and CallerID proposals are: > > 1) The PRA "protects what users see, e.g. the From: header". (Never > mind that the PRA really just protects the Resent-Sender: header > which almost no one sees.) > > 2) Using the PRA makes it easier for mail forwarders to comply. > (Never mind that support for mail forwarders on many open source > MTAs has been around for a fair while now. OTOH, I know of *no* > support for forwarders to add the headers required for the PRA. > Even the just announced milter from Sendmail doesn't appear have > the required support.) > > While those are the claimed reasons, I think it is quite clear from > talking to quite a few people involved with this working group that > the REAL reason is: > > * People want MS on board because it would *really* help deployment > and MS *really* wants their PRA algorithm. > It is also interesting to note that the protection of the "From:" header has been discussed at least a year and a half ago on the ASRG list here: http://www1.ietf.org/mail-archive/web/asrg/current/msg04390.html The use of XML for storing RMX records was first proposed on the ASRG list here: http://www1.ietf.org/mail-archive/web/asrg/current/msg04302.html I wonder how the IETF's IPR policy in the "note well" text applies here. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 13:12:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06007 for ; Tue, 31 Aug 2004 13:12: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 i7VGp8JU036195; Tue, 31 Aug 2004 09:51:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VGp8qb036193; Tue, 31 Aug 2004 09:51:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from iadonisi.to (gw.iadonisi.to [66.92.68.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGp75r036173 for ; Tue, 31 Aug 2004 09:51:07 -0700 (PDT) (envelope-from pri.marid@iadonisi.to) Received: from [192.168.111.8] (gw.local.linuxlobbyist.org [192.168.111.1]) (authenticated bits=0) by iadonisi.to (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id i7VGo1b0018537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Aug 2004 12:50:07 -0400 Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) From: Paul Iadonisi To: IETF MARID WG In-Reply-To: <20040831162256.GE96404@Space.Net> References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> <20040831162256.GE96404@Space.Net> Content-Type: text/plain Message-Id: <1093970969.9301.9.camel@va.local.linuxlobbyist.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 31 Aug 2004 12:49:29 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-31 at 12:22, Markus Stumpf wrote: > On Tue, Aug 31, 2004 at 10:26:18AM -0500, wayne wrote: > > While those are the claimed reasons, I think it is quite clear from > > talking to quite a few people involved with this working group that > > the REAL reason is: > > * People want MS on board because it would *really* help deployment > > and MS *really* wants their PRA algorithm. > > Why will that help deployment? > The latest surveys state that MS SMTP servers have less than 10% > market share. > I'd say having sendmail + qmail + postfix + exim will help more than > having MS on board for whatever solution. I made this point a while ago on the spf-discuss list. While it would be nice to have Microsoft on board, they do *not* have the lion's share of the installed base of internet facing SMTP servers. That's where most of implementation of these standards will take place. I would be quite disappointing if this draft was pushed through with the current patent license because someone thought 'we need Microsoft'. Even if we did, shunning this license does not have to mean pushing Microsoft out, so to me, it would make no sense to push this through just because someone thinks we need Microsoft. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 13:12: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 NAA06025 for ; Tue, 31 Aug 2004 13:12: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 i7VGmDhd035694; Tue, 31 Aug 2004 09:48:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VGmDG4035693; Tue, 31 Aug 2004 09:48:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGmCw0035677 for ; Tue, 31 Aug 2004 09:48:12 -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 (Email Firewall v6.0.0)); Tue, 31 Aug 2004 09:48:12 -0700 X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Tue, 31 Aug 2004 09:47:58 -0700 Message-ID: From: "Daryl Odnert" To: "'Chris Haynes'" , "IETF MARID WG" Subject: RE: TECH-OMISSION: Security vulnerability - Malicious DSN attacks Date: Tue, 31 Aug 2004 09:47:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-WSS-ID: 6D2A74462ZG15375-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48F7A.4189BA46" 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_01C48F7A.4189BA46 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Chris Haynes wrote: > > Normally, only MTAs that are operated by (or trusted by) V for outbound > > SMTP mail processing would be configured this way. Therefore, the attack > > is only likely to occur if it can be launched from an IP address that > > normally submits mail from V to P. > > I'm very sorry, I just don't understand this point. > Dues it change in the light of my comments / draft amendments above? My point is that the vulnerability your are describing presumes the existence of an MTA (which you've labeled P) with several assumptions made about the behavior of that MTA. You need to make it clear what those assumptions are so that others can fairly assess the risks. One of the assumptions you have made is that P is normally willing to accept a message where the SMTP sender is V and the recipient is R. Let's assume that V and R are distinct domains. Nearly every MTAs in use today has configuration controls to prevent "open relaying". These controls limit the IP addresses from which mail will be accepted for relaying to outside domains. Most MTAs will perform the open relaying check immediately after the RCPT command or immediately after the end of the message DATA is received. The message is rejected during the SMTP conversation if the combination of (client IP address, sender address, recipient address) is unacceptable to the MTA. Assuming the MTA at P is not configured as an open relay and that IP address spoofing is not involved, the only way that P will accept a message with a sender address in V and recipient in domain R is if the SMTP client is one that P believes is "owned by" V - that is, it normally sends mail to P on behalf of V. To put it in simple terms, you cannot launch this type of attack against V using P using unless one of the following is true: (1) P is an open relay. (2) The attack messages are sent to P from an IP address that normally sends mail for domain V. (3) IP address spoofing is used to make it look like the attack message is coming from an IP address that normally sends mail for domain V. Do you agree? If so, then I think this is important to mention because it significantly reduces the risk level associated with the vulnerability you're writing about; one cannot easily launch this type of attack from anywhere on the Internet. Regards, Daryl Odnert Tumbleweed Communications Redwood City, California ------_=_NextPart_001_01C48F7A.4189BA46 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: TECH-OMISSION: Security vulnerability - Malicious DSN attacks

Chris Haynes wrote:
> > Normally, only MTAs that are operated by (or trusted by) V for outbound
> > SMTP mail processing would be configured this way.  Therefore, the attack
> > is only likely to occur if it can be launched from an IP address that
> > normally submits mail from V to P.
>
> I'm very sorry, I just don't understand this point.
> Dues it change in the light of my comments / draft amendments above?

My point is that the vulnerability your are describing presumes the
existence of an MTA (which you've labeled P) with several
assumptions made about the behavior of that MTA.  You need to make it
clear what those assumptions are so that others can fairly assess the
risks.

One of the assumptions you have made is that P is normally willing
to accept a message where the SMTP sender is V and the recipient is R.
Let's assume that V and R are distinct domains.  Nearly every MTAs in
use today has configuration controls to prevent "open relaying".  These
controls limit the IP addresses from which mail will be accepted for
relaying to outside domains.  Most MTAs will perform the open relaying
check immediately after the RCPT command or immediately after the end
of the message DATA is received.  The message is rejected during the
SMTP conversation if the combination of (client IP address, sender
address, recipient address) is unacceptable to the MTA.

Assuming the MTA at P is not configured as an open relay and that IP
address spoofing is not involved, the only way that P will accept a
message with a sender address in V and recipient in domain R is if
the SMTP client is one that P believes is "owned by" V - that is, it
normally sends mail to P on behalf of V.

To put it in simple terms, you cannot launch this type of attack
against V using P using unless one of the following is true:

(1) P is an open relay.

(2) The attack messages are sent to P from an IP address that
normally sends mail for domain V.

(3) IP address spoofing is used to make it look like the attack
message is coming from an IP address that normally sends mail for
domain V.

Do you agree?  If so, then I think this is important to mention
because it significantly reduces the risk level associated with
the vulnerability you're writing about; one cannot easily launch
this type of attack from anywhere on the Internet.

Regards,
Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C48F7A.4189BA46-- From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 13:16: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 NAA06350 for ; Tue, 31 Aug 2004 13:16: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 i7VGuGSO037284; Tue, 31 Aug 2004 09:56: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 i7VGuGEf037283; Tue, 31 Aug 2004 09:56:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGuFFx037269 for ; Tue, 31 Aug 2004 09:56:15 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7VH5gLf030655; Tue, 31 Aug 2004 13:05:42 -0400 From: To: "'Daryl Odnert'" , "'Chris Haynes'" , "'IETF MARID WG'" Subject: RE: TECH-OMISSION: Security vulnerability - Malicious DSNattacks Date: Tue, 31 Aug 2004 12:54:28 -0400 Message-ID: <025801c48f7b$2df99fe0$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-reply-to: Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit RE: >Do you agree? If so, then I think this is important to mention >because it significantly reduces the risk level associated with >the vulnerability you're writing about; one cannot easily launch >this type of attack from anywhere on the Internet. I disagree because "anywhere on the internet" has to include the thousands of trojaned workstations (and even servers) that are in the wild. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Daryl Odnert Sent: Tuesday, August 31, 2004 12:48 PM To: 'Chris Haynes'; IETF MARID WG Subject: RE: TECH-OMISSION: Security vulnerability - Malicious DSNattacks Chris Haynes wrote: > > Normally, only MTAs that are operated by (or trusted by) V for outbound > > SMTP mail processing would be configured this way. Therefore, the attack > > is only likely to occur if it can be launched from an IP address that > > normally submits mail from V to P. Do you agree? If so, then I think this is important to mention because it significantly reduces the risk level associated with the vulnerability you're writing about; one cannot easily launch this type of attack from anywhere on the Internet. Regards, Daryl Odnert Tumbleweed Communications Redwood City, California From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 14:23:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12294 for ; Tue, 31 Aug 2004 14:23:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VHwP7M049407; Tue, 31 Aug 2004 10:58: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 i7VHwPHI049404; Tue, 31 Aug 2004 10:58:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VHwNrc049324 for ; Tue, 31 Aug 2004 10:58:24 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2Ctj-0007HD-Us; Tue, 31 Aug 2004 13:58:25 -0400 Message-ID: <4134BC33.9050400@solidmatrix.com> Date: Tue, 31 Aug 2004 13:58:11 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Paul Iadonisi CC: IETF MARID WG Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> <20040831162256.GE96404@Space.Net> <1093970969.9301.9.camel@va.local.linuxlobbyist.org> In-Reply-To: <1093970969.9301.9.camel@va.local.linuxlobbyist.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Iadonisi wrote: > On Tue, 2004-08-31 at 12:22, Markus Stumpf wrote: > >>On Tue, Aug 31, 2004 at 10:26:18AM -0500, wayne wrote: >> >>>While those are the claimed reasons, I think it is quite clear from >>>talking to quite a few people involved with this working group that >>>the REAL reason is: >>>* People want MS on board because it would *really* help deployment >>> and MS *really* wants their PRA algorithm. >> >>Why will that help deployment? >>The latest surveys state that MS SMTP servers have less than 10% >>market share. >>I'd say having sendmail + qmail + postfix + exim will help more than >>having MS on board for whatever solution. > > > I made this point a while ago on the spf-discuss list. While it would > be nice to have Microsoft on board, they do *not* have the lion's share > of the installed base of internet facing SMTP servers. That's where > most of implementation of these standards will take place. > I would be quite disappointing if this draft was pushed through with > the current patent license because someone thought 'we need Microsoft'. > Even if we did, shunning this license does not have to mean pushing > Microsoft out, so to me, it would make no sense to push this through > just because someone thinks we need Microsoft. > We had this argument in the ASRG as well until some pointed out that the PRA algorithm works in MUA. The market share on Microsoft MUAs is over 70%. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 14:23: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 OAA12309 for ; Tue, 31 Aug 2004 14:23: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 i7VHtcom048406; Tue, 31 Aug 2004 10:55: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 i7VHtcFP048405; Tue, 31 Aug 2004 10:55:38 -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 i7VHtbOR048206 for ; Tue, 31 Aug 2004 10:55: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 4B751414C5; Tue, 31 Aug 2004 10:55:33 -0700 (PDT) Subject: RE: DOC-BUG: permitted use of PRA/submitter address From: Douglas Otis To: Harry Katz Cc: mazieres@gmail.com, MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1093974931.17480.53.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 31 Aug 2004 10:55:32 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-08-30 at 22:12, Harry Katz wrote: > On Monday, August 30, 2004 7:07 PM, mazieres@gmail.com > [mailto:mazieres@gmail.com] wrote: > > > Okay, so basically is it the case that Sender ID (in its > > present form) isn't designed to help with these kinds of > > viruses and virus notifiers? At this point, is there any > > possible action the MARID group could take that would allow > > more intelligent virus rejection? I care a lot about this > > problem, and was hoping the outcome of this working group could help. > > I think Sender ID will help with viruses, though perhaps not in the way > you're suggesting. As I understand it, many viruses today are > tranmitted from infected zombie machines, often home computers connected > via cable modem or DSL lines. The IP addresses of these home computers > will not likely be listed by their owning ISPs as legitimate sources of > outbound e-mail. Thus a receiver performing the Sender ID check should > be able to detect "foul play" and reject the message, presumably with a > 5xx type return code rather than by sending an actual bounce message. There are several problems with what appears to be misleading information. If Harry was suggesting the use of a DUL list, then this could indicate whether the ISP has listed these addresses, but then he say it is Sender-ID doing this? Sender-ID does not restrict the IP address placed within an SPF2 record. In fact, the SPF2 record could include the entire Internet. Nor does Sender-ID bother to identity the host sending the mail. This misleading information also seems to imply "?all" records will be refused. If so, the "all" construct should be removed from the draft. To give the virus writer some credit, the virus may use Sender-ID macro syntax to create labels that ensure receiving a "pass" where the scope of the address does not appear out of the norm. In short, Sender-ID does not offer protection from viruses or zombie machines attached to DSL lines. Keep your virus filter running. > > > Not sure I understand this question. However, when an MTA > > > sends a DSN with MAIL FROM <>, the PRA would typically be > > > something like postmaster@example.com or > > > mailer-daemon@example.com. See example 5.5 of the SUBMITTER spec. > > > > Sorry, my question was about receiving, not sending bounces. > > Let me elaborate. Suppose I have two email addresses: > > > > me@myschool.edu > > me-bounces-2004@myschool.edu > > > > Because of the number of bounces I get from viruses, the > > address me@myschool.edu does not accept DSNs. Therefore, I > > always use me-bounces-2004@myschool.edu as the envelope sender. > > > > So far so good. The next question is which address I should > > use as the PRA. If I don't do anything, the PRA will be > > me@myschool.edu, which I would probably prefer. However, > > given that that address refuses DSNs, the question is whether > > there would be grounds for listing me in the rfc-ignorant RBL: > > > > http://www.rfc-ignorant.org/policy-dsn.php > > Thanks for clarifying. Bounces go to the return-path address, not to > the PRA. If you want bounces to go to a specific address you need to > set the MAIL FROM address to the desired address when you send mail. This does not seem to answer the question. If the PRA is compared against the list, then your RFC2822 From will need to be changed, or you will need to include a Resent-From header in your message to preserve the RFC2822 From. You may need to get the Resent-From plug-in. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 14:24: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 OAA12339 for ; Tue, 31 Aug 2004 14:24: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 i7VI4FZA050696; Tue, 31 Aug 2004 11:04:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VI4Fdr050695; Tue, 31 Aug 2004 11:04:15 -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 i7VI4FlJ050689 for ; Tue, 31 Aug 2004 11:04:15 -0700 (PDT) (envelope-from amitchell@isipp.com) Received: from [192.168.0.247] (adsl-64-165-36-235.dsl.snfc21.pacbell.net [64.165.36.235]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i7VI4JMD029373 for ; Tue, 31 Aug 2004 11:04:19 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2D922BA4-FB78-11D8-BA2B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: "Anne P. Mitchell, Esq." Subject: Re: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) Date: Tue, 31 Aug 2004 11:04:18 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > IMHO, in light of the possible prior art, it may be very probably that > the potential patent application is invalid or will not approved. > Therefore, it might be feasible to ignore the IPR claim all together > and > preceed with approval of Sender-ID. Oh dear. Never, *ever* make the mistake of thinking that a patent application will not be approved because of prior art. You'd be stunned at the things which are granted patents where the prior art seems *so* obvious to anyone who knows (and that is a key - the guys at the USPTO can't know everything, and it is not their job to know everything). Right now the MO at the USPTO seems to be "approve everything, and let them sort it out in the courts". Anne From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 14:25: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 OAA12421 for ; Tue, 31 Aug 2004 14:25:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VI0o2i050101; Tue, 31 Aug 2004 11:00:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VI0ovp050100; Tue, 31 Aug 2004 11:00:50 -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 i7VI0mpg050089 for ; Tue, 31 Aug 2004 11:00:49 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 3610 invoked by uid 1013); 31 Aug 2004 18:00:51 -0000 Date: Tue, 31 Aug 2004 20:00:51 +0200 From: Markus Stumpf To: IETF MARID WG Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier) Message-ID: <20040831180051.GJ96404@Space.Net> References: <0E45024F-FAAF-11D8-B42B-000A95AC5778@isipp.com> <20040831162256.GE96404@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040831162256.GE96404@Space.Net> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 31, 2004 at 06:22:56PM +0200, Markus Stumpf wrote: > Why will that help deployment? > The latest surveys state that MS SMTP servers have less than 10% > market share. > I'd say having sendmail + qmail + postfix + exim will help more than > having MS on board for whatever solution. I was asked if I could provide some URLs: Here are links to some recent surveys: http://cr.yp.to/surveys/smtpsoftware6.txt http://www.falkotimme.com/projects/survey_smtp_032004.php http://www.tty1.net/smtp-survey/survey-2004-03-04_de.html http://www.ornl.gov/lists/mailing-lists/qmail/2003/11/msg00245.html Numbers differ in detail but the overall figures are the same. What is also important is the number of users served by the the different MTAs and I know from scratch of no large provider using MS SMTP server, but I may be wrong. \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 Tue Aug 31 14:25: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 OAA12451 for ; Tue, 31 Aug 2004 14:25:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VHvIFT048915; Tue, 31 Aug 2004 10:57: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 i7VHvIRB048914; Tue, 31 Aug 2004 10:57:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VHvG8K048905 for ; Tue, 31 Aug 2004 10:57:17 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2Cse-0007EQ-Cq for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 13:57:18 -0400 Message-ID: <4134BBF0.6060604@solidmatrix.com> Date: Tue, 31 Aug 2004 13:57:04 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "IETF MXCOMP (E-mail)" Subject: DEPLOY: Prior Art for PRA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The following is the PRA algorithm from the current draft: ------------------------------------------------------------------------- 1. Locate the first non-empty Resent-Sender header in the message. If no such header is found, continue with step 2. If it is preceded by a non-empty Resent-From header and one or more Received or Return-Path headers occur after said Resent-From header and before the Resent-Sender header, continue with step 2. Otherwise, proceed to step 5. 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. 3. Locate all the non-empty Sender headers in the message. If there are no such headers, continue with step 4. If there is exactly one such header, proceed to step 5. If there is more than one such header, proceed to step 6. 4. Locate all the non-empty From headers in the message. If there is exactly one such header, continue with step 5. Otherwise, proceed to step 6. 5. A previous step has selected a single header from the message. If that header is malformed (e.g. it appears to contain multiple mailboxes, or the single mailbox is hopelessly malformed, or the single mailbox does not contain a domain name), continue with step 6. Otherwise, return that single mailbox as the Purported Responsible Address. 6. The message is ill-formed, and it is impossible to determine a Purported Responsible Address. ------------------------------------------------------------------------- The algorithm looks at the following headers in order: 1. First non-empty Resent-Sender. 2. First non-empty Resent-From. 3. Sender. 4. From. The PRA draft states that: "Note that steps 1 and 2 above extract the Resent-Sender or Resent- From header from the first resent block (as defined by section 3.6.6 of [RFC2822]) if any. Steps 3 and 4 above extract the Sender or From header if there are no resent blocks." RFC 2822 is clear that (section 3.6.6): "Each of the resent fields corresponds to a particular field elsewhere in the syntax." Therefore, Resent-Sender and Resent-From correspond to "Sender" and "From" headers. Precendence of "Sender" over "From" and by extension of "Resent-Sender" over "Resent-From" is clear from section 3.6.2 of RFC 2822: "The originator fields of a message consist of the from field, the sender field (when applicable)" and "The originator fields indicate the mailbox(es) of the source of the message. The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. " As we all know, all RFCs are under intellectual property of the IETF and held by ISOC. More prior art, for example documentation for fetchmail written by ESR states as follows (http://catb.org/~esr/fetchmail/fetchmail-man.html): -------------------------------------------------------------------------- INTERACTION WITH RFC 822 When trying to determine the originating address of a message, fetchmail looks through headers in the following order: Return-Path: Resent-Sender: (ignored if it doesn’t contain an @ or !) Sender: (ignored if it doesn’t contain an @ or !) Resent-From: From: Reply-To: Apparently-From -------------------------------------------------------------------------- The only difference from PRA is the fact that Sender appears before Resent-From. RFC 3028 which defined SIEVE has the following (section 5.1): -------------------------------------------------------------------------- "5.1. Test address Syntax: address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE] The address test matches Internet addresses in structured headers that contain addresses. It returns true if any header contains any key in the specified part of the address, as modified by the comparator and the match keyword. .... Implementations MUST restrict the address test to headers that contain addresses, but MUST include at least From, To, Cc, Bcc, Sender, Resent-From, Resent-To, and SHOULD include any other header that utilizes an "address-list" structured header body. -------------------------------------------------------------------------- I didn't have the time, but we can check any of the implementations listed on http://www.cyrusoft.com/sieve/ to see the exact way they do it. I wound guess that they following a similar algorithm. SpamAssassin configuration file (http://spamassassin.apache.org/doc/Mail_SpamAssassin_Conf.html): -------------------------------------------------------------------------- WHITELIST AND BLACKLIST OPTIONS whitelist_from add@ress.com Used to specify addresses which send mail that is often tagged (incorrectly) as spam; it also helps if they are addresses of big companies with lots of lawyers. This way, if spammers impersonate them, they'll get into big trouble, so it doesn't provide a shortcut around SpamAssassin. If you want to whitelist your own domain, be aware that spammers will often impersonate the domain of the recipient. The recommended solution is to instead use whitelist_from_rcvd as explained below. ..... The headers checked for whitelist addresses are as follows: if Resent-From is set, use that; otherwise check all addresses taken from the following set of headers: Envelope-Sender Resent-Sender X-Envelope-From From In addition, the ``envelope sender'' data, taken from the SMTP envelope data where this is available, is looked up -------------------------------------------------------------------------- Qmail documentation (http://qmail.sg.feratech.com/qmail-manual-html/man5/qmail-header.html): -------------------------------------------------------------------------- SENDER ADDRESSES qmail-inject looks for sender address lists in the following fields: Sender, From, Reply-To, Return-Path, Return- Receipt-To, Errors-To, Resent-Sender, Resent-From, Resent- Reply-To. -------------------------------------------------------------------------- iPlanet documentation from Sun (http://docs.sun.com/source/816-6091-10/contents.htm): -------------------------------------------------------------------------- The email message's originator address is taken from one of the following five sources, shown in decreasing order of preference: 1. Resent-from: 4. Sender: 2. From: 5. Envelope From: 3. Resent-sender: -------------------------------------------------------------------------- Another piece of code (http://email.uoa.gr/projects/fromfilter/doc/fromfilter.html): -------------------------------------------------------------------------- For now, the only headers we are interested in are From and Sender or, if this message has been forwarded and the sender has retained the original headers, the Resent-From and Resent-Sender. -------------------------------------------------------------------------- Another example (http://h71000.www7.hp.com/wizard/wiz_7493.html): -------------------------------------------------------------------------- (The list of SMTP return addresses that are checked for and used by OpenVMS include the following (ordered) list of fields: Resent-Reply-To Resent-From Reply-To From Resent-Sender Sender Return-Path) -------------------------------------------------------------------------- The only differences are order of fields and some semantics. I am sure there are more examples. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 14:26: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 OAA12508 for ; Tue, 31 Aug 2004 14:26:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VI0twi050131; Tue, 31 Aug 2004 11:00:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VI0tvJ050130; Tue, 31 Aug 2004 11:00:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VI0sMO050122 for ; Tue, 31 Aug 2004 11:00:54 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2Cw7-0007Q9-Iq for ietf-mxcomp@imc.org; Tue, 31 Aug 2004 14:00:55 -0400 Message-ID: <4134BCC6.7040601@solidmatrix.com> Date: Tue, 31 Aug 2004 14:00:38 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Sendmail releases open source Sender ID milter for testing References: <41341DD0.7010008@sendmail.com> <413498DF.9090008@solidmatrix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > In <413498DF.9090008@solidmatrix.com> Yakov Shafranovich writes: > > >>wayne wrote: >> >> >>>Actually, the download is hosted on sourceforge. Have you made sure >>>that sourceforge is aware that all of there dozens of mirror sites >>>will have to sign a license in order to distribute this code? >> >>The patent license only affects implementors, the code can be freely >>distributed. > > > > Really? > >>From the SenderID licenses: > > 2.2 _Source_Code_Distribution_ You also have [...] a > perpetual, non-exclusive, royalty-free, nontransferable, > non-sublicenseable, personal, worldwide license to distribute or > otherwise disclose source code copies of such Licensed > Implementation licensed in Section 2.1 only if You [...] > > 'This source code may incorporate intellectual property owned by > Microsoft Corporation that is necessary to implement the IETF > Sender ID Specification. [...] Our provision of this source code > does not include any licenses or any other rights to you under any > Microsoft intellectual property. If you would like a license from > Microsoft (e.g. rebrand, redistribute), you need to contact > Microsoft directly.' > > This seems pretty clear, if you want to rebrand or redistribute the > source code, you need to contact MS and get a license. Sourceforge is > *not* the implementor, Sendmail is. Souceforge is just redistributing > the source code. > My reading of this is that if you include the notice in your source, you are free to distribute it, although people who want to change it might need to get a new license. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 14:52: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 OAA15561 for ; Tue, 31 Aug 2004 14:52:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VISEZg054471; Tue, 31 Aug 2004 11:28: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 i7VISEV5054470; Tue, 31 Aug 2004 11:28:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7VISCBp054455 for ; Tue, 31 Aug 2004 11:28:13 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id C96721A6BD; Tue, 31 Aug 2004 20:28:09 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 7897D1A6B7 for ; Tue, 31 Aug 2004 20:28:07 +0200 (CEST) Message-Id: <9ORm2vUiLl7/hP3TlHeBAw.md5@prosecco.oryx.com> Date: Tue, 31 Aug 2004 20:27:58 +0200 From: Arnt Gulbrandsen To: IETF MARID WG Subject: Re: Sendmail releases open source Sender ID milter for testing References: <41341DD0.7010008@sendmail.com> <413498DF.9090008@solidmatrix.com> <4134BCC6.7040601@solidmatrix.com> In-Reply-To: <4134BCC6.7040601@solidmatrix.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov Shafranovich wrote: > wayne wrote: >> Our provision of this source code does not include any licenses >> or any other rights to you under any Microsoft intellectual >> property. If you would like a license from Microsoft (e.g. >> rebrand, redistribute), you need to contact Microsoft directly.' > > My reading of this is that if you include the notice in your source, > you are free to distribute it, although people who want to change it > might need to get a new license. Right. And people who want to redistribute it, too. The first sentence quoted above says that the "you" (the party who wishes to redistribute) does not receive a SenderID license from "us" (the party who has one). The second says that to redistribute, "you" must contact Microsoft. So even if Sendmail has a license, that doesn't grant Sourceforge a right to redistribute. Maybe I'm wrong. If I am, I think it's an understandable error and clarifications are urgently needed. Arnt From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 14:55: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 OAA15808 for ; Tue, 31 Aug 2004 14:55: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 i7VISknV054584; Tue, 31 Aug 2004 11:28:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VISjiW054583; Tue, 31 Aug 2004 11:28:45 -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 i7VISjns054577 for ; Tue, 31 Aug 2004 11:28:45 -0700 (PDT) (envelope-from csg@habeas.com) Received: from [10.4.1.84] ([10.4.1.84]) by exchange2003.ad.skymv.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 11:27:01 -0700 Message-ID: <4134C357.1030604@habeas.com> Date: Tue, 31 Aug 2004 11:28:39 -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: Re: TECH-OMISSION: Security vulnerability - Malicious DSN attacks References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2004 18:27:01.0750 (UTC) FILETIME=[1BC5F960:01C48F88] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daryl Odnert wrote: > To put it in simple terms, you cannot launch this type of attack > against V using P using unless one of the following is true: > > (1) P is an open relay. > > (2) The attack messages are sent to P from an IP address that > normally sends mail for domain V. > > (3) IP address spoofing is used to make it look like the attack > message is coming from an IP address that normally sends mail for > domain V. > (4) The attack messages are sent to P from an IP address that P considers to be part of its own management domain, and it puts no restrictions on either the MailFrom or the From header field from such IP addresses. I believe (4) applies to the overwhelming majority of ISP's submission hosts, including all three ISPs that I use regularly, and every hotel, airport, and public WiFi I've used in the past year. From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 14:56: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 OAA15902 for ; Tue, 31 Aug 2004 14:56: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 i7VIRM3e054336; Tue, 31 Aug 2004 11:27:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VIRMOq054335; Tue, 31 Aug 2004 11:27:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VIRLCM054321 for ; Tue, 31 Aug 2004 11:27:21 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) Date: Tue, 31 Aug 2004 13:27:20 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEB451@cliff.bai.org> Thread-Topic: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) thread-index: AcSPhSMMRJT/aMAST/26QIKrxBpIUAAANibA From: "Ryan Malayter" To: "Anne P. Mitchell, Esq." , "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VIRLCM054330 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [Anne P. Mitchell, Esq.] >the guys at the USPTO can't know everything, and it is >not their job to know everything It seems to me it *IS* the job of a patent examiner to know everything in their assigned subject area, or at least to know enough about a subject to be able to research patent claims quickly and accurately. This is how the system is supposed to work. The problem, of course, is one of economics: the USPTO cannot pay subject matter experts the required market rates to be examiners, so the patent examiners we have are probably not truly subject matter experts. To be effective (especially when dealing with a subject as broad as software patents), the USPTO needs true experts as examiners. This will cost a lot more money than the USPTO gets now. So to fix the system, the cost of patent applications should go up dramatically. Which means only moneyed persons or corporations will be able to get patents. It's a no-win situation for inventors, unless the USPTO can get it's federal funding drastically increased. But the moneyed people and corporations control all the congressional lobbyists, so it's budget will never be drastically increased. To be fair, Microsoft probably would have paid a lot to have a thorough and accurate examination before the Eloas patent was granted. But you can't have the corporations requesting and contesting patents funding the examination process. -Ryan- From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 14:59: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 OAA16045 for ; Tue, 31 Aug 2004 14:59: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 i7VISeOP054559; Tue, 31 Aug 2004 11:28: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 i7VISecf054558; Tue, 31 Aug 2004 11:28:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VISdnB054550 for ; Tue, 31 Aug 2004 11:28:39 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i7VIbpLf008441; Tue, 31 Aug 2004 14:37:51 -0400 From: To: "'Yakov Shafranovich'" , "'Paul Iadonisi'" Cc: "'IETF MARID WG'" Subject: RE: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID supportin Courier) Date: Tue, 31 Aug 2004 14:26:37 -0400 Message-ID: <029201c48f88$0d3c5b00$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-reply-to: <4134BC33.9050400@solidmatrix.com> Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit But by the time the email gets to the MUA its TOO LATE. Client machines cannot do an SMTP reject. But SPF classic requires *zero* changes to the MUA, its just the MTA that is enhanced. This is especially true if one of the goals is to preserve MTA to MUA bandwidth nad/or clutter of bad emails at MUA. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Yakov Shafranovich > Sent: Tuesday, August 31, 2004 1:58 PM > To: Paul Iadonisi > Cc: IETF MARID WG > Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID > supportin Courier) > > > > Paul Iadonisi wrote: > > > On Tue, 2004-08-31 at 12:22, Markus Stumpf wrote: > > > >>On Tue, Aug 31, 2004 at 10:26:18AM -0500, wayne wrote: > >> > >>>While those are the claimed reasons, I think it is quite clear from > >>>talking to quite a few people involved with this working group that > >>>the REAL reason is: > >>>* People want MS on board because it would *really* help deployment > >>> and MS *really* wants their PRA algorithm. > >> > >>Why will that help deployment? > >>The latest surveys state that MS SMTP servers have less than 10% > >>market share. > >>I'd say having sendmail + qmail + postfix + exim will help more than > >>having MS on board for whatever solution. > > > > > > I made this point a while ago on the spf-discuss list. > While it would > > be nice to have Microsoft on board, they do *not* have the > lion's share > > of the installed base of internet facing SMTP servers. That's where > > most of implementation of these standards will take place. > > I would be quite disappointing if this draft was pushed > through with > > the current patent license because someone thought 'we need > Microsoft'. > > Even if we did, shunning this license does not have to mean pushing > > Microsoft out, so to me, it would make no sense to push this through > > just because someone thinks we need Microsoft. > > > > We had this argument in the ASRG as well until some pointed > out that the > PRA algorithm works in MUA. The market share on Microsoft > MUAs is over 70%. > > Yakov > From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 15: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 PAA16120 for ; Tue, 31 Aug 2004 15:00: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 i7VIXLo8055528; Tue, 31 Aug 2004 11: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 i7VIXL5W055527; Tue, 31 Aug 2004 11:33:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VIXK0H055521 for ; Tue, 31 Aug 2004 11:33:20 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2DRY-00011u-SX; Tue, 31 Aug 2004 14:33:22 -0400 Message-ID: <4134C45E.5070207@solidmatrix.com> Date: Tue, 31 Aug 2004 14:33:02 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: terry@ashtonwoodshomes.com CC: "'Paul Iadonisi'" , "'IETF MARID WG'" Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID supportin Courier) References: <029201c48f88$0d3c5b00$2766f30a@development.greatgulfhomes.com> In-Reply-To: <029201c48f88$0d3c5b00$2766f30a@development.greatgulfhomes.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Note the list arguments about silently swallowing emails and then think why these arguments are relevant (hint: swallowing email on MUA level). It is clear to me from the entire Sender-ID development from its roots in the ASRG, as well as the information I heard directly from Microsoft employees on the subject, is that the Sender-ID standard is intended to be deployed on the MUA level by Microsoft. Of course, they are free to correct me. Yakov terry@ashtonwoodshomes.com wrote: > But by the time the email gets to the MUA its TOO LATE. Client machines cannot do an SMTP reject. > > But SPF classic requires *zero* changes to the MUA, its just the MTA that is enhanced. > > This is especially true if one of the goals is to preserve MTA to MUA bandwidth nad/or clutter of > bad emails at MUA. > > Terry Fielder > Manager Software Development and Deployment > Great Gulf Homes / Ashton Woods Homes > terry@greatgulfhomes.com > Fax: (416) 441-9085 > > > >>-----Original Message----- >>From: owner-ietf-mxcomp@mail.imc.org >>[mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Yakov Shafranovich >>Sent: Tuesday, August 31, 2004 1:58 PM >>To: Paul Iadonisi >>Cc: IETF MARID WG >>Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID >>supportin Courier) >> >> >> >>Paul Iadonisi wrote: >> >> >>>On Tue, 2004-08-31 at 12:22, Markus Stumpf wrote: >>> >>> >>>>On Tue, Aug 31, 2004 at 10:26:18AM -0500, wayne wrote: >>>> >>>> >>>>>While those are the claimed reasons, I think it is quite clear from >>>>>talking to quite a few people involved with this working group that >>>>>the REAL reason is: >>>>>* People want MS on board because it would *really* help deployment >>>>> and MS *really* wants their PRA algorithm. >>>> >>>>Why will that help deployment? >>>>The latest surveys state that MS SMTP servers have less than 10% >>>>market share. >>>>I'd say having sendmail + qmail + postfix + exim will help more than >>>>having MS on board for whatever solution. >>> >>> >>> I made this point a while ago on the spf-discuss list. >> >>While it would >> >>>be nice to have Microsoft on board, they do *not* have the >> >>lion's share >> >>>of the installed base of internet facing SMTP servers. That's where >>>most of implementation of these standards will take place. >>> I would be quite disappointing if this draft was pushed >> >>through with >> >>>the current patent license because someone thought 'we need >> >>Microsoft'. >> >>>Even if we did, shunning this license does not have to mean pushing >>>Microsoft out, so to me, it would make no sense to push this through >>>just because someone thinks we need Microsoft. >>> >> >>We had this argument in the ASRG as well until some pointed >>out that the >>PRA algorithm works in MUA. The market share on Microsoft >>MUAs is over 70%. >> >>Yakov >> > > > > > From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 15:01:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16180 for ; Tue, 31 Aug 2004 15:01: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 i7VIYnj7055759; Tue, 31 Aug 2004 11:34:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VIYnu4055758; Tue, 31 Aug 2004 11:34:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.bai.org (smtp.bai.org [65.116.201.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VIYmVS055730 for ; Tue, 31 Aug 2004 11:34:48 -0700 (PDT) (envelope-from rmalayter@bai.org) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Sendmail releases open source Sender ID milter for testing Date: Tue, 31 Aug 2004 13:34:47 -0500 Message-ID: <792DE28E91F6EA42B4663AE761C41C2A02CEB457@cliff.bai.org> Thread-Topic: Sendmail releases open source Sender ID milter for testing thread-index: AcSPd3ZBcyL/VutHR52ORIfN8//fQwAETisg From: "Ryan Malayter" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VIYmVS055753 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [wayne] >This seems pretty clear, if you want to rebrand >or redistribute the source code, you need to >contact MS and get a license. Sourceforge is >*not* the implementor, Sendmail is. Souceforge >is just redistributing the source code. I personally don't think Sourceforge is a distributor in this case. They are merely a courier, like FedEx. If I FedEx a CD containing a SenderID implementation to my buddy across town, does FedEx have to sign the MS license? Obviously not. IANAL, of course, so I ask the lawyers out there: is there a strict legal definition of a "(re)distributor" of software? -ryan- From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 15:08:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17125 for ; Tue, 31 Aug 2004 15:08:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VIfLvw057149; Tue, 31 Aug 2004 11:41: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 i7VIfKP5057148; Tue, 31 Aug 2004 11:41:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VIfK4j057142 for ; Tue, 31 Aug 2004 11:41:20 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2DZI-0001UF-OJ; Tue, 31 Aug 2004 14:41:22 -0400 Message-ID: <4134C644.2010802@solidmatrix.com> Date: Tue, 31 Aug 2004 14:41:08 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Anne P. Mitchell, Esq." CC: IETF MARID WG Subject: Re: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) References: <2D922BA4-FB78-11D8-BA2B-000A95AC5778@isipp.com> In-Reply-To: <2D922BA4-FB78-11D8-BA2B-000A95AC5778@isipp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne P. Mitchell, Esq. wrote: > > >> IMHO, in light of the possible prior art, it may be very probably that >> the potential patent application is invalid or will not approved. >> Therefore, it might be feasible to ignore the IPR claim all together and >> preceed with approval of Sender-ID. > > > Oh dear. > > Never, *ever* make the mistake of thinking that a patent application > will not be approved because of prior art. > > You'd be stunned at the things which are granted patents where the prior > art seems *so* obvious to anyone who knows (and that is a key - the guys > at the USPTO can't know everything, and it is not their job to know > everything). > > Right now the MO at the USPTO seems to be "approve everything, and let > them sort it out in the courts". > Thanks for the correction. Ah, the wonders of our legal system. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 15:17: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 PAA18353 for ; Tue, 31 Aug 2004 15:17: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 i7VItQRk060057; Tue, 31 Aug 2004 11:55: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 i7VItPUp060056; Tue, 31 Aug 2004 11: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 i7VItP8X060039 for ; Tue, 31 Aug 2004 11:55:25 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7VItM57008739; Tue, 31 Aug 2004 11:55:23 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7VItK1I000693; Tue, 31 Aug 2004 11:55:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <2D922BA4-FB78-11D8-BA2B-000A95AC5778@isipp.com> References: <2D922BA4-FB78-11D8-BA2B-000A95AC5778@isipp.com> Date: Tue, 31 Aug 2004 11:55:19 -0700 To: "Anne P. Mitchell, Esq." , IETF MARID WG From: Ted Hardie Subject: Re: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Please note that this advice is contrary to the advice given in RFC 3669. An evaluation of prior art may be considered in the IETF process; it should be part of a much broader range of considerations (and I urge folks who have not read RFC 3669 lately to read it again), but such evaluations _do_ have their place. Many folks are stunned by the actions of their governments, and that prior behavior may be taken into account. But assuming a result without analysis is a poor response to a working group's responsibility to determine how to proceed in the light of IPR claims and offered licenses. regards, Ted Hardie At 11:04 AM -0700 8/31/04, Anne P. Mitchell, Esq. wrote: >>IMHO, in light of the possible prior art, it may be very probably that >>the potential patent application is invalid or will not approved. >>Therefore, it might be feasible to ignore the IPR claim all together and >>preceed with approval of Sender-ID. > >Oh dear. > >Never, *ever* make the mistake of thinking that a patent application >will not be approved because of prior art. > >You'd be stunned at the things which are granted patents where the >prior art seems *so* obvious to anyone who knows (and that is a key >- the guys at the USPTO can't know everything, and it is not their >job to know everything). > >Right now the MO at the USPTO seems to be "approve everything, and >let them sort it out in the courts". > > >Anne From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 15:22: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 PAA19076 for ; Tue, 31 Aug 2004 15:22: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 i7VIxtax060676; Tue, 31 Aug 2004 11:59:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VIxtaP060675; Tue, 31 Aug 2004 11:59:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VIxsZF060668 for ; Tue, 31 Aug 2004 11:59:55 -0700 (PDT) (envelope-from mazieres@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so190424rnl for ; Tue, 31 Aug 2004 11:59:52 -0700 (PDT) Received: by 10.38.73.36 with SMTP id v36mr1707267rna; Tue, 31 Aug 2004 11:59:52 -0700 (PDT) Received: by 10.38.164.56 with HTTP; Tue, 31 Aug 2004 11:59:52 -0700 (PDT) Message-ID: <94df60cf040831115919056323@mail.gmail.com> Date: Tue, 31 Aug 2004 14:59:52 -0400 From: Reply-To: To: Mark Shewmaker Subject: Re: Re: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages Cc: MARID In-Reply-To: <1093945156.2379.9503.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <81AC085044D04B429F5FB883D94FA1AF8FAFDF@df-fido-msg.exchange.corp.microsoft.com> <1093650303.3782.3839.camel@localhost.localdomain> <72A8ABAC-F95A-11D8-881C-000A95B3BA44@hxr.us> <1093906313.3463.8385.camel@localhost.localdomain> <94df60cf0408301735444d4a45@mail.gmail.com> <1093923481.3782.8749.camel@localhost.localdomain> <94df60cf040830214924086f53@mail.gmail.com> <1093945156.2379.9503.camel@localhost.localdomain> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A few more detailed comments: > This vulnerability exists if local policy settings allow for a situation > in which all of the following are true: > > - A message is sent to multiple recipients, > > - The recipients have differing local policy settings > with respect to message body requirements, > > - An ultimate determination of per-recipient nondeliverability > cannot be communicated within the SMTP session after the receipt > of message data, and > > - The Return Path is forged, Okay, better. I still think it could be clearer because of the dependence between some of these things. Also, that the message has multiple recipients is less important than emphasizing that the *transaction* has multiple recipients. How about saying: 1. The Return Path is forged. 2. Per-recipient non-deliverability status cannot be communicated to the client during the SMTP transaction because A. The transaction has multiple recipients, B. The recipients have differing local policy settings, some allowing and some rejecting delivery of the message, and C. The policies are based on message headers or contents transmitted to the server during the SMTP DATA command, and the SMTP protocol only allows a single success or failure code for all recipients in response to the DATA command. 3. Local policy requires the sending of a DSN for rejected recipients of successful SMTP transactions. > An attacker can take advantage of this vulnerability by using any > machine with detectably differing local policy settings as an apparent > source of the attacker's forged DSNs. > > Not only does this mean the ultimate victims will receive forged DSNs, > but the machine the attacker used to accomplish the forgery may become > known as a source of forged DSNs. The term "forged DSN" may be misleading here, because the DSNs themselves are in a sense genuine, just the message for which they are generated are forged. So maybe substitute "maliciously-induced DSN" for "forged DSN." > An MTA can completely avoid becoming a participant in this type of DSN > attack by preventing any of the above listed requirements from > occuring. That is, it could do any of the following: > > - Disallow some message recipients. > - Disallow local policy settings which depend on message contents. > - Disable sending of DSNs. Instead of "Disallow some message recipients", how about: - Disallow combinations of recipients with different local policies in the same SMTP transaction > Each option has downsides. The first option would require addition addition -> additional > message transmission attempts, the second option would limit desirable > functionality, and the third would hide email to become less reliable by > hiding legitimate email problems. How about: "and the third could make email less reliable by hiding legitimate problems, and would in any case violate section 4.2.5 of RFC 2821." (done with appropriate citation) > However, the first option is the only one which does not actually limit > mail system functionality, making it the only real option to consider. > > To expand upon the first option, an MTA can completely avoid becoming a > participant in this type of DSN attack in all cases by: > > Whenever all of the following is true: > > - An incoming message is addressed to multiple participants. > > - Those participants have local policy settings that, > given the context of the specifics of the MTA transaction > mean that per-recipient final determinations of nondeliverability > cannot be communicated until after the message has been accepted > for delivery. > > - The MTA has not positively validated the MAIL FROM address to > its satisfaction, > > Then: > > - The MTA should give temporary rejections at "RCPT TO:" time > to all recipients with differing message-body-related local policy > settings and where the recipients have not already been temporarily > or permanently rejected for other reasons, thus accepting only a > compatible subset of recipients and avoiding the need to create > DSNs at all. > > It is suggested that the MTA reject these recipients with a > return code of 4.7.6. > > (Note that the MTA is not rejecting on the basis of too many > recipients, rather it is rejecting on the basis of a > security-related incompatibility in the requested recipient list.) My only potential quibble here is that it might be clearer to describe this from the point of view of the MTA receiving the message. For example, the fact that the message is addressed to multiple recipients isn't exactly the concern, because the messages might be in separate transactions. (For example, I think qmail always uses a separate transaction for each recipient.) Something along the lines of: A server has already accepted one RCPT TO: command in the current transaction. The server receives a subsequent RCPT TO: command. The mailbox in the second RCPT command has a different policy from the mailbox in the first command, and at least one of the policies cannot be resolved until the server has received the message contents with the DATA command. > For instance, I was imagining a situation in which one machine is > temporarily set up for a day or so to send semi-secure eft > notifications, after which it is wiped of all the secure-ish info > necessary for the bulk sending, (or the capability to access the > secure-ish info), and then set up for another bulk sending session of > another customer, with the bulk sender or bank or what-have-you making a > big deal about secure wipes or deletions. > > And then if you don't need as much secure info to handle bounce > processing, the bounce-handling machine might be another machine > entirely, and thus might be allowed the necessary access longer. > > So you might have: > > Mail-From: mybank-bounce-1234@bounces.bulksender.mybank.com > From: eft-notification@bulksender.mybank.com > > So if you're the big bank in question, and you want to prove to federal > regulators that you're performing your due diligence for the regs, even > though technically clued in people will understand that having separate > bounce-handling machines isn't necessary and is quite possibly > counterproductive, (and causing you to be more likely to make mistakes), > I'm guessing that big bank folks would like to be able to jump up and > down, point at a machine that's dedicated to only receiving bounce > messages, has been doing that exclusively for xxx amount of time, etc., > "prove" it by talking about bounce addresses, and thus completely > (hopefully) avoid any question about their behavior in that respect. But this seems entirely compatible with the MAIL-FROM scenario I proposed. If you have: sender.bank.com IN MX 10 bounces.sender.com sender.bank.com IN TXT "v=spf1 redirect=spf.sender.com" And you send out mail: Mail-From: notification-1234@sender.bank.com From: eft-notifications@sender.bank.com Nothing says that the mail has to come from bounces.sender.com. sender.com can put whatever they want in spf.sender.com, and bounces.sender.com should map to the IP address (or addresses) of machines doing bounce processing. > It's not really logical, and I admit I'm stretching things, but my guess > is that that's the sort of reason people want that sort of difference. But I still don't get it. I understand that people might want to do what you are describing. What I don't understand is why PRA-based authentication is more amenable to the task than MAIL-FROM authentication. > In any event, the fact that such requirements are so unusual, in the > only situations I could think of, put me squarely in the "keep spf1 > semantics, no spf2 strings" camp. Well, then maybe I'm asking the wrong person. But at this point I'm thinking there must be something big I'm missing (or else it was unfortunate to move from SPF to Sender ID). On the other hand, since the big advantage of SPF over Sender ID is virus (and joe job) prevention, and since Microsoft is both one of the big proponents of PRA and one of the biggest targets of virus writers, I'm thinking there's probably a pretty good reason for wanting Sender ID over SPF-classic. I'd just like to understand that reason myself... David From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 15:40: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 PAA20705 for ; Tue, 31 Aug 2004 15:40: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 i7VJJ7V9063933; Tue, 31 Aug 2004 12:19: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 i7VJJ77D063932; Tue, 31 Aug 2004 12:19:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VJJ65i063864 for ; Tue, 31 Aug 2004 12:19:07 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7VJIuNT016171 for ; Tue, 31 Aug 2004 20:18:56 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7VJIuWo016170; Tue, 31 Aug 2004 20:18:56 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Unencumbered Checking References: <029201c48f88$0d3c5b00$2766f30a@development.greatgulfhomes.com> <4134C45E.5070207@solidmatrix.com> From: Graham Murray Date: Tue, 31 Aug 2004 20:18:56 +0100 In-Reply-To: <4134C45E.5070207@solidmatrix.com> (Yakov Shafranovich's message of "Tue, 31 Aug 2004 14:33:02 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov Shafranovich writes: > It is clear to me from the entire Sender-ID development from its roots > in the ASRG, as well as the information I heard directly from Microsoft > employees on the subject, is that the Sender-ID standard is intended to > be deployed on the MUA level by Microsoft. Of course, they are free to > correct me. But should that concern us in this working group? Should we not be investigating and recommending the best solution for implementing in the MTA (as per the name and charter of this group)? We should be concerned about what may or may not be done or implemented in MUAs. From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 15:49: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 PAA21767 for ; Tue, 31 Aug 2004 15:49: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 i7VJShMj066106; Tue, 31 Aug 2004 12:28: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 i7VJShad066105; Tue, 31 Aug 2004 12:28:43 -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 i7VJSgQ3066093 for ; Tue, 31 Aug 2004 12:28:43 -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 i7VJSkpA006931 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 31 Aug 2004 12:28:47 -0700 Message-ID: <097901c48f90$c4a22600$3201a8c0@rasta> From: "Harold A'Hole" To: "IETF MARID WG" References: <792DE28E91F6EA42B4663AE761C41C2A02CEB457@cliff.bai.org> Subject: Re: Sendmail releases open source Sender ID milter for testing Date: Tue, 31 Aug 2004 12:29:00 -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 > I personally don't think Sourceforge is a distributor in this case. They > are merely a courier, like FedEx. If I FedEx a CD containing a SenderID > implementation to my buddy across town, does FedEx have to sign the MS > license? Obviously not. Bad analogy. Sourceforge itself may be a carrier, but whoever runs the project is the distributor. And since they are distributing to untold numbers of folks without any permission required, it is much more broad than FedEx and its very targeted distribution to the addressee as specified by the paying party. Besides, with all of the napster effect, sourceforge would most certainly be considered a distributor. They cannot create a system that makes it easy to share such IP and then claim they have no responsibility since the entire purpose is to distribute whatever is posted there. But in the end, why sign a license for IP that MSFT cannot prove it owns. It's just an unfounded claim right now unsupported by law. They must own the patent first. Harry From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 15:59: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 PAA23092 for ; Tue, 31 Aug 2004 15:59: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 i7VJXJWv067225; Tue, 31 Aug 2004 12:33: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 i7VJXJDo067223; Tue, 31 Aug 2004 12:33:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VJXI1A067210 for ; Tue, 31 Aug 2004 12:33:18 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2ENZ-0004IW-BO; Tue, 31 Aug 2004 15:33:18 -0400 Message-ID: <4134D26D.4030607@solidmatrix.com> Date: Tue, 31 Aug 2004 15:33:01 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Ted Hardie CC: "Anne P. Mitchell, Esq." , IETF MARID WG Subject: Re: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) References: <2D922BA4-FB78-11D8-BA2B-000A95AC5778@isipp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ted, What about the actual list of possible prior art that I provided in the original message? My reading of RFC 3669 seems to indicate that its beneficial: " o Possibilities of prior art should be considered. o It's all right, and sometimes beneficial, to discuss IPR claims and gather information about possible prior art on the group list. " Yakov Ted Hardie wrote: > > Please note that this advice is contrary to the advice given > in RFC 3669. An evaluation of prior art may be considered > in the IETF process; it should be part of a much broader > range of considerations (and I urge folks who have not > read RFC 3669 lately to read it again), but such evaluations > _do_ have their place. > > Many folks are stunned by the actions of their governments, > and that prior behavior may be taken into account. But > assuming a result without analysis is a poor response to > a working group's responsibility to determine how to > proceed in the light of IPR claims and offered licenses. > > regards, > Ted Hardie > > > > At 11:04 AM -0700 8/31/04, Anne P. Mitchell, Esq. wrote: > >>> IMHO, in light of the possible prior art, it may be very probably that >>> the potential patent application is invalid or will not approved. >>> Therefore, it might be feasible to ignore the IPR claim all together >>> and >>> preceed with approval of Sender-ID. >> >> >> Oh dear. >> >> Never, *ever* make the mistake of thinking that a patent application >> will not be approved because of prior art. >> >> You'd be stunned at the things which are granted patents where the >> prior art seems *so* obvious to anyone who knows (and that is a key - >> the guys at the USPTO can't know everything, and it is not their job >> to know everything). >> >> Right now the MO at the USPTO seems to be "approve everything, and let >> them sort it out in the courts". >> >> >> Anne > > > > > From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 16:00: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 QAA23204 for ; Tue, 31 Aug 2004 16:00: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 i7VJanF9067998; Tue, 31 Aug 2004 12:36:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VJanrS067996; Tue, 31 Aug 2004 12:36:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VJamPf067974 for ; Tue, 31 Aug 2004 12:36:48 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7VJalja016345 for ; Tue, 31 Aug 2004 20:36:47 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7VJal54016344; Tue, 31 Aug 2004 20:36:47 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Sendmail releases open source Sender ID milter for testing References: <792DE28E91F6EA42B4663AE761C41C2A02CEB457@cliff.bai.org> From: Graham Murray Date: Tue, 31 Aug 2004 20:36:47 +0100 In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB457@cliff.bai.org> (Ryan Malayter's message of "Tue, 31 Aug 2004 13:34:47 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Ryan Malayter" writes: > I personally don't think Sourceforge is a distributor in this case. They > are merely a courier, like FedEx. If I FedEx a CD containing a SenderID > implementation to my buddy across town, does FedEx have to sign the MS > license? Obviously not. I do not think the situation is the same. This would be more like providing a master CD to FedEx and them duplicating it every time a customer orders one. FedEx collect and deliver each individual CD, but Sourceforge create a new copy every time someone performs a download. From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 16:06: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 QAA24731 for ; Tue, 31 Aug 2004 16:06:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VJdSfJ068541; Tue, 31 Aug 2004 12:39:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VJdSJR068540; Tue, 31 Aug 2004 12:39:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miranda.server-plant.co.uk (miranda.server-plant.co.uk [193.110.88.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VJdQO1068510 for ; Tue, 31 Aug 2004 12:39:27 -0700 (PDT) (envelope-from johnp@idimo.com) Received: from idimo2 ([62.87.75.145]) (authenticated) by miranda.server-plant.co.uk (8.11.6/8.11.2) with ESMTP id i7VJdBB13068; Tue, 31 Aug 2004 20:39:12 +0100 Message-ID: <006101c48f92$30ee5760$914b573e@idimo2> From: "jpinkerton" To: "Anne P. Mitchell, Esq." Cc: References: <2D922BA4-FB78-11D8-BA2B-000A95AC5778@isipp.com> Subject: Re: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) Date: Tue, 31 Aug 2004 21:35:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit As a matter of urgency - could we please have the details of how to contact the United States Patent Office regarding patent applications. It would be *most* useful if the people on this list who know of prior art and obviousness "proofs" could get in touch with that office immediately the patent application is lodged. Slainte, JohnP. johnp@idimo.com ICQ 313355492 ----- Original Message ----- From: "Anne P. Mitchell, Esq." To: "IETF MARID WG" Sent: Tuesday, August 31, 2004 8:04 PM Subject: Re: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) > > > > IMHO, in light of the possible prior art, it may be very probably that > > the potential patent application is invalid or will not approved. > > Therefore, it might be feasible to ignore the IPR claim all together > > and > > preceed with approval of Sender-ID. > > Oh dear. > > Never, *ever* make the mistake of thinking that a patent application > will not be approved because of prior art. > > You'd be stunned at the things which are granted patents where the > prior art seems *so* obvious to anyone who knows (and that is a key - > the guys at the USPTO can't know everything, and it is not their job to > know everything). > > Right now the MO at the USPTO seems to be "approve everything, and let > them sort it out in the courts". > > > Anne From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 16:31: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 QAA29382 for ; Tue, 31 Aug 2004 16:31: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 i7VK1pmh073245; Tue, 31 Aug 2004 13:01: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 i7VK1paN073244; Tue, 31 Aug 2004 13:01:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gmdev.webwayone.co.uk (webway-one-04.hiway.co.uk [62.8.115.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VK1nh4073219 for ; Tue, 31 Aug 2004 13:01:50 -0700 (PDT) (envelope-from graham@webwayone.co.uk) Received: from gmdev.webwayone.co.uk (localhost [IPv6:::1]) by gmdev.webwayone.co.uk (8.13.1/8.13.1) with ESMTP id i7VK1mZ5016570 for ; Tue, 31 Aug 2004 21:01:48 +0100 Received: (from graham@localhost) by gmdev.webwayone.co.uk (8.13.1/8.13.1/Submit) id i7VK1mjF016569; Tue, 31 Aug 2004 21:01:48 +0100 X-Authentication-Warning: gmdev.webwayone.co.uk: graham set sender to graham@webwayone.co.uk using -f To: ietf-mxcomp@imc.org Subject: Re: Unencumbered Checking References: <029201c48f88$0d3c5b00$2766f30a@development.greatgulfhomes.com> <4134C45E.5070207@solidmatrix.com> From: Graham Murray Date: Tue, 31 Aug 2004 21:01:48 +0100 In-Reply-To: (Graham Murray's message of "Tue, 31 Aug 2004 20:18:56 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Graham Murray writes: > We should be concerned about what may or may not be done or > implemented in MUAs. Oooops That should say "We should not be concerned....." ^^^ From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 16: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 QAA02157 for ; Tue, 31 Aug 2004 16:58:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VKThC6078973; Tue, 31 Aug 2004 13: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 i7VKThWq078972; Tue, 31 Aug 2004 13:29:43 -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 i7VKTh7Z078942 for ; Tue, 31 Aug 2004 13:29:43 -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 EC9B240DB for ; Tue, 31 Aug 2004 13:29:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <6.1.0.6.2.20040828214646.02a823d0@localhost> References: <81AC085044D04B429F5FB883D94FA1AF8896D3@df-fido-msg.exchange.corp.microsoft.com> <6.1.0.6.2.20040828214646.02a823d0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7B94467B-FB8C-11D8-9ADB-000393A56BB6@glyphic.com> From: Mark Lentczner Subject: Re: TECH-ERROR: DNS Record Types Date: Tue, 31 Aug 2004 13:29:39 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VKTh7Z078966 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit First, two minor points: > ... as when SPF (I do not like the name SPF2) RR ... Several people have made this suggestion to me, on and off list. I have seen only one argument against. Unless I hear more, I will rename the RR type from 'SPF2' to 'SPF'. >> 2a.The contents of the SPF2 record and TXT record MUST be identical. > This I agree with and the current document says so (at least > that is my reading of section 2.1 paragraph 3). > But I agree with you that putting in a MUST there is a good idea. I will add the MUST. Then: On Aug 28, 2004, at 7:55 PM, Ólafur Guðmundsson wrote: > The fundamental difference between your position and mine is > you: want everyone to be compliant at all times. > me: Specify clearly fully compliant state and tolerate non compliance > during phase-in. I think this is a good summary of the two positions presented. I agree with Ólafur on this, since I think this document is a standard, not a how-to manual. The How-to's and web wizards will make it clear to people that they need to publish the TXT form for now. - Mark From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 17:01: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 RAA02367 for ; Tue, 31 Aug 2004 17:01: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 i7VKNq7M077953; Tue, 31 Aug 2004 13:23: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 i7VKNqhe077952; Tue, 31 Aug 2004 13:23:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VKNp8M077939 for ; Tue, 31 Aug 2004 13:23:52 -0700 (PDT) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7VK5oo3014384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 16:05:51 -0400 Date: Tue, 31 Aug 2004 16:23:53 -0400 From: Cyrus Daboo To: Yakov Shafranovich , "IETF MXCOMP (E-mail)" Subject: Re: DEPLOY: Prior Art for PRA Message-ID: <9C1B82A83447131BA7AE74FA@ninevah.cyrusoft.com> In-Reply-To: <4134BBF0.6060604@solidmatrix.com> References: <4134BBF0.6060604@solidmatrix.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Yakov, --On Tuesday, August 31, 2004 1:57 PM -0400 Yakov Shafranovich wrote: > > RFC 3028 which defined SIEVE has the following (section 5.1): > -------------------------------------------------------------------------- > "5.1. Test address > > Syntax: address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE] > > > The address test matches Internet addresses in structured headers > that contain addresses. It returns true if any header contains any > key in the specified part of the address, as modified by the > comparator and the match keyword. > .... > Implementations MUST restrict the address test to headers that > contain addresses, but MUST include at least From, To, Cc, Bcc, > Sender, Resent-From, Resent-To, and SHOULD include any other header > that utilizes an "address-list" structured header body. > -------------------------------------------------------------------------- > > I didn't have the time, but we can check any of the implementations > listed on http://www.cyrusoft.com/sieve/ to see the exact way they do it. > I wound guess that they following a similar algorithm. The SIEVE address test is not a PRA-type check that scans possible address headers in some well-defined order to extract a particular value. Instead it provides a way to test the content of specific address headers - no ordering is implied, and the author of the sieve script gets to say which headers are tested. So I don't think SIEVE can be used as an example of PRA prior art - sorry! -- Cyrus Daboo From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 17:18: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 RAA03678 for ; Tue, 31 Aug 2004 17:18: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 i7VKpbk2083480; Tue, 31 Aug 2004 13: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 i7VKpbH1083479; Tue, 31 Aug 2004 13:51:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VKpaPI083471 for ; Tue, 31 Aug 2004 13:51:36 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-076-260.area3.spcsdns.net ([68.245.40.189]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2FbO-0000kG-VA; Tue, 31 Aug 2004 16:51:40 -0400 Message-ID: <4134E4C9.5080608@solidmatrix.com> Date: Tue, 31 Aug 2004 16:51:21 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Graham Murray CC: ietf-mxcomp@imc.org Subject: Re: Unencumbered Checking References: <029201c48f88$0d3c5b00$2766f30a@development.greatgulfhomes.com> <4134C45E.5070207@solidmatrix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Murray wrote: > Graham Murray writes: > > >>We should be concerned about what may or may not be done or >>implemented in MUAs. > > > Oooops That should say "We should not be concerned....." > ^^^ There are many instances were the check will be done after the SMTP transaction. SpamAssassin is an obvious example. Plus, the MUA checking is what makes this valuable against phishing. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 17:23: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 RAA03990 for ; Tue, 31 Aug 2004 17:23: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 i7VKmPah082681; Tue, 31 Aug 2004 13:48: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 i7VKmP3Y082680; Tue, 31 Aug 2004 13:48:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7VKmOTo082666 for ; Tue, 31 Aug 2004 13:48:24 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 0E7531A6C5; Tue, 31 Aug 2004 22:48:28 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id DAC401A6B8 for ; Tue, 31 Aug 2004 22:48:25 +0200 (CEST) Message-Id: Date: Tue, 31 Aug 2004 22:48:18 +0200 From: Arnt Gulbrandsen To: Ryan Malayter Subject: Re: Sendmail releases open source Sender ID milter for testing Cc: IETF MARID WG References: <792DE28E91F6EA42B4663AE761C41C2A02CEB457@cliff.bai.org> In-Reply-To: <792DE28E91F6EA42B4663AE761C41C2A02CEB457@cliff.bai.org> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ryan Malayter writes: > I personally don't think Sourceforge is a distributor in this case. > They are merely a courier, like FedEx. If I FedEx a CD containing a > SenderID implementation to my buddy across town, does FedEx have to > sign the MS license? Obviously not. > > IANAL, of course, so I ask the lawyers out there: is there a strict > legal definition of a "(re)distributor" of software? If you think offering software downloads to the general public isn't redistributing, I dare you to put your Windows CDs on your web site. Arnt From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 17:25: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 RAA04155 for ; Tue, 31 Aug 2004 17:25: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 i7VKnNn6082943; Tue, 31 Aug 2004 13:49: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 i7VKnN4U082942; Tue, 31 Aug 2004 13:49:23 -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 i7VKnNuf082915 for ; Tue, 31 Aug 2004 13:49:23 -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 AF47C40DB for ; Tue, 31 Aug 2004 13:49:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <013901c48c01$4b7a03c0$6c62fea9@ibmrkydk2ufvdd> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3BE5237E-FB8F-11D8-9ADB-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) Date: Tue, 31 Aug 2004 13:49:21 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Re-reading this thread, looking for common ground, I see 1) There is near universal agreement that domains will still want to publish records about the 2821 Mail From identity. 2) There is still concern on where the TXT records should be published: Either at something like _pra._marid.example.com vs. at example.com itself. 3) It has been shown that even if records go into sub-domains, due to the way DNS wildcards work, records still need to be distinguishable based solely on their content, not their location. Therefore, I suggest that we adopt the scheme I labeled (3a): > 3a) Put scopes in the field > Proposed by Wayne in > http://www.imc.org/ietf-mxcomp/mail-archive/msg03441.html > This scheme replaces the "/pra" and field in the version > string with a list of scopes. For example: "spf2.0/pra,mailfrom" or > "spf2.0/mailfrom". It applies to the whole record, so it only helps > domains with very large records if their v=spf1 and spf2.0/pra records > are otherwise the same. If the above two large records were the same, > this would look like: > > example.com. IN TXT "spf2.0/pra,mailfrom ... some very > long record here ..." The only counter to this scheme (other than some preference for the others) was that it would require existing v=spf1 domains to re-publish. I don't beleive this would be the case:: All existing SPF implementations are likely to accept v=spf1 for quite some time, if not forever. And, because it is also likely that all existing SPF implementations would be rev'd quickly[1] to support spf2.0/mailfrom, then new sites can simply publish the new version. - Mark [1]: There aren't that many existing implementations, and everyone running one knows that they are running less than 1.0 code and generally is keeping an eye on updates. From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 17:38: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 RAA04928 for ; Tue, 31 Aug 2004 17: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 i7VLFQiE088723; Tue, 31 Aug 2004 14:15:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VLFQfE088722; Tue, 31 Aug 2004 14:15:26 -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 i7VLFOaI088701 for ; Tue, 31 Aug 2004 14:15:24 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 6178 invoked by uid 1013); 31 Aug 2004 21:15:28 -0000 Date: Tue, 31 Aug 2004 23:15:28 +0200 From: Markus Stumpf To: Graham Murray Cc: ietf-mxcomp@imc.org Subject: Re: Unencumbered Checking Message-ID: <20040831211528.GQ96404@Space.Net> References: <029201c48f88$0d3c5b00$2766f30a@development.greatgulfhomes.com> <4134C45E.5070207@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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, Aug 31, 2004 at 09:01:48PM +0100, Graham Murray wrote: > Oooops That should say "We should not be concerned....." I have raised this and I have also raised more than once concerns that there are zillions of MUAs in intranets and behind firewalls that cannot do DNS lookups themselfes. But I was told this is then a job for "special gateways" and "solution" would be to add headers for evaluation by the MUAs that would be removed for security reasons at the receiving MTA for incoming eMails. Funny thing is that http://weblog.infoworld.com/udell/2004/03/23.html clearly shows MUAs and the user interface (and the users behind) are simply to dumb to get things halfway right ... and SenderId will not change a thing with that regard. \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 Tue Aug 31 17:41: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 RAA05078 for ; Tue, 31 Aug 2004 17:41:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VLJGQe089436; Tue, 31 Aug 2004 14:19: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 i7VLJFQF089435; Tue, 31 Aug 2004 14:19:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VLJFCD089427 for ; Tue, 31 Aug 2004 14:19:15 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7VLS2qn000981; Tue, 31 Aug 2004 14:28:02 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7VLS2BP000977; Tue, 31 Aug 2004 14:28:02 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 31 Aug 2004 14:28:02 -0700 (PDT) From: "william(at)elan.net" To: Yakov Shafranovich cc: terry@ashtonwoodshomes.com, "'Paul Iadonisi'" , "'IETF MARID WG'" Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID supportin Courier) In-Reply-To: <4134C45E.5070207@solidmatrix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 31 Aug 2004, Yakov Shafranovich wrote: > Note the list arguments about silently swallowing emails and then think > why these arguments are relevant (hint: swallowing email on MUA level). > > It is clear to me from the entire Sender-ID development from its roots > in the ASRG, as well as the information I heard directly from Microsoft > employees on the subject, is that the Sender-ID standard is intended to > be deployed on the MUA level by Microsoft. Of course, they are free to > correct me. SenderID can not reliably be used at MUA level and in my opinion should not be used there. See my long object on this very topic at: http://www.imc.org/ietf-mxcomp/mail-archive/msg03769.html This was however discussed more at spf-discuss, my arguments there are: http://archives.listbox.com/spf-discuss@v2.listbox.com/200408/1237.html http://archives.listbox.com/spf-discuss@v2.listbox.com/200408/1255.html Unless I'm mistaken the same arguments were expressed before by others too but I only have copies of my own posts to find them in archive. My recomendation for MUA support is to require MTAs that do MARID record checks to add special received header (or specified fields in normal received header) and for MUAs to look for this header and if it is the one from the top-most Received header only then can MUA show to the user that certain from address is MARID verified, in such received header should already contain PRA address, which is the one MUA can show to the user (this is not to say MUA can't show other address that are typically involved in PRA to the user, but that is optional and carries no assurances that those addressed were ever checked). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 18: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 SAA07953 for ; Tue, 31 Aug 2004 18:18:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VLqXh2096724; Tue, 31 Aug 2004 14:52:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VLqXVA096722; Tue, 31 Aug 2004 14:52:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VLqWDa096716 for ; Tue, 31 Aug 2004 14:52:32 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7VM1kA6003577; Tue, 31 Aug 2004 15:01:46 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7VM1kwe003574; Tue, 31 Aug 2004 15:01:46 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 31 Aug 2004 15:01:46 -0700 (PDT) From: "william(at)elan.net" To: Yakov Shafranovich cc: "IETF MXCOMP (E-mail)" Subject: Re: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) In-Reply-To: <41349EEC.8000407@solidmatrix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Looking through my old asrg summary/archive , I find the the following message from archives talks about checking both "From:" and "Sender:" headers: http://www1.ietf.org/mail-archive/web/asrg/current/msg04684.html I can't find anything going futher (i.e. including Resent headers), but I would not be surprised if somebody posted about that too. Please go through archives on that thread. Also, unrelated to this group but of interest is this prior work on header cryptographic signatures for email messages (I believe this supercedes any claims Yahoo or others may make about this method): http://www.chaoszone.org/misc/spam.html P.S. I believe the messages from Microsoft people from links below make it clear that they had used prior work of RMX for Caller-ID (one message talked about _rmx subdomain even) and had published "responsible sender" from RFC822 headers idea in the public. If only I had number of the patent application to check ... but I'd not be surprised if these messages superceded that application, which means they should not have filed it considering the idea (which is obvious from email RFCs anyway) was already disclosed to the public and was based on the existing publicly published (as IETF draft!) work. On Tue, 31 Aug 2004, Yakov Shafranovich wrote: > (This message got stuck originally because of my own stupidity, I am > resending it to the list) > > > Andrew Newton wrote: > > > >> 4) You have stated above that you believe Microsoft's claim is > >> "nebulous" with regard to rights being claimed. Your release notes > >> state "Implemented Sender Policy Framework checking on the From: > >> header. Be sure to read the documentation and understand the > >> implication." Since checking of the From: header is listed in the -pra > >> document, are you concluding that this is not encumbered by Microsoft's > >> claim? If so, how did you come to this conclusion? > >> > > > > The ASRG archive runs several thousand messages. They start with a > > discussion on RMX. There is more than one message in there talking about > > the use of "From" headers for RMX lookup. If someone has the time to go > > through it, prior art is certain to be found. Perhaps someone should > > tell the lawyers. > > > > IMHO, in light of the possible prior art, it may be very probably that > > the potential patent application is invalid or will not approved. > > Therefore, it might be feasible to ignore the IPR claim all together and > > preceed with approval of Sender-ID. > > > > > > In any case, for example, here is a is a message posted to the ASRG list > > on May 7th, 2003 > > (http://www1.ietf.org/mail-archive/web/asrg/current/msg04390.html): > > > > -----snip---- > > On Wed, May 07, 2003 at 07:43:10AM -0700, Daniel Erat wrote: > > > I understand why RMX is not able to examine RFC 822 headers. My point > > > was that RMX does nothing to curtail the sending of messages with > > > forged 822 From: addresses. Since this is the only sender address > > > that most users see, and the address that replies go to (in absence of > > > a Reply-To: or related header), I disagree with the assertion that > > > this is not a severe problem. > > > > Well, RMX could be used to verify the From: address as well. > > Feel free to ask your MTA to do another RMX lookup after > > receiving the message body (and before sending the reply code). > > If you like it, you can do it. > > -----snip---- > > > > Another message as a reply to Bob Atkinson, the author of Caller-ID, > > talks about parsing "Received" lines: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg04321.html > > > > Another messaging discussing headers: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg04591.html > > > > A snippet of actual code that compares headers against DNSBLs in the > > context of the RMX discussion: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg00686.html > > =========================================== > > On a related note, here is a message posted on May 5th, 2003 by Bob > > Atkinson, the author of the Caller-ID draft talking about "domain > > purportedly responsible for a message: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg04231.html > > > > Another message from Bob dated May 6th, 2003 talking about the use of > > XML for RMX records and enhancing the RMX proposal: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg04302.html > > > > Another message talking about "From" headers, also from Bob: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg04333.html > > > > Here is a message from another Microsoft employee dated March 6th, 2003 > > regarding RMX: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg00608.html > > > > Another few messages from a Microsoft employee critisizing RMX: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg00646.html > > http://www1.ietf.org/mail-archive/web/asrg/current/msg00671.html > > > > ==================================================================== > > If we take a look in RFC 2014, we find the following in section 1: > > > > "Participation is by individual contributors, rather than by > > representatives of organizations." > > > > We also find that the ASRG adopted an following IPR policy on June 12th, > > 2003, requiring disclosure of IPR: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg05378.html > > > > At least one message was posted from Bob Atkinson after this policy was > > adapted without disclosing any IPR information: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg07090.html > > > > Here is another one discussing reputation systems from Bob Atkinson on > > October 31st, 2003: > > http://www1.ietf.org/mail-archive/web/asrg/current/msg07875.html > > > > Frequent readers of the ASRG list will note that Phil Hallam-Baker of > > Verisign explicitly stated a few times that his company may claim IPR on > > specific ideas he shared with the ASRG list. To my knowledge, none of > > the Microsoft employees ever did that. > > > > Also, the ASRG list is hosted at the IETF domain. We find the following > > notice at IETF's mailing list page (http://www.ietf.org/maillist.html): > > > > ----------------------------------------------------------------------- --- > > Any submission to the IETF intended by the Contributor for publication > > as all or part of an IETF Internet-Draft or RFC and any statement made > > within the context of an IETF activity is considered an "IETF > > Contribution". Such statements include oral statements in IETF sessions, > > as well as written and electronic communications made at any time or > > place, which are addressed to: > > the IETF plenary session, > > any IETF working group or portion thereof, > > the IESG, or any member thereof on behalf of the IESG, > > the IAB or any member thereof on behalf of the IAB, > > any IETF mailing list, including the IETF list itself, any working group > > or design team list, or any other list functioning under IETF auspices, > > the RFC Editor or the Internet-Drafts function > > ----------------------------------------------------------------------- --- > > > > The ASRG list maybe considered "any other list functioning under IETF > > auspices" and posting to it may be considered "any statement made within > > the context of an IETF activity is considered an "IETF Contribution". > > However, it is unclear whether IRTF lists fall under that. If the ASRG > > list does in fact fall under that, than postings to it are considered > > "Contributions to the IETF" and are covered under RFC 3667 and 3668: > > > > Yakov --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 18:52:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09831 for ; Tue, 31 Aug 2004 18:52:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VMQGvi002841; Tue, 31 Aug 2004 15:26:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VMQGwG002840; Tue, 31 Aug 2004 15:26:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VMQGs1002833 for ; Tue, 31 Aug 2004 15:26:16 -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 i7VMZQDT006835; Tue, 31 Aug 2004 15:35:26 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7VMZPkT006832; Tue, 31 Aug 2004 15:35:25 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 31 Aug 2004 15:35:25 -0700 (PDT) From: "william(at)elan.net" To: Mark Lentczner cc: IETF MARID WG Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe) In-Reply-To: <3BE5237E-FB8F-11D8-9ADB-000393A56BB6@glyphic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 31 Aug 2004, Mark Lentczner wrote: > Re-reading this thread, looking for common ground, I see > > 1) There is near universal agreement that domains will still want to > publish records about the 2821 Mail From identity. That was quite clear from the start. In fact when I first talked to Meng on the interim meeting about combination of SPF and Caller-ID he was quite clear that this is being done so that existing SPF records would be supported by wider range of software including from Microsoft, and that at the same time SPF libraries would also be upgraded to support new type records for Caller-ID but that both would continue to exist. > 2) There is still concern on where the TXT records should be published: > Either at something like _pra._marid.example.com vs. at example.com > itself. > > 3) It has been shown that even if records go into sub-domains, due to > the way DNS wildcards work, records still need to be distinguishable > based solely on their content, not their location. Yes, I made this quite clear. But after rereading David Blacka's last email on the subject: http://www.imc.org/ietf-mxcomp/mail-archive/msg03763.html I will no longer object to putting records in subdomains, I made wrong logical conclusion on it being useless solely because it does not achieve scoping by itself. In fact while providing scoping as part of spf data part is required, we can still benefit from subdomain/prefix placement of records in case when records are in fact completely different, then when somebody looks for one particular record type, they no longer get the other record and we can have larger size of records in dns and do not need to use approach of redirection that Mark previously desciribed. But at the same time there is a downside to doing it this way too as application, may end up doing more dns lookups. For example if application checks for PRA record first and then for mailfrom and first one is not published, it ends up doing second lookup for second record. While if records were both contained at the root of the domain, the application would only need to do one lookup. So choose what is worth - possible problems with larger dns record size or possible problems with larger number of dns lookups... > Therefore, I suggest that we adopt the scheme I labeled (3a): > > > 3a) Put scopes in the field > > Proposed by Wayne in > > http://www.imc.org/ietf-mxcomp/mail-archive/msg03441.html > > This scheme replaces the "/pra" and field in the version > > string with a list of scopes. For example: "spf2.0/pra,mailfrom" or > > "spf2.0/mailfrom". It applies to the whole record, so it only helps > > domains with very large records if their v=spf1 and spf2.0/pra records > > are otherwise the same. If the above two large records were the same, > > this would look like: > > > > example.com. IN TXT "spf2.0/pra,mailfrom ... some very > > long record here ..." > > The only counter to this scheme (other than some preference for the > others) was that it would require existing v=spf1 domains to > re-publish. I don't beleive this would be the case:: All existing SPF > implementations are likely to accept v=spf1 for quite some time, if not > forever. And, because it is also likely that all existing SPF > implementations would be rev'd quickly[1] to support spf2.0/mailfrom, > then new sites can simply publish the new version. You're assuming that existing SPF implementors want to support PRA which maybe an issue because of Microsoft licese requirements. If implementors don't want to support PRA, they have no reason to not coninue to only work with SPF1 records. There is a solution available which completely supports existing SPF base and as I already posted before: example.com. IN TXT "spf2.0/pra,mailfrom ... very long record ~all" is completely (100%) equivalent to: example.com. IN TXT "v=spf1 sc=p,m ... very long record ~all" Because in case of records being equivalent a scoping modifier is interpreted exactly the same way as version modifier for entire record. > [1]: There aren't that many existing implementations, and everyone > running one knows that they are running less than 1.0 code and > generally is keeping an eye on updates. I hope you're right, but if I remember the talk about merging SPF and CallerID was so that existing SPF record could be supported by both. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 19:02:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10339 for ; Tue, 31 Aug 2004 19:02:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VMeCI2005701; Tue, 31 Aug 2004 15:40: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 i7VMeCT4005700; Tue, 31 Aug 2004 15:40:12 -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 i7VMeAvN005680 for ; Tue, 31 Aug 2004 15:40:11 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i7VMe66K023147; Wed, 1 Sep 2004 00:40:06 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i7VMbvgj032269; Wed, 1 Sep 2004 00:37:57 +0200 From: Hadmut Danisch Date: Wed, 1 Sep 2004 00:37:57 +0200 To: jpinkerton Cc: "Anne P. Mitchell, Esq." , ietf-mxcomp@imc.org Subject: Re: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) Message-ID: <20040831223757.GA31987@danisch.de> References: <2D922BA4-FB78-11D8-BA2B-000A95AC5778@isipp.com> <006101c48f92$30ee5760$914b573e@idimo2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006101c48f92$30ee5760$914b573e@idimo2> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 31, 2004 at 09:35:13PM +0200, jpinkerton wrote: > the United States Patent Office regarding patent applications. It would be > *most* useful if the people on this list who know of prior art and > obviousness "proofs" could get in touch with that office immediately the > patent application is lodged. Prior art of what exactly? I didn't have the time to read all postings since the San Diego meeting, and I still don't know what exactly Microsoft claims to have a patent on. If there is a precise description then we know what to look for in the archives. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 19:16:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11077 for ; Tue, 31 Aug 2004 19:16: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 i7VMo1nI007378; Tue, 31 Aug 2004 15:50: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 i7VMo1AN007377; Tue, 31 Aug 2004 15:50:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VMo06S007366 for ; Tue, 31 Aug 2004 15:50:00 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i7VMo5na023299; Wed, 1 Sep 2004 00:50:05 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i7VMihs2032536; Wed, 1 Sep 2004 00:44:43 +0200 From: Hadmut Danisch Date: Wed, 1 Sep 2004 00:44:43 +0200 To: Yakov Shafranovich Cc: "IETF MXCOMP (E-mail)" Subject: Re: DEPLOY: Prior Art for PRA Message-ID: <20040831224443.GB31987@danisch.de> References: <4134BBF0.6060604@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4134BBF0.6060604@solidmatrix.com> User-Agent: Mutt/1.5.6+20040523i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 31, 2004 at 01:57:04PM -0400, Yakov Shafranovich wrote: > > The following is the PRA algorithm from the current draft: Why do you call this an algorithm, anyway? It is just giving header lines a priority or precedence. Use the one with the highest priority, and if there is no such, use the one with the second highest priority, if there is still no such use the one with the third highest priority... is not what I'd call an algorithm. It is just assigning priorities to header lines. The idea of priorities and precendences is already known for centuries. You can't patent a definition of priorities. It has not even been invented or defined, it is just a observation of the current practise. So what exactly is new and what exactly is to be considered as an algorithm? Hadmut From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 19:59: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 TAA14483 for ; Tue, 31 Aug 2004 19:59: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 i7VNTcIX014371; Tue, 31 Aug 2004 16:29:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VNTc3d014370; Tue, 31 Aug 2004 16:29:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VNTbov014361 for ; Tue, 31 Aug 2004 16:29:37 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-112-109.area3.spcsdns.net ([68.245.180.58]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2I4J-0000iw-6V; Tue, 31 Aug 2004 19:29:41 -0400 Message-ID: <413509D0.4090203@solidmatrix.com> Date: Tue, 31 Aug 2004 19:29:20 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Hadmut Danisch CC: ietf-mxcomp@imc.org Subject: Re: DEPLOY: Prior Art for Sender-ID (was Re: DEPLOY: SPF/Sender ID support in Courier.) References: <2D922BA4-FB78-11D8-BA2B-000A95AC5778@isipp.com> <006101c48f92$30ee5760$914b573e@idimo2> <20040831223757.GA31987@danisch.de> In-Reply-To: <20040831223757.GA31987@danisch.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hadmut Danisch wrote: > On Tue, Aug 31, 2004 at 09:35:13PM +0200, jpinkerton wrote: > >>the United States Patent Office regarding patent applications. It would be >>*most* useful if the people on this list who know of prior art and >>obviousness "proofs" could get in touch with that office immediately the >>patent application is lodged. > > Prior art of what exactly? > > I didn't have the time to read all postings since the San Diego > meeting, and I still don't know what exactly Microsoft claims to > have a patent on. > > If there is a precise description then we know what to look for in the > archives. > That's the problem - there isn't a precise description and the Microsoft lawyers might even be right on this one - they don't know what they can claim until the Patent office actually gives them a decision. Although, they could let us know what they are trying to claim but then it would defeat the whole purpose of filing the patent application in secret? The relevant question to us here, is whether the IPR issue will affect deployment. Part of it is whether we should ignore the IPR claims all together if they appear to be meaningless. In RFC 3669, section 4.6 examples are given of IPR claims that were choosen to be ignored by the WG because they were frivilous. The best quote is this part which in light of previous posting referencing the ASRG list might be relevant: ------------------------------------------------------------------------------ In another case, patent claims were asserted that appeared to be derived from working group discussion, rather than vice versa (or independent discovery). The claimants were known to be following the working group's work when the ideas were proposed, and their patent filing was considerably subsequent to that time. ------------------------------------------------------------------------------ Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 20:16: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 UAA16270 for ; Tue, 31 Aug 2004 20:16: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 i7VNoOUv018255; Tue, 31 Aug 2004 16: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 i7VNoOjU018254; Tue, 31 Aug 2004 16:50:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VNoN7P018239 for ; Tue, 31 Aug 2004 16:50:24 -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); Tue, 31 Aug 2004 16:50:26 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 31 Aug 2004 16:50:26 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 Aug 2004 16:50:25 -0700 Received: from df-dogbert-msg.exchange.corp.microsoft.com ([157.54.5.14]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 16:50:13 -0700 Content-class: urn:content-classes:message Subject: RE: TECH-ERROR: DNS Record Types MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 31 Aug 2004 16:50:24 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V8.0.155.1 Thread-Topic: TECH-ERROR: DNS Record Types thread-index: A8+Nc7+AA/++T412Rk+mC7I2U9p0+Q+PxT0w From: "Jim Lyon" To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , "IETF MARID WG" , "Mark Lentczner" X-OriginalArrivalTime: 31 Aug 2004 23:50:13.0784 (UTC) FILETIME=[42538980:01C48FB5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VNoO7P018248 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Saturday, August 28, 2004 at 7:56 PM, Ólafur Guðmundsson wrote (about DNS record types): > The fundamental difference between your position and mine is > you: want everyone to be compliant at all times. > me: Specify clearly fully compliant state and tolerate non compliance > during phase-in. This is the crux of the disagreement. However, there are at least two relevant phase-in periods: 1. In the first phase-in, mail senders begin to publish records, and those mail senders who need to begin to add additional headers. 2. In the second phase-in (more relevant to this discussion), people with "challenged" DNS implementations begin to publish and/or query for the new record type. The problem is that the first phase-in lasts months, but the second phase-in lasts many years. (As I mentioned previously, it's at least 10 years before the number of installed Microsoft OS's with lousy DNS implementations becomes small enough to ignore.) So, given that Ólafur's "short term" isn't in fact short, my point still stands. Require (MUST) TXT records and encourage (SHOULD) new record types. Ólafur also worries that if we go this route, there will never be a time when publishing only an SPF2 record becomes acceptable. This isn't necessarily so. There are two possible futures: a. "Challenged" DNS implementations get fixed over time, and more and more people come to query/use SPF2 records. Eventually, a new standards action requires the new record type and deprecates use of TXT records. b. "Challenged" DNS implementations continue to be plentiful over time. In this case, we'd sure look stupid of we followed Ólafur's approach. Assuming that we go with MUST for TXT records now, I submit that a built-in opportunity to revisit the issue is when SenderId is considered for advancement from Proposed Standard to Draft Standard or Internet Standard. Should upgrades to DNS servers proceed faster than the standards track, it's not hard to convene a working group to reconsider this issue. On Tuesday, August 31, 2004 at 1:30 PM, Mark Lentczner wrote: > I agree with Ólafur on this, since I think this document is a standard, > not a how-to manual. The How-to's and web wizards will make it clear > to people that they need to publish the TXT form for now. The purpose of a standard is to describe the rules for interoperable implementations. But the "MAY" in the current doc (MAY publish/query TXT records) means that it's truly optional whether to do this. This is just wrong -- you won't interoperate with a substantial fraction of the Internet if you don't follow the MAY. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 21:11: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 VAA20287 for ; Tue, 31 Aug 2004 21: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 i810ZNSR026844; Tue, 31 Aug 2004 17:35: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 i810ZN8Y026843; Tue, 31 Aug 2004 17:35:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i810ZL1m026834 for ; Tue, 31 Aug 2004 17:35:21 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id i810iqLf024179; Tue, 31 Aug 2004 20:44:52 -0400 From: To: "'Yakov Shafranovich'" , "'Graham Murray'" Cc: Subject: RE: Unencumbered Checking Date: Tue, 31 Aug 2004 20:33:36 -0400 Message-ID: <000601c48fbb$527a0040$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <4134E4C9.5080608@solidmatrix.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Yakov Shafranovich > Sent: Tuesday, August 31, 2004 4:51 PM > To: Graham Murray > Cc: ietf-mxcomp@imc.org > Subject: Re: Unencumbered Checking > > > > There are many instances were the check will be done after the SMTP > transaction. SpamAssassin is an obvious example. > > Plus, the MUA checking is what makes this valuable against phishing. > > Yakov > Why? If the email is rejected before being written to users mail spool files, it still doesn't get to the MUA. But rejecting at the MTA also saves bandwidth etc. So why isn't checking at the MTA valuable against phishing? Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 21:11: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 VAA20288 for ; Tue, 31 Aug 2004 21: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 i810fORn027951; Tue, 31 Aug 2004 17:41: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 i810fOQm027949; Tue, 31 Aug 2004 17:41:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i810fN9m027938 for ; Tue, 31 Aug 2004 17:41:24 -0700 (PDT) (envelope-from research@solidmatrix.com) Received: from 000-112-109.area3.spcsdns.net ([68.245.180.58]) by manet.hmdnsgroup.com with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1C2JBj-0004Vv-FO; Tue, 31 Aug 2004 20:41:24 -0400 Message-ID: <41351A9C.4050500@solidmatrix.com> Date: Tue, 31 Aug 2004 20:41:00 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: terry@ashtonwoodshomes.com CC: "'Graham Murray'" , ietf-mxcomp@imc.org Subject: Re: Unencumbered Checking References: <000601c48fbb$527a0040$2766f30a@development.greatgulfhomes.com> In-Reply-To: <000601c48fbb$527a0040$2766f30a@development.greatgulfhomes.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit terry@ashtonwoodshomes.com wrote: >>-----Original Message----- >>Subject: Re: Unencumbered Checking >> > >> >>There are many instances were the check will be done after the SMTP >>transaction. SpamAssassin is an obvious example. >> >>Plus, the MUA checking is what makes this valuable against phishing. >> > > Why? > > If the email is rejected before being written to users mail spool files, it still doesn't get to the > MUA. But rejecting at the MTA also saves bandwidth etc. > > So why isn't checking at the MTA valuable against phishing? > Let me more clear - it can in theory be used as a check on the MUA level or past MTA for phishing in those cases where the underlying MTA does not support Sender-ID yet but the MUA or a filter running behind the MTA does. Obviously it is better to reject stuff at MTA level. Another possibility is when the MTA doesn't reject it out right btt assigns a score. Of course this is in theory, take a look at William Leibzon's earlier reply to this of why this is might not feasible. Yakov From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 22:32: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 WAA25074 for ; Tue, 31 Aug 2004 22:32: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 i811vjKh043883; Tue, 31 Aug 2004 18:57:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i811vjmW043882; Tue, 31 Aug 2004 18:57:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from willow.gnomon.org.uk (willow.gnomon.org.uk [69.10.132.76]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i811viQR043865 for ; Tue, 31 Aug 2004 18:57:45 -0700 (PDT) (envelope-from roy+dated+1096595858.28705f@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by willow.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i811veTw007988 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 1 Sep 2004 02:57:47 +0100 (envelope-from roy+dated+1096595858.28705f@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i811vdXL025455 for ; Wed, 1 Sep 2004 02:57:39 +0100 (BST) (envelope-from roy+dated+1096595858.28705f@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i811vd0a025452 for ietf-mxcomp@imc.org; Wed, 1 Sep 2004 02:57:39 +0100 (BST) (envelope-from roy+dated+1096595858.28705f@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 01 Sep 2004 02:57:34 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16693.11406.185197.719219@giles.gnomon.org.uk> Date: Wed, 1 Sep 2004 02:57:34 +0100 To: Dean Anderson Cc: Roy Badami , Paul Iadonisi , Subject: Re: In favour of Sender ID (was: DEPLOY: SPF/Sender ID support in Courier.) In-Reply-To: References: <16691.49492.811055.57958@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (willow.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.72, clamav-milter version 0.72 on willow.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 >>>>> "Dean" == Dean Anderson writes: Dean> This is completely wrong. You are confusing a license with Dean> a contract. Patent laws in various countries prohibit use Dean> of patented technology and intentional violations have Dean> severe penalties, where unintentional violations have Dean> economic penalties and injunction. I think you're missing my point. I fully realize that distributing software may violate patent law. However a lot of discussion here has focussed on whether the existence of the Sender ID license causes distribution of software to be contrary to the GPL. My point is: clearly, if you aren't a party to the patent license then its wording can't have any effect on you. Either the GPL allows you to distribute software that might have claims on it or it doesn't. Distributing software may (obviously) be unlawful under patent law, but the wording of a license you haven't agreed to isn't going to affect your rights under the GPL. -roy From owner-ietf-mxcomp@mail.imc.org Tue Aug 31 23:09:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26927 for ; Tue, 31 Aug 2004 23:09:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i812hY99051753; Tue, 31 Aug 2004 19:43: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 i812hY7s051752; Tue, 31 Aug 2004 19:43: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 i812hXRs051745 for ; Tue, 31 Aug 2004 19:43:33 -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 8A9D84149B for ; Tue, 31 Aug 2004 19:43:40 -0700 (PDT) Subject: How is a mail domain like an insurance company? From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1094006619.17480.463.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 31 Aug 2004 19:43:39 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit When buying insurance from a broker, one of the first precautions is to check the name and license of that broker against an institutional registry. The broker may then present several insurance plans, where then names of these insurance companies would be checked and may be asked to confirm their relationship with the broker. Many states relegate insurance brokers to a status of an order taker charged with the responsibility for placing coverage or giving the client timely notice that they cannot do so. They also often play an important role of tracking performance of insurance companies to protect their clients by not offering coverage from known bad actors. In this analogy, there are many more insurance companies than brokers, and an insurance broker could work out of many offices where these offices may be shared by other brokers. Imagine buying coverage from an anonymous broker, where both the insurance company and the broker are checked by asking the insurance company for a list of all the office addresses of their brokers. These lists may be large, and to gather the entire list, partial lists must be obtained from each of their divisions where they are maintained separately. If there is a problem, there is a more fundamental problem. With whom did the actual transaction take place? Worst still, some offices are not secure, and some insurance companies have roaming brokers. This method of checking will force clients not to deal with insurance companies with roaming brokers where lists read "and other offices." Rather than checking the reputation of the broker, with this address list scheme, the check must be made against the office address. (Some claim reputations can be based upon the insurance company when using anonymous brokers. This could never be defended however.) Checking the identity of the broker first makes obtaining the cumbersome office address list unnecessary. If there is a problem, the trusted party in the transaction claiming to have been acting on behalf of the insurance company is known. Checks that only compare addresses provided by an insurance company of all broker's offices, makes holding an insurance company liable difficult. The insurance company can readily claim to have not been part of the transaction. One may provide authorities the office address and color this office suspect, while there may be other brokers sharing that office. The broker causing the problem may work out of many offices. Hardly an effective means to curtail trouble. Anyone looking at this strange checking scheme would quickly point out the basic flaw. One must validate the broker and then establish the relationship with the insurance company by name. But this is not how Sender-ID works. As it turns out, checking the name of the broker, otherwise known as the Mail Transfer Agent, can be done with no extra overhead. If there is a problem, the name of the MTA earns the reputation. After all, part of their job is to protect their clients from the bad actors. By using the insurance broker model, an efficient and fair scheme of assessing the acts of the MTA becomes possible. As with insurance companies, domains could restrict their coverage to be handled by a few agents by name, rather than by address. This can be easily asserted with a simple name list which hides the delegation of addresses. Roaming from office to office is without a problem, as the name is used to establish trust. -Doug