Subject: Re: [asrg] 6. proposal of solution: Using Relay Honeypots to Reduce Spam

From: "John Fenley" <[email-masked]>
Date: Tue, 15 Apr 2003 14:48:43 -0600

>From: Brad Spencer <[email-masked]>
>Subject: [asrg] 6. proposal of solution: Using Relay Honeypots to  Reduce 
>Spam

[I cut tons of stuff out of this whole thing]

>ASRG can anticipate that some spammers, at least for a while, will resist 
>the effort to end spam and will attempt to overcome the ASRG methods.  
>While the ASRG proposal should be comprehensive enough to anticipate such 
>moves the details of such moves cannot be anticipated.

There are current ways to defeat honeypots.

1. using a test address to detect honeypots.(there are an infinite number of 
addresses available, they will not run out.)

2. unless you can convince the whole world that these are good, using ip to 
determine geographical locations where honeypots are scarce.

3. send even more spam through the real open relays.

and As you mention:
4. send spam directly

>The first analysis of spam is easy: spam has two types, direct, and 
>non-direct.  Direct spam should be completely controllable by use of block 
>lists, at least direct spam from spam-only sources.

Blocklists don't work. Again, there are an infinite number of email 
addresses for spammers to use.

A spammer could buy a domain, and do a mailing using real begginning 
addresses with their real domain endings. each unique address would only be 
used once. everyone would have to block every address in that spammers list, 
untill it is RBLed, and by that time the dammage is done. the spammer can 
just buy another domain.

>The long-term ASRG plan may include a replacement or strengthening of the 
>SMTP protocol.  What ASRG does need not be limited to a single action.  
>Protocol enhancement may be the key part of the ASRG plan but the current 
>intense level of spam calls for immediate action yo substantially reduce 
>the amount of spam that reaches all users, as a whole.

A revision to the SMTP protocall would eliminate the need for honeypots 
altogether. The problem is adoption. a new protocall will not be adopted if 
there is not an advantage to every user of the new protocall.

Senders will not upgrade unless they see an advantage to doing it.
Mail programs will not support it unless people are sending, using it. In 
any case you will still have to recieve regular smtp mail untill the change 
is complete.

There is only one case I know of where change like this has happened. Sweden 
changed from driving on the left to driving on the right, one morning 
(September 3, 1967 I think), after a major advertising camaign 
(obviously)backed by their government. They made the change in the middle of 
the week to avoid people getting up to go to work on monday and having a 
"Mannic Monday" because they forgot.

Oh yeah, our (american) tv signals are changing to digital, in a plan backed 
by our government. I think the deadline is 2008?

Also the Euro.

These plans were not spur of the moment plans. They took years of effort to 
formulate and pass. This is what is needed if the system is not self 
adopting, and backward compatable. (color tv was like this... a Black & 
White tv could display color signals, just not the color.)

>Whether or not the abuse meets the federal standard for action the abuse 
>[from spammers]is theft of service.

If I set up a table on a hot day in a crowded place with no sign, put 
glasses of liquid on it, and people drink the liquid, are they stealing the 
liquid from me?
likewise if the liquid turns out to be poison, am I responsible? I didn't 
tell them to drink it...
What do you think a court would say?

>Honeypots, in this context, are systems set up to appear to the spammer to 
>be vulnerable to abuse but not be vulnerable - some key part of the abuse 
>is intercepted, usually delivery of spam.

>The real power of honeypots comes when they exist in large numbers...

The number of honeypots does not effect the validity of the workarounds 
mentioned earlier.

>RFC 2505 says that securing open relays is not an approach to ending spam.  
>The reason is that spammers will continue to discover open relays, so that 
>even a 95% success in securing open relays won't stop spam.  The key word 
>is discover: the problem is that spammers can discover open relays.  Anyone 
>can: try to relay an email message through a million IPs and you'll find 
>some that will.

RFC 2505 also says:
      "The Non-Relay rules are not in themselves enough to stop spam.
       Even if 99% of the SMTP MTAs implemented them from Day 1,
       spammers would still find the remaining 1% and use them. Or
       spammers would just switch gear and connect directly to each and
       every recipient host; that will be to a higher cost for the
       spammer, but is still quite likely."

Honeypots are not the solution. There are much more prommising Ideas out 
there.

>To really disrupt the spammers may take a number of honeypots equal to or 
>greater than the number of open relays.  If the numbers were equal then the 
>honeypots would be expected to be receiving roughly half the spam, a 50% 
>cut in spam volume.  At that level the spammers need only double their 
>output to keep the same delivery level.  (Someday the headroom for 
>increasing volume will run out - then nothing the spammers can do will keep 
>up the volume.)

Does Moore's Law apply to Bandwidth? mine sure has been going up.
I've heard tell of "A fiber to every room". Maybe that will be part of my 
2016 campaign if it hasn't already happened by then.
I sure hope spam isn't still around in 2016.

>The prime countermeasure a spammer can take is to stop sending spam to the 
>honeypot, once he discovers it is a honeypot.

The best possible course of action for the spammer is to hack through your 
simple security, and turn your "honeypot" into a "zombie cash cow".

>If the spammer sends spam to his own address then he probably will use that 
>same address multiple times.

Not if that is what you are depending on.
random bot generated free addresses used only for 3 or so runs.

I am only half way through this thing.
I'm sorry.
I realy tried to see your logic, I feel dumber now.
I have read every message on this list since I got here, but I will not 
continue to read this one. You have not addressed the problems.
You are "Beating a Dead Horse to Death".

Please use some logic. Please try to solve the problems we are telling you 
about before posting another behemoth like this one.
I can never get that hour back.

John Fenley

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Spencer <[email-masked]>
Date: Wed, 16 Apr 2003 05:58:15 -0500

At 02:48 PM 4/15/2003 -0600, John Fenley wrote:
>1. using a test address to detect honeypots.(there are an infinite number 
>of addresses available, they will not run out.)

Prove that.

You cannot.

If you do the simplest analysis you will see the flaw in what you say.

You make an assumption that isn't true or should not be true.  Your 
objection depends on that assumption.

If freemail providers filter against spam then there is a second mechanism 
by which the spammers will not see the tests they send to their plethora of 
dropbox addresses.  How does the spammer distinguish between not receiving 
the spam because it was trapped by a honeypot and because it was blocked by 
the freemail provider?

Only if the freemail provider tells the spammer the spam was blocked does 
the spammer know.  Even if the freemail provider does that a collaboration 
between the honeypot operator and the freemail provider leaves the spammer 
uninformed.