[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Asrg] Collaborative real time spam blocking
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.org
https://www1.ietf.org/mailman/listinfo/asrg