[spam-stopper] 404 to spam!

ruben at lingo.com.mx ruben at lingo.com.mx
Sun Apr 22 04:58:46 UTC 2007


> <quote who="Rubén Marrero" date="Fri, Apr 20, 2007 at 07:34:17PM -0500">
>> I could hack my Akismet install to update the DB as soon as it has
>> received a response from the central server, but I thought that maybe
>> this feature could be discussed and maybe integrated into the main
>> devel line of this plugin. What do you think?
>
> I think this would be a bad idea. This type of IP blocking is both
> over-broad and under-broad and the reason I Akismet is interesting to me
> is because it is content based as opposed to originator based.
>
> Very frequently, machines that spam are badware infected computers are
> being used by spammers as proxies. Often, those computers will be fixed
> later.  Then there are dynamic IP ranges or shared IP blocks with NAT.
>
> It's bad enough when your IP is flagged and you have to moderate a
> comment before it's posted. In your system, people are never given that
> option chance.  There's no moderation queue or even an option for one.
>
> If it works for you, that's great. But the price of the false positives
> from an IP-based addition to Akimset like the one that you suggest is
> far too high for me to be comfortable with.

The real risk is that when a legitimate user from the umpteen infected
machines that bombard your blog tries to *post* (not read, just post) she
gets a 404. I'll share with everyone on this list the IP addresses that
I've collected, you might check them with the IPs flagged as legitimate
comments, and if shows that I have a percentage of your comments' IPs,
I'll stand corrected and apologize :-)

My guess is that not one of the umpteen IP's that I have collected has
ever posted a single legitimate comment on a WP blog.

Maybe Akismet could take a step further and at least temporarily block
IP's for posting I don't see the harm on that.

>
> I also have run into performance problems on Vservers. My solution was
> to buy server space from someone who did not overload their hosts.
>
On my case, dropping the HTTP transaction even before PHP got started did
the trick.

> Regards,
> Mako
>
> --
> Benjamin Mako Hill
> mako at atdot.cc
> http://mako.cc/
>
Best
Rubén



More information about the spam-stopper mailing list