-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Rudd wrote: > > On Aug 21, 2006, at 10:13 PM, Chip M. wrote: > >> While skimming thru my daily rejected spam pile, did a double take >> when a >> GIF spam seemed to "blink" at me. Thought it was a sw glitch at >> first... >> then realized the sneaky Borg had adapted again. >> >> Took a look at the frames in PaintShopPro's AnimationShop, and the >> first >> three are all but blank (wee bit of noise), followed by the payload. >> >> Below are links to the raw message, and the extracted GIF: >> http://Puffin.net/software/spam/samples/0001a_animated_gif.eml >> http://Puffin.net/software/spam/samples/0001b_been.gif >> >> Decoder/Chris, I'd view this as a compliment to your FuzzyOCR. ;) I'll implement that in the next release :) thx :D >> >> The good news is that ImageInfo should have no problem with this >> particular >> instance, as the initial width x height are "correct". >> >> Time to recalibrate those phaser frequencies! :) >> - "Chip" >> > > I also heard that interlaced gif spam is appearing now. This will be supported then, too. Not a big deal:) > > It'd be interesting to see how to counter them. > > For animated, is there a clean break between "frames" of animation, > something that netpbm or whatever can easily identify and break out > into individual images? It would be CPU intensive, but the right > way to fight it might be to run the FuzzyOCR on each frame. And/or > have a setting for "maximum frames to process", and if the GIF goes > over that number of frames, give it a huge spam score. Or "add this > score per frame", so that the number of frames increases the spam > score directly, and automatically bail out if they cross a certain > threshold (score from number of animation frames alone >= 20, then > just return 20 ... or something; which saves you on processing the > frames themselves). Sounds good :) But there might be a better way... but I'm not sure atm, got to read up on it in the netpbm manual first:) > > For interlaced ... I have no idea. Depends a lot on how the > interlaced images are stored, I guess. And whether or not netpbm > can generate the final image for processing, instead of having to > work on the interlaced data. > > >
Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE6rlvJQIKXnJyDxURAg8iAKCnQkgGNY/o+iJDf+WG0KSisyi32QCeJ8zR DfefnLEv8Tkow0O6HhbieLs= =lj4i -----END PGP SIGNATURE-----
