David Morris wrote: > > their customers about the opportunity to use a new app. The larger > > providers (AOL, MSN, Yahoo, ...) can drive media attention and might > > The providers you have listed all have what I'd call closed > applications. Yahoo is (largely) browser based working from a > MUA coded in their server. AOL is client-server, again the > MUA is in their server and, I believe but have never > observed, MSN is similar to AOL. Other examples as well. In one incarnation, MSN mail is simple SMTP/POP3, in another it is web based. That is less the point than the fact they collectively cover a very substantial number of clients. Cover those, and provide the enterprise mail administrator with an equivalent tool, and the rest of the world will follow, including the spammers. It will take external action to push back and stop the spam. > > Once a new/updated mail protocol is available, then each of > the above must implement updates to their servers. Then > deploy the changes. The new revised system will just happen > to the average user of those services. > > The slower process will be the millions of smaller mail > infrastructures, They feel the pain of spam as much (or more on a percentage basis) as anyone else. Why wouldn't they be motiveted to deploy a spam reduction tool? > > As long as the new protocols provide a migration plan and > support, upgrade over a year or two is a reasonable > expectation. A key requirement on the providers of the server > and client software is to NOT include dependancies on related > system software versions which would force the prospective > upgradee to encounter the upgrade domino chain which ends up > in substantial costs for unrelated software or hardware. I agree completely with the point about dependencies, but there should be absolutely no interoperability between the old and new. The migration plan should simply be to let the existing infrastructure and set of apps die for lack of use. Tony