[SC-Help] Re: Problem reporting spam
MikeE at ster.invalid
Sun Sep 25 22:24:55 EDT 2005
> Here's an update. I was able to pull up the tracking ID of the spam
> report that's causing SC to timeout.
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
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
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
host deilmabcjf.yellowbring.info (checking ip) ip not found ;
deilmabcjf.yellowbring.info discarded as fake.
host cfbejahkm.animeu.biz (checking ip) ip not found ;
cfbejahkm.animeu.biz discarded as fake.
host bgjacelfim.fanglendy.biz (checking ip) ip not found ;
bgjacelfim.fanglendy.biz discarded as fake.
host dijmaefglbhk.beachbox.info (checking ip) ip not found ;
dijmaefglbhk.beachbox.info discarded as fake.
host ahlmbcegdj.narcosis.info (checking ip) ip not found ;
ahlmbcegdj.narcosis.info discarded as fake.
host fghjblce.beachbox.info (checking ip) ip not found ;
fghjblce.beachbox.info discarded as fake.
Tracking link: http://bgjacelfim.fanglendy.biz/?dhkfimxwonoybgjzsvacel
Cannot resolve http://bgjacelfim.fanglendy.biz/?dhkfimxwonoybgjzsvacel
Tracking link: http://cfbejahkm.animeu.biz/?dgilahkmxwonoycfzsvbej
Cannot resolve http://cfbejahkm.animeu.biz/?dgilahkmxwonoycfzsvbej
Tracking link: http://fghjblce.beachbox.info/?adikmcexwonoyfghjzlvbl
Cannot resolve http://fghjblce.beachbox.info/?adikmcexwonoyfghjzlvbl
Tracking link: http://dijmaefglbhk.beachbox.info/?cbhkxwonoydijmzvpaefgl
Cannot resolve http://dijmaefglbhk.beachbox.info/?cbhkxwonoydijmzvpaefgl
Tracking link: http://ahlmbcegdj.narcosis.info/?fikdjxwonoyahlmzvpbceg
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
Incidentally, not that it matters, but each of those names resolves
'promptly' for me
deilmabcjf.yellowbring.info = 126.96.36.199
bgjacelfim.fanglendy.biz = 188.8.131.52
cfbejahkm.animeu.biz = 184.108.40.206
fghjblce.beachbox.info = 220.127.116.11
dijmaefglbhk.beachbox.info = 18.104.22.168
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.
kibitzer, not SC admin
More information about the SpamCop-Help