John Andersen wrote: > On Sunday 10 December 2006 04:09, Santiago Vila wrote: >> the image is also created with randomness in it (so I think razor >> is not very effective with it). > > The image is usually not really randomized (that would require > too much work), but is randomly corrupted at the > end of the image.
Yes it is really randomized, and not just at the end. Even the font colors, size, and word wrap is randomized on a per message basis. I've repeatedly had multiple system accounts receive the "same" message at more-or-less the same time, but with a separate connection, each is really completely different. Take a close look at your image spam sometime. Make sure you're not looking at ones that were BCCed to multiple accounts at once (same SMTP ID by your MTA). As for the work involved, that's what botnets are for. Modern spammers don't use their own resources, they use stolen ones. Most of the bots are home PCs on DSL/Cable networks. These machines usually have more spare CPU than upstream bandwidth to send with, so the CPU overhead really doesn't slow down the rate of spam sending. >From the looks of things the spam is sent out to the bots in some kind of quasi-html format, and the bot renders the html text into an image with slight variations in the parameters. On top of it all, older ones had random "noise dots" inserted. More recent ones use a background of random colorful geometric figures with a border of random "splotch" marks, and have the text rendered with a small random vertical offset on each character (creates a "wavy text line" effect). The geometrics and vertical offsets serve to help throw off OCRs, but also increase the randomness of the image. I just selected 94 image-rendered stock-spams dating from November 21 through today. Razor did not hit a single one of them. All that said, I don't think reporting these to Razor will really hurt, but it won't help either. I don't think Razor can be "diluted" or "poisoned" by these reports. But they're true random one-offs so they won't likely generate any hits. (or if they do, it's due to occasional collisions in the random parameters) I'd venture to guess that the Cloudmark folks are smart enough to use a purge algorithm that favors purging "one-offs" like these. Some kind of modified LRU that has a hit count bias, or LFU with time-of-last-hit bias, would be my own approach. That would inhibit any dilution/poisoning impact. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Razor-users mailing list Razor-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/razor-users
