At 03:40 PM 4/8/2003 -0400, you wrote:
You have an idea.
That's what I am presenting. In engineering the idea precedes
implementation. I deliberately don't describe implementation - why is that
such a problem? You configure something to accept relay email messages,
you do something to recognize spammer relay tests, you deliver those. I
tell one way to recognize tests: one's IP is in the tests very often,
plaintext or encoded. I tell how they are encoded. If you trap relay
email the chances are nearly 100% that the first email you trap is a relay
test. What does it look like? It might be different from any yet
seen. Does it or doesn't it have the tested IP in it someplace?
Different people are familiar with different MTA's. Chances are most MTA's
can be configured (on a separate system) to be honeypots. The IDEA works
for all MTAs - giving details of how I do it (ancient, free, unavailable
PMDF) would be useless to anyone. People can run Jackpot - I gave the URL
for that. Most Windows systems can be open relay honeypots. Some can't -
there's no particular need to enumerate those.
Honeypots are a single-system-level approach to dealing with the relay
tests sent by spammers. ISPs can do network-level actions against the
abuse. Yes, some legitimate traffic will be similar to spammer traffic - I
don't recommend "sound shots." Once the ISP is convinced a source of
activity is a spammer the ISP can then act.
I never thought of adding a web server to the honeypot - Michael Tokarev
did. If he had just done what I did he'd have had a far weaker tool than
what he devised himself. There's good reason to leave off implementation
details - innovation comes form going beyond what has already been done.
I've also sent a draft to Paul Judge of my response to his suggestions for
how to propose honeypots. I don't think he'll like it - it isn't as
detailed (I imagine) as he'd want it to be. I am working in that direction
but there's really no need to wait for that post.
I'm sorry if I'm brittle but you must understand I had two years of
quibbles in NANAE and I'm not going to go that route any longer.
Here's an IDEA. Examine it. It has great power to stop a huge portion of
today's spam. Assume I've overlooked something even more powerful than a
web server - add to the idea. That's what engineering is, is it not?
Actually, it's two ideas. (1) Act at the relay level (including the proxy
level.) (2) Do it at a huge number of IPs, quickly. You should see why
the "quickly" part of (2) is a powerful idea against countermeasures.
I have not described all that might be possible using a
honeypot. Obviously you can end up with fresh spam and all you can do
against received spam can be done against that. It may contain variable
data, such as reply-to addresses, that you can collect and report in one
bunch to the provider of those reply-to addresses (almost surely a freemail
provider.) You can accomplish things against the spammers that will
mystify them if they don't know about honeypots - they aren't used to that
level of defense, don't understand their vulnerability. That is part of
the power. Honeypots are two years overdue. It's time to move on them.
Implied, I think, in your post is an assessment that says I am
flawed. Boy, am I. Take the idea and run - leave me behind. ASRG doesn't
care, at any particular level, how flawed I am. It's the idea that
matters. Go with the idea.
Thanks for your interest - I do appreciate your posts.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg