Slashdot Mirror
TarProxy Creates Tar Pit... For Spammers
agravaine writes "I ran across TarProxy, which, IMHO, is one of the cleverest spammer-handling ideas I've seen yet. The gist: Early detection of incoming spam [using the statistical techniques pioneered on the client side] could be used to create an artificial scarcity of bandwidth experienced only by spammers." This project hasn't gone very far yet, but essentially is slows SMTP requests to suspected spammers. If this really works, and is installed on enough of the net, it could work. 144 spam so far today. Anything would be an improvement. CT Yup, it's a dupe. There wasn't anything better to post at 9am on a sunday, so you can just bitch about me instead ;)
"These classifiers already come in many forms. There are POP3 proxies, IMAP proxies, mail file processors, and even classifiers built directly into mail clients. I use PopFile (a naïve Bayesian classifier in a POP3 proxy) at home with great success. Some work better than others, but with a little training, they all seem to work pretty well. Unfortunately, they have a common shortcoming: They don't cause the spammers any pain."
What is the goal?:
"And we all want to cause spammers pain."
How do they want to accomplish this pain?:
"None of these classifiers are capable of causing the spammers any pain because the spammer is long gone by the time the classifier has the opportunity to process the message. What we need is a way to use the classifier against the spammer while the spammer is still connected."
This is brilliant. If all you do is clean up after the spammers when they are long gone, there is little motivation for them to stop. So what if they've dumped a bunch of garbage in your in-box? They don't stick around to see you clean up. But this idea hits them while they are in the process of spamming you.
That's the key: Make it harder/more unpleasant/less cost-effective for the spammers and you discourage them from spamming. Hit the source, not the results.
------
This is an interesting pro-active approach, but isnt most mail sent through open proxies, which have absent sysadmins? If we cant get them to lock down their mail servers, how can we get them to install this?
1) the /. creaters are by-in-large the /. people that control the posting of stories
2) Most stories contain at least one URL
3) URL's, by in large, are unique
Then;
Would it be so hard to modify the actual posting code to check that the URL hadn't already been part of a story header within say the last 60 days?
Such a check would help both /. and all others that run / code.
Just a thought!
-- Multics