Social problems are not that simple. They are not solved by confrontation. Because there is no confrontation, there is no victory to be had. But a confrontation (physical or legal) without regard to rights and reason will only go badly for those who pursue it. Some anti-spammers might be happy to find a spammer in a back alley, and beat them. But they would find themselves up on assault charges. They would "lose". Spammers have rights, too. Assuming they do not is a falacy. However, this was the falacy that caused defeat in 1998, (as I predicted in 1997). People assumed they could shout down anyone who disputed the costs of spam or who suggested that they had to be reasonable with respect to spammers rights, and so they used that as their "cause". The DMA could not be shouted down, and were able to present their case, and debunk the anti-spammers. Who "lost". --Dean On Mon, 26 May 2003, Eric A. Hall wrote: > > on 5/26/2003 12:40 PM Dean Anderson wrote: > > <taxonomy and observations snipped> > > > The issue of detecting abuse was the focus of the MIT anti-spam > > conference. There are many paths presently being pursued: Blacklists, > > header analysis, and various kinds of content analysis. I think the > > general consensus was that content analysis offers the most promising > > means of detecting and blocking abuse. > > The problem is that this defines defeat as victory. > > There is also existent proof that filtering is only "mostly" successful at > even its limited role. There are plenty of problems with false positives, > delayed positives, and so forth, which cumulative conspire to make this > approach less than functional as anything but a stop-gap measure. In that > regard, filtering is analogous to defining ~delayed defeat as victory. > > What would victory actually look like? To me, it would be keeping the crap > off my network in the first place. Forcing people to engage in full-time > warfare with the ethically bankrupt is not a victory. Telling people to > give up and take it is not a victory. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > >