ietf-asrg
[Top] [All Lists]

Re: [Asrg] Whitelisting on Message-ID (Was Turing Test ...) honey pot plug

2003-04-09 11:34:31
At 10:59 AM 4/9/2003 -0700, Chuq Von Rospach wrote:

On Wednesday, April 9, 2003, at 09:38  AM, Kee Hinckley wrote:


That's the major flaw with the honeypot solution. It deals very poorly with evasion. As soon as honeypots become a problem, spammers will begin to write more sophisticated tests that try and detect honeypots.

I posted an easy way to get around honeypots the other day -- regular tests. Easy to do using a small array of captive accounts, hard to catch.

Any solution that's so easy *I* can pull a way to isolate it off the top of my head is something not worth spending energy implementing, because it's a solution that works only because spammers haven't had enough hassle from it to work around it. That's not even an arms race, that's throwing snowballs at a tank. It'd take us a lot more time and energy to build up a honeypot system annoying enough to make them notice than it'll take for them to build a system to make that honeypot system useful only against stupid spammers.

So IMHO, it's a bad place to spend our energy, but it won't even slow down the smart spammers, and we don't need sophisticated tools to catch stupid ones.

Obviously you are smarter than the spammers, Ralsky in particular. See my recent reply for more. I suspect I know things about some spammers that no one else here knows. That's because I trap relay tests. Whether the spammers sending the tests are smart or dumb I can't say. I didn't have to be at all smart to catch their tests - nobody does. They aren't smart enough to be able to find open relays without sending open relay tests. (Creative use of DNSBLs excepted, but that doesn't discover new open relays.)

I responded to your earlier post, I think, by saying that just watching the spammer relay tests is an important function, currently not done, and (IMHO) worth the time of those here. I do it by trapping the tests: spammers could learn what that means and no longer test IPs that accept tests but don't deliver them. I specifically said in my reply that one could run a secure sendmail on a dedicated system and pull much of the information about the spammer tests from the logs (source IP and dropbox address.) Spammers could stop testing those, too. Pretty soon the spammers run out of IPs to test, and if they are looking for NEW open relays they have to test IPs that they don't know about or give up. Honeypots can be waiting at some of those new IPs. And, be honest, if spammer A finds a honeypot will he tell spammer B that it is (a) a honeypot or (b) an open relay?

What you propose has been anticipated, is the first thing I looked for when I first collected spam. I've discussed that topic with someone else in this list long ago and we agreed on how sneakily the spammer could do the tests. So far no test I've received has shown the sneakiness. Fred Woods has worked on a database for spammed addresses, so that if your test idea worked for the spammer he'd have to create a new throwaway for each test. It wouldn't do for him to send the tests to random names in his own captive domain - that would be detected very quickly. First, though, the spammers have to get smart enough to do these things for there to be reports of success in defeating the evasion.

Energy has already been spent implementing honeypots and everyone who reports results reports positive results. I think I have the worst results of anyone in terms of captured spam. Not too surprising when you recognize that I don't deliver most relay tests. I propose no change in any protocol, nothing that requires any email operator to do anything different, nothing that requires MTAs to be changed in any way. That in itself makes this a very good solution, if its benefits are adequate. That means it can be implemented quickly, that means there is no lag in its effectiveness due to reticence or neglect on the par of email operators. It works from day one. The more honeypots there are the greater the effect of its working. When the effect is great enough to cause significant spammer grief then yes, I also anticipate evasion. None of that evasion will be secret - they have to show exactly what they are doing.

It is also possible that they'll go with dedicated Trojan Horse relays, as some are already using. That's a different kind of abuse, that will take a different effort. Must I also solve that problem for honeypots to be considered? If the honeypots aren't done it doesn't matter - the spammers will have open relays and open proxies to abuse - who need the Trojan Horses? If it's a technical solution that is wanted then the effort better be quick or the DMA will get a law through Congress that makes the technical solutions irrelevant. (Maybe I'm wrong, but maybe I'm right.)

My larger objection is that you say to reject the entire idea based on postulated defeat of one aspect of one implementation of the idea. It is a very good idea, one it is (and has been) foolish to ignore. Starkly stated, the choice is to allow the spammers to commit abuse with nothing done to stop them or to act to stop the abuse. The current choice, for most, is to allow the spammers to commit the abuse. No matter how it is rationalized that is a bad choice, that is the wrong choice. Where's the good idea in ASRG to make mine unnecessary? Nowhere - you are spinning your wheels.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg