4xx web page status and reports

[ankman]

I (or somebody else) seems to have Yahoo made to understand to use a scri_pt or some other automatitsm to detect spammer (basicly they use meta refresh forwarders) and today ALL spamervertised pages hosted at Geocities bring an error page that the page isn't there. Yay!

However, I always noticed Spamcop fails often to file complaints to Yahoo. Sometimes it does, somtimes not, though the spam looks about the same with an easy to parse geocities URL. while it ALWAYS works on other, like 0catch.com involved pages. Why?

But now that all Geocities' links throw a 404 if I click at a link coming from a spam mail, Spamcop does the same: sometimes wants to send reports, sometimes not.

Spamcop now should never send complaints when a link throws a 404 (I guess yesterday I also had a 301, may be Geocities is still configuring).

My question (I couldn't find an answer reading the forum) is, doesn't Spamcop check the web page status and acts accordingly?

It's also because many Spamcop users do not check if links in spam work. Neither do I all the time. So they send reports even though a spamvertised page does not exist anymore. Here Spamcop should honor a 404 and such, not to kick Yahoo's a**, since they managed to get spam off their servers.

Now if also Google could do the same with their abused Blogs, since I notice spammer's abuse them more after they have no luck at Geocities anymore. One would assume Yahoo people are smarter then those at Google.

[Farelf]

I suspect this is a matter of cached data being used - a glance at the stats pages (daily reports) will indicate volumes of inquiry that would be "over-the-top" for real-time live lookup. There is conjecture about the refresh policies and the general thought is caches are probably only updated when a user/reporter prods the update link (in the course of reviewing a "full" report) - like (from //members.spamcop.net):

[refresh/show] Cached whois for 89.111.181.25 : ivan[at]hc.ru abuse-mailbox: abuse[at]hc.ru

But ... just conjecture.

[ankman]

I suspect this is a matter of cached data being used - a glance at the stats pages (daily reports) will indicate volumes of inquiry that would be "over-the-top" for real-time live lookup. There is conjecture about the refresh policies and the general thought is caches are probably only updated when a user/reporter prods the update link (in the course of reviewing a "full" report) - like (from //members.spamcop.net):

[refresh/show] Cached whois for 89.111.181.25 : ivan[at]hc.ru abuse-mailbox: abuse[at]hc.ru

But ... just conjecture.

Would be interesting to know how long the caches last.

It's now two days that none of the Geocities links would lead to a spammer page. All pill spammer gave up and now, as predicted (wasn't hard to predict, eh? ) they abuse Google's Blogspot instead. Still one OEM spammer tries it with Geocities. I assume the spammer does not test if the Geocities account is still available when sending the spam, so all four links in spam of OEM spammers from today are dead. But in one of the four cases Spamcop created a report, so I unchecked to box.

I have an eye on this. Assuming, all Geocities links are dead by default, Spamcop's cache lasts too long if this is the problem for creating reports for 404 pages. I will post on Sunday here again if Spamcop still creates reports of 404 links by then.

NB: I gave up sending reports to Google (yes, I read the thread about Blogspot), they seems to be just ignorant and no matter how many complaints you send, Google doesn't care.

Thumbs up for Yahoo/Geocities though. It works, showing spammers abusing their service will not work for them.

[ankman]

Well it's not Sunday. But having time checking, no changes. On 404 links Spamcop still sometimes wants to create reports, while on 200 links in spam it sometimes doesn't want. Sometimes does though. It looks like pure random to me when complaints are filed, not matter what the link returns (2xx or 4xx).

[Farelf]

...It looks like pure random to me when complaints are filed, not matter what the link returns (2xx or 4xx).

Seems that must be true, reliance must be (as previously conjected) on individual reporters hitting the "refresh/show" link if they have any reason to suspect the spamvertized url's status which would be a random occurrence to all intentes and purposes. I guess the deputies might try to keep an eye on it but spamvertized sites are not their priority and high volumes fairly much rule out real-time automated checking (noting recent SC server issues seemingly confirming there's no "spare" capacity).