I think it would be safe to say that you should be careful where you bring things like this up. I'd venture to say on this list you will probably get some insightful comments, but I'm not sure how many people on this list are really up to speed on what's going on out there in the anti-spam world. On the other hand, if you sent that email to an anti spam list/group from the various IETF working groups to the multitude of other communitites trying to deal with this problem, I can guarantee a naive statment like:
> > Surely this is not a new idea, but I cannot see any fault. Will effectively piss people off. More out of frustration than anything else. Not a day goes by in any well known spam group without someone proposing a Spam Solution, and some people are really persistent (like this guy who kept persisting on quite a few IETF lists recently http://www1.ietf.org/mail-archive/web/asrg/current/msg11242.html) and refuse to accept all of the technical hurdles, or really just trivialize them with a statment like that. If you're really interested perhaps you should consult the list we've compiled: http://www.rhyolite.com/anti-spam/you-might-be.html To make sure you're not rehashing things that have already been reviewed a multiitude of times, and perhaps spend a little time reviewing some of the common strategies out there currently like SPF(pobox/Meng), Sender-ID (MS), Identified Internet Mail (Cisco), BATV (Dave Crocker....not sure if this is his personal thing), Domain Keys (Yahoo), and well....the list goes on and on and on and a good introduction to it all could be found at http://spf.pobox.com/whitepaper.pdf Which is a whitepaper Meng of Pobox wrote that is more or less current as of the FTC summit on spam that was held concurrently with the IETF in D.C. in the fall. Of course there was lots of confusion at that point as well but essentialy someone will either have to come up with a solution that doesn't depend on widespread implementation like BATV or will have to work with one of the many emerging standards which are starting to get widespread acceptance because there's no way to fight the tide even with a "technically superior" solution per se. It would be nice to think that some major out of the box thinking could provide an elegant soultion that will work for everybody, but people have been trying this for some time, and really you'll probably just end up rehashing something that somone already failed with. Though I will say that Hadmut Dansch's proposal at that same FTC summit for breaking email addresses up into countries was an interesting exception to this belief. The paradigm I agree with down the road is that all of this baysian crap that we use along with blacklists etc. will slowly give way along with the junk mail folder, and eventually be replaced by a "quality mail folder" that will evolve once Authorization, Accredidation, and Accountability are all in place and you can guarantee that mail is in fact from the person it says it is, that they had the right to send it, and that their reputation is good enough that you care to read their email. Just the thoughts of someone who's been in pretty deep....... -T p.s. I wouldn't mind seeing that honeypot strategy incorportated into a P2P anti spam system like GoSSIP that I used to follow (http://sourceforge.net/projects/gossip-project/) as it could probably be efficient if it was distributed......but I still don't think there's any degree of longevity On 5/18/05, Stewart Stremler <[EMAIL PROTECTED]> wrote: > begin quoting m ike as of Wed, May 18, 2005 at 12:11:56PM -0700: > > new to list ... wanted to propose and get feedback on a spam tactic > > > > It proposes a way to filter out spam and a way to make spamming > > cost prohibitive. > > > > Suppose one were to create N=100 fictitious email addresses for each > > valid email address that they have, and then offer them up to the > > world of spammers. > > How do you offer 'em up? > > > Mail arriving at those addresses is considered spam. Mail arriving at the > > valid address is filtered by crosschecking it with the fictitious accounts. > > N could be any number, of course. Whatever it is, it would be a cost > > factor for spammers. If the approach succeeded in making spam cost > > prohibitive, then our cost would only be the "up front cost" for the first > > year or two. > > "Honeypot" is the name of the generic concept. > > > Surely this is not a new idea, but I cannot see any fault. Even if it > > failed > > to rid the world of spam, lol, it still seems to provide an effective > > filter. And in that case, sharing fictitious addresses would bring > > down our costs. > > How do you choose to ignore the spammers? > > Filter on the sender's email address? That doesn't work so well -- > spammers use real email addresses and generate (unique?) email > addresses. > > Block the IP of the sender? That's being done (blackhole lists). And > they do run honeypots to harvest the IP addresses of spammers. But the > zombie networks give the power to the spammers who use 'em. > > I like the idea of greylisting, coupled with a honeypot-driven realtime > blackhole list. > > I also am trying to think of the downside of changing the SMTP spec > to keep the connection open until AFTER the receiver has recieved the > body and had a chance to run the headers/body through a spam-filter. > If the email resembles spam, then the filter can reject it with an > informative message. > > (Immediately, you can reject HTML with a message that says "HTML is > not accepted." and all the HTML spam "just goes away", while people > who accidently send you HTML email get a useful bounce message that > they can use to correct the issue and send again.) > > It keeps the connection open while scanning, which (presumably) > slows the rate that spam can be sent, and increases the chance > that the spammer will end up in an RBL, which increases the cost > to the spammer. > > -Stewart "Not happy with the idea of changing the protocol." Stremler > > > > -- > [email protected] > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list > > > > -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
