Re: Why doesn't spamcop find the obvious HTML links in this spam
g.hyde at bigpond.net.au
Sun Feb 12 10:23:11 EST 2006
"Mike Easter" <MikeE at ster.invalid> wrote in message
news:dslrrd$h3m$1 at news.spamcop.net...
> Geoffrey Hyde wrote:
>> These do not appear obsfucated, or in any way obstructed, and I'd
>> think SC would certainly have picked them up on a plaintext parse
>> which it tried, and failed to detect them.
> When SC parsed that tracker for me, it found the link and failed to
> resolve it.
That was the odd thing for me, it was a fairly short parse, but it never
found the links or even tried to find the links. It just did both the HTML
and text parses without even finding the links. Which was decidedly odd
behaviour for SC.
> Finding links in message body
> Resolving link obfuscation
> Host violandera.com (checking ip) IP not found ; violandera.com
> discarded as fake.
> Tracking link: http://violandera.com/
> [report history]
> Cannot resolve http://violandera.com/
>> Can anyone tell me how the spammer is obsfucating the links so SC
>> doesn't parse them?
> When SC finds links, it can decline to try to resolve them, or it can
> try to resolve them and fail.
That was my problem, SC didn't even find the links.
> IMO I think the reporter should have the option to notify a devnull
> address for any/every link found, instead of SC trying to resolve and
> not notifying anything and also failing to feed the spamvertised link to
> the stats page or the sc-surbl.
It should tell me if it found an error that prevented it from finding a link
(system busy, whatever) I suspect perhaps it had a little too much server
load to handle when I submitted this spam for tracking.
> If there are IBs, the reporter would uncheck the devnull. SC resources
> would be conserved instead of spending any time trying to resolve
> something. The SC reporter would be 'protected' from providing spam
> evidence to blackhat spamvertiser providers and their cohorts, and the
> reporter would be 'declining' to notify the spamvertiser provider.
Not sure what you mean by "IB" but if you mean more than one provider, I'd
guess that is what should probably happen.
> All of the 'good guys' would be better off and the bad guys would be
> both 'foiled' and contributed to a minor blocklist functionality better,
> namely the sc-surbl. Currently SC resources are being 'wasted' in
> trying to resolve spamvertiser IPs and blackhats are being aided with
> the SC functions of notifying.
And if someone is an unknown or whitehat provider, should this also apply to
them? It does sound a bit one-sided to me.
> Bad configuration. Needs to be updated.
> Those 'advanced' spamfighters who can tell the blackhats from the
> whitehat spamvertiser providers can also option to notify in the current
> 'old fashioned' way in the event of a whitehat provider.
I guess so but what do you do with the unknown borderline cases? Or those
that are simply totally unresponsive? I don't necessarily agree that an ISP
should get lumped in with blackhats just because they're unresponsive - it
may be that they're understaffed or don't understand the problem. That is
not necessarily reason to blackhat label them.
> Incidentally, violandera.com resolves to 184.108.40.206 which is a
> blackhat .cn provider for Leo BadCow Kuvayev SBL36758
Heh - I might have known it was him.
> ... so you wouldn't want to be notifying that anyway -- but by my idea
> of a new improved spamcop parser option, you could have been putting
> that spamvertiser on the stats list and feeding it to sc-surbl.
Would he even care about being notified? It sounds to me like the only
thing that will shut Leo up is a total lack of internet connectivity or the
IP addess allocation providers get sick and tired of him.
It would be nice if your suggested improvements get approval, but I think
there are still unresolved issues that need working out.
More information about the SpamCop-List