On 22/10/04 14:28 -0400, Jim Whitescarver wrote:
Greetings,
I do not know if this is the correct forum to address this issue.
Please let me know if these issues are being addressed elsewhere. What
I am seeking is a means for coordinating a grass roots trust network for
aggressive dynamic blocking of spammer IP addresses. While there are
The best idea I have seen for this is a PGP/GPG signed post to usenet.
<snip>
All the 'experts' tell me black lists don't work any more because
spammers are moving too fast and there are too many of them. There is
no simple solution but I believe an agreesive, combined, scalable,
collaborative grass roots approach can work.
DNSBLs work. They just shouldn't be your only filters. Validating email
addresses, both syntactically and against lists of legitimate recipients,
checking for helo content, matching DNS (forward/reverse with regular
expressions), DNSBLs, sender verification.....
While I have succeeded in significantly reducing the spam load on the
machine, I cannot alone stop spam in a timely manner or impact the spam
problem in general. Every day I identify about 1500 new spammer IP
addresses. In many cases I block them immediately after receiving just
one spam. This prevents getting hundreds of spams from each address.
Nice. Join the club.
The trick is to identify a spammer IP as soon as possible and block it
as soon as possible. If this was done widely, the spammers would be out
of business. The system must agressively identify and block
spammers, but it also must be forgiving and heal as spammers move around
the net. If the incentives are there for Internet service providers to
enforce anti-spam policies to avoid being blocked, and timely blocking
can significantly reduce the profits from spamming, spam can be stopped.
The trick is to identify the spammer IP.
Spam me once, shame on you! Spam me twice, shame on me!
Trust networks are needed to avoid malicious blocking. Participants
should be able to negotiate the degree of confirmation desired before
blocking and choose trusted and untrusted sources. There need to be
Why? I choose which DNSBLs to trust, and which not to. Any DNSBL user
needs to do that.
<snip>
I also introduce the use of "honey pot" email addresses for spam
identification, which is an idea I have not seem elsewhere. However, I
don't see this as a standards issue at this point, but you may read on
if you are interested.
In email related activities, these are known as spamtraps.
Devdas Bhagat
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg