Whenever the ISP sees his spam log getting hit from a particular IP address, he could want the associated client one time, and then anymore problems they are out.
Also as indicated by Pete (thanks for the post Pete), the cost of filtering spam at the ISP versus the cost of everyone else filtering are much less and it would benefit the Internet largely to stop all those packets before they reach the backbone. I really am not talking about word filters and that kind of stuff, I mean verifying that the return address and the sending address match and the HELO is valid for the associated client that is at that IP address. That way if people else where don't want to read the stuff being sent, it can be filtered by the end user and/or valid removal requests wouldn't be sent to bogus address that spammers use. This problem could be 75 to 90 % solved by US ISP companies and those that refuse to comply will be penalized enough to make them comply or they lose their IP addresses, etc. Even if the ISP companies would force all static bulk mailers into one group of IP addresses it would be easier for us to filter that block knowing that we will not be filtering legitimate mail lists etc. Ted -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, December 07, 2004 5:35 AM To: Bruce Barnes Subject: Re[2]: [IMail Forum] Lycos goes limp On Tuesday, December 7, 2004, 7:29:00 AM, Bruce wrote: BB> Since every user's definition of "spam" is different, it makes it BB> exceedingly difficult for the ISP to do the enforcing. BB> If there was a standard definition of what constitutes spam, it would make BB> the proposal you have outlined much easier. BB> If we filter all of the porn, then one user complains. If we filter all the BB> "advertising" another user complains. If we filter word or phrase "a" then BB> another user complains, if we filter word or phrase "b" another user BB> complains that we are infringing on their right to receive and send e-mail BB> based on free speech - and I agree with them. BB> In order for ISPs to filter spam, everyone has to agree on what constitutes BB> spam. That would be like trying to get my family to agree on which movie to BB> go see on a saturday night or what television program to watch - impossible. Excuse me for butting in, but this is just not true. I am personally responsible for all of the false positive reports for all of hundreds of customers, each with many thousands of their own customers on average. (millions of messages per day, hundreds of thousands, if not millions of mailboxes) Message Sniffer rejects somewhere between 60% and 98% of all email on any given day depending upon the system. The number of false positive reports we see are vanishingly small in those numbers. While this is not good enough to meet my standards, it does prove that it IS possible to solve this problem. If nothing else this proves that the vast majority of "What is spam" can be agreed upon, and that the exceptions can be handled with very small holes in the filtering process --- much of which can be automated (we have helped our customers develop this kind of automation). It is not only possible, but reasonably practical to do this - even now with an incomplete system. By practical I mean that the real, sustainable costs of doing this are also vanishingly small. We charge almost nothing compared to the number of end users served and we are credibly effective at this task. We have also proven that the business model works - so by extension, the costs - even of our as-yet incomplete approach - are completely reasonable. With a more complete system we will be able to do a much better job at an even lower cost -- it's only a matter of further development. The conventional scientific / engineering method for this problem simply breaks down and is used as an excuse to call the problem hopeless - don't believe it. "WE" do not need a concreted definition of spam to solve this problem. The problem is fluid and extremely dynamic as the solution must be. It cannot be solved by first defining the problem concretely and then engineering a complete solution to that specification. Anything so rigid is essentially designed to fail in the same way that rigid, process oriented command/response user interfaces could not stand in the face of the event driven interfaces we have today. I think we need to start defining this problem differently. It is not a problem of "spam" abuse... it is a signal-to-noise problem. * Each receiver in the system must have, and currently lacks, an effective mechanism to define what is signal and what is noise and the ability to reduce the noise that they receive --- no matter how that noise is defined. (To continue to radio metaphor, today we are still using crystal sets to receive and spark-gap rigs to transmit. When there were only a handful of stations on the air this didn't matter... now that we're here en-mass, we need better technology to manage this "spectrum" more efficiently. The technology can and must evolve.) * In addition, each receiver's filtering (or "tuning") mechanism must not interfere with the other receivers in the system. With these two simple rules it is possible to protect free speech, open access, and control over this kind of abuse. There is no need for any central governing agency (which would be impractical) - nor is any single, concrete definition of "spam" and "non-spam" required or even appropriate. Each receiver must, and can, make their own definition. There is a second problem that is related, but also not unsolvable if put in the correct frame - that of security and resource abuse. * The fabric of the network should deny and/or suppress undesired and unauthorized traffic. * The suppression mechanism must not unnecessarily interfere with desired / authorized traffic (traffic in adjascent channels?). If "the problem" is addressed from this perspective and "WE" recognize that there is no perfect way to reduce "noise" or eliminate abuse then viable solutions become apparent. MHO _M To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
