[SpamCop-List] Re: Why doesn't spamcop find the obvious HTML links in this spam email?

[Geoffrey Hyde]

"Mike Easter" <MikeE at ster.invalid> wrote in message 
news:dslrrd$h3m$1 at news.spamcop.net...
> Geoffrey Hyde wrote:
> www.spamcop.net/sc?id=z873291386zddad65b735462367ccf2ad0309a7349dz
>>
>> 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
>   http://violandera.com/
>   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 220.231.20.231 which is a
> blackhat .cn provider for Leo BadCow Kuvayev SBL36758
> http://www.spamhaus.org/SBL/sbl.lasso?query=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.


Cheers ...

Geoffrey Hyde