Dave Crocker wrote: > Please indicate some historical basis for moving an installed > base of users on this kind of scale and for this kind of reason.
WWW browser deployment shows that given appropriate motivation, users will aggressively take advantage of a new app. Yes I consider this to be a new app, even though it is replacing an existing capability. Rather than force people to move or upgrade, give them a new tool and explain the value. They will move as soon as they believe it is less painful than staying where they are. Given the growing level of complaint, and the fact that it will be at least 2 years before anything is ready to deploy, just about anything will be an easy sell. > > > TH> If the courts routinely granted judgments to > TH> individuals of 100 $/euro for every received unsolicited message, > TH> people > > a transition plan for 100 million users that relies on an > "if" concerning entirely new behaviors for a large number of > independent judicial systems around the world is a rather > fragile dependency, to say the least. > > (and, yes, I realize that that was just an example. so, > please, go ahead and provide a scenario that is not equally > fragile. i can't.) > I would argue this is not entirely new behavior, just that one widely publicized instance needs to establish precedent that receiving unsolicited email constitutes an abuse of personal resources and establish the value of that abuse. Since I think we are talking small-claims here ($100/day per spam source), it would be most efficient for the courts to have a procedure where the claimant provided the abusing email with tracability to the origin, then an automatic judgment could be issued (yes that is new, but the newness is about efficiency, not basic process). Defining an alternative mechanism is the IETF's job. As long as we explicitly refuse to allow interoperability, we don't need to worry about a transition. The mail service providers have the means to inform their customers about the opportunity to use a new app. The larger providers (AOL, MSN, Yahoo, ...) can drive media attention and might even help with any legal efforts to make the case that the new app will have anti-spam characteristics. In any case, transition is not a problem when we simply let the spam laden legacy die off as people start refusing to use the old apps. > > TH> would jump at the chance to run the new mail tool, and spam as we > TH> know it would loose its economic viability. Making that > work means > TH> absolute traceability of the message origin. > >> For this effort to be effective, I think it will have to > be done in a > >> way that is at odds with the traditional IETF thinking: > >> > >> 1) Compatibility with SMTP is not desirable > > why? See above about this being a new app. Requiring integration and compatibility will only create unnecessary complexity, and won't show any quantitative value to the end user. Also, as Alain pointed out in the mail I was responding to, interoperability simply creates a forward path for the SMTP based spam. Just make them parallel systems and move on. > > > >> 2) Some form of privacy is not desirable > >> 3) To much scalability is not desirable > > scalability is not desirable? wow. > > please explain. You cut off my comment that scalability is desirable everywhere except at the originator. The point is to raise the cost at the origin to bias the economics against random spamming. Something like requiring recipient based public key cryptography substantially raises the originator cost for mass mailings. Mail list servers would be a problem if we only use public key, so another part of the new system could be establishing a symmetric key as part of subscribing to a mail list. Clearly we have a number of technologies available, we just need to define the characteristics of the desired system and start applying technologies to build a new app. Tony
