[SpamCop.net - protecting the internet through technology]

[SC-Help] Re: Problem reporting spam

Mike Easter MikeE at ster.invalid
Sun Sep 25 22:24:55 EDT 2005


Borgholio wrote:

> Here's an update.  I was able to pull up the tracking ID of the spam
> report that's causing SC to timeout.
>
www.spamcop.net/sc?id=z809243932zb1fda793746d0cf1222873a16804498az

To me, that is a design flaw in the parser.  I can imagine a number of
different configurations which would be better than that item jamming up
the works.

My favorite choice would be that the parser provides an option to not
even notify the spamvertisers, so the parser doesn't even have to
resolve anything.

My next favorite choice would be that the parser doesn't spend too much
time trying to resolve some things which it shouldn't.  Namely, this
picture is ridiculous:

>>
Resolving link obfuscation
http://deilmabcjf.yellowbring.info/?ghkfxwonoydeilmzlvabcj
   host deilmabcjf.yellowbring.info (checking ip) ip not found ;
deilmabcjf.yellowbring.info discarded as fake.
http://cfbejahkm.animeu.biz/?dgilahkmxwonoycfzsvbej
   host cfbejahkm.animeu.biz (checking ip) ip not found ;
cfbejahkm.animeu.biz discarded as fake.
http://bgjacelfim.fanglendy.biz/?dhkfimxwonoybgjzsvacel
   host bgjacelfim.fanglendy.biz (checking ip) ip not found ;
bgjacelfim.fanglendy.biz discarded as fake.
http://dijmaefglbhk.beachbox.info/?cbhkxwonoydijmzvpaefgl
   host dijmaefglbhk.beachbox.info (checking ip) ip not found ;
dijmaefglbhk.beachbox.info discarded as fake.
http://ahlmbcegdj.narcosis.info/?fikdjxwonoyahlmzvpbceg
   host ahlmbcegdj.narcosis.info (checking ip) ip not found ;
ahlmbcegdj.narcosis.info discarded as fake.
http://fghjblce.beachbox.info/?adikmcexwonoyfghjzlvbl
   host fghjblce.beachbox.info (checking ip) ip not found ;
fghjblce.beachbox.info discarded as fake.

Tracking link:
http://deilmabcjf.yellowbring.info/?ghkfxwonoydeilmzlvabcj
[report history]

Cannot resolve
http://deilmabcjf.yellowbring.info/?ghkfxwonoydeilmzlvabcj
Tracking link: http://bgjacelfim.fanglendy.biz/?dhkfimxwonoybgjzsvacel
[report history]

Cannot resolve http://bgjacelfim.fanglendy.biz/?dhkfimxwonoybgjzsvacel
Tracking link: http://cfbejahkm.animeu.biz/?dgilahkmxwonoycfzsvbej
[report history]

Cannot resolve http://cfbejahkm.animeu.biz/?dgilahkmxwonoycfzsvbej
Tracking link: http://fghjblce.beachbox.info/?adikmcexwonoyfghjzlvbl
[report history]

Cannot resolve http://fghjblce.beachbox.info/?adikmcexwonoyfghjzlvbl
Tracking link: http://dijmaefglbhk.beachbox.info/?cbhkxwonoydijmzvpaefgl
[report history]

Cannot resolve http://dijmaefglbhk.beachbox.info/?cbhkxwonoydijmzvpaefgl
Tracking link: http://ahlmbcegdj.narcosis.info/?fikdjxwonoyahlmzvpbceg
[report history]

got sigalarm, taking too long to process, aborted.
Perhaps you can wait a few minutes and reload?
>>

IMO the reporter should be able to report all of those links to the
statistics page only, which doesn't require time or resolution.

But, aside from my opinion about how the parser should provide different
options than it currently does, the other issue is that the parser has a
configuration by which it 'bails' on trying to resolve anything.  So, if
it is so 'designed' to bail on trying to resolve some things and not
even bother, why would it spend so much time trying to resolve
deobfuscated link after deobfuscated link all the way to a sig alarm,
when it should have bailed a lot earlier.  I don't understand that
design.

Incidentally, not that it matters, but each of those names resolves
'promptly' for me

deilmabcjf.yellowbring.info = 222.122.52.115
bgjacelfim.fanglendy.biz = 222.122.52.115
cfbejahkm.animeu.biz = 222.122.52.115
fghjblce.beachbox.info = 222.122.52.115
dijmaefglbhk.beachbox.info = 222.122.52.115

It isn't spamcop's fault that its resolver might be blocked, but it is
SC's fault that it barfs and hangs up everything.

According to dnsstuff, the time to resolve one of those by something
which isn't the SC resolver is less than half a second, so why should SC
spend too much time?  Either it should bail on trying to resolve sooner
or 'something'.  That is, the dnsstuff timing report isn't good, but it
also isn't horrible for a non-SC resolution.

I think the parser should be configured to 'discover' that "I think my
resolver is being blocked, I think I'm going to bail on trying to
resolve any of this spam's links."

But most of all I think that the reporter should be able to choose that
s/he doesn't want any resolution, s/he just wants to put the url on the
statistics page and there is no resolution or gagging or expenditure of
resources necessary to do that.


-- 
Mike Easter
kibitzer, not SC admin



More information about the SpamCop-Help mailing list