Re: Problem reporting spam
"Mike Easter" <[email protected]>
| Newsgroups | gmane.mail.spam.spamcop.help,gmane.spam.detected |
|---|---|
| Organization | SpamCop |
| Message-ID | <[email protected]> |
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