At 08:29 AM 4/16/2003 -0600, Vernon Schryver wrote:
It does not matter whether spammers are doing the obvious and including
undetectable drop-boxes in their spews. (It is obviously impossible
for a honeypot operator to distinguish or detect one address that gets
a copy of every spam sent by a relay spammer and is monitored by the
spammer from every other address that gets a copy of every spam sent.)
The honeypot operator isn't the only person who can act usefully. The
operator of the system to which the test spam is sent can, by implementing
anti-spam filters, greatly destroy the power of this spammer ploy. If the
spammer response is to send the spam to his own domain (as some do for
their test messages) it's trivial to make sure that domain gets all the
spam the spammer sends to himself (once you know the spammers' domains.)
What matters is that honeypots that don't deliver spam to victims
don't get used by spammers, while honeypots that do deliver spam are
no better than Spamfords paid "Bandwidth Partners" and must be treated
like the spammers they are.
My original honeypot did sometimes leak spam. Mea Culpa. I now run it
with all delivery disabled and sometimes deliver a relay test
manually. It now does not and cannot leak spam. I run Jackpot at home
with relay disabled. It does not and cannot leak spam, not even one. It
does trap relay tests every once in a while. The "work" honeypot was up to
333 tests this year last time I checked. Many of those are repeat
tests. With only one trap I can't say anything about the testing pattern
that the tests represent (and I think the testing patterns are tremendously
important to know.). I do know some spammers differently from how most
do. I know a jela(_at_)borovo(_dot_)net spammer - he's the one that sent three
intermingled types of relay spam, through open proxies, and sometimes
screwed up (put the "Meet Russian Women" subjects with a different
spam.) That's another way I know spammers differently from most: I see
more of a complete spam run than is usual. If there were larger numbers of
honeypots and if the operators were doing what I started to do with the
"work" honeypot - let test messages be delivered only to one drop box -
then there'd be a good body of formation possible that would link a test
dropbox address with a particular flavor of spam. If the dropboxes were
not done under fictitious names (and some have very long histories, so the
spammers may not realize the vulnerability) then a subpoena could be issued
to link the spam back through the dropbox that received a test message and
triggered that spam to the name of the spammer. The AOL suit could have a
lot of the "John Doe's" filled in with real names.
However, since the topic has come up, there are honeypot schemes in which
some spam is delivered. I will point out the inconsistency of opposition
to those, using securing of open relays as the starting point. When an
open relay is secured then that particular IP is no longer a source of
spam. As generally done the securing results in the IP responding "550 we
do not relay" to any relay attempts. That is all the information the
spammer needs and it is given to him for free. That preserves the strict
dichotomy on the internet: systems that don't relay spammer test messages
and aren't open relays and systems that do deliver spammer test messages
and are open relays. The act of securing the system makes no noticeable
effect on the volume of delivered spam. As long as the spammer can find
enough true open relays he continues to send as much relay spam as he needs
or desires.
If I created a honeypot that used some random number function to determine
which spam recipients were to get spam, and programmed it to deliver 50% of
the spam, then it would also stop 50% of the spam. That is far worse form
a single-system viewpoint but is infinitely more effective than the secured
system in actually stopping spam TODAY. Only when almost all systems are
secured does simply securing result in a lowered spam volume - that day
hasn't yet arrived. You can rail all you want about a system that delivers
half the spam it is given to deliver but it is doing more to stop spam than
a secured open relay.
That's not the only scenario. If there were a million honeypots they
could deliver 100% today, 98% tomorrow, and so on, ramping down to 0%
delivery in 50 days. This isn't likely to ever be done but, depending on
how thoroughly the spammers had switched over to these fake open relays,
the spam volume would be greatly reduced after 50 days (if the spammers
didn't scramble away from the honeypots.) I don't advocate this but I do
advocate thinking about it - the simple gut-reaction approach, appropriate
for the first day it is discovered that your system is being used to relay
spam, is no longer adequate (and thus never was.)
There was no benefit I can see to my honeypot leaking spam and I never
wanted it to leak. But it did function to end huge amounts of spam while
people with simply-secured systems did nothing comparable. It did get
listed as an open relay but that was OK: I invited ORBS to test my zone
whenever they wished. Later on it was much tighter. It also functioned by
delivering all single-recipient messages (for convenience in
implementation, not for any necessity.) After it was shut down
single-recipient relay spam got far more prevalent. It would have been
trivial to change it so that it checked all messages. Even for
single-recipient spam it checked for relay tests, so I could save
copies. MAPS listed it because I described it in NANAE. Again, no problem.
If you remember nothing else from this message remember the folly of giving
the spammer for free the piece of information he most needs about a secured
system to enable him to keep sending relay spam: the fact that it is secured.
I've not really thought through all the implications of open proxy
honeypots - there may be some great ideas there that haven't yet been
touched. That's where the action is now - open proxies.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg