Martin Gregorie wrote:
On Wed, 2009-05-06 at 02:08 +0100, Ned Slider wrote:
I had one sneak through today which didn't hit any rules at all (it hits
a few DNSBLs now but not when I received it). It contained an inline png:
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline
here's the full message:
http://pastebin.com/m608defa5
Any idea how to tackle these? I have the DSCxxxx png rule in place but
obviously that doesn't apply to this example.
Perhaps I need a rule for "Content-Type: image/png" too?
This works for me:
describe MG_NONAME Image with no filename
mimeheader __MG_NON1 Content-Type =~ /image\/(png|gif)/i
mimeheader __MG_NON2 Content-Type !~ /name\=/i
meta MG_NONAME (__MG_NON1 && __MG_NON2)
score MG_NONAME 1.5
If you want a more bullet-proof rule, don't overlook the two sex terms
in the subject line: write a rule that fires on that sort of stuff in
the subject and combine it with the two image rules in a meta that looks
something like this:
meta IMAGE_SPAM ( SEX_SUBJECT && ( MG_NONAME || FAKE_PHOTO ))
where FAKE_PHOTO represents your DSCnnn.png detection rule.
Martin
Thanks everyone :)
Here's what I have to test with so far using a combination of the
suggestions:
# image has no name
mimeheader __LOCAL_IMAGE_NONAME Content-Type !~ /name\=/
meta LOCAL_IMAGE_SPAM ((__HTML_IMG_ONLY || __DC_IMG_HTML_RATIO ||
__DC_IMG_TEXT_RATIO || __LOCAL_IMAGE_NONAME) && (__PNG_ATTACH_1 ||
__GIF_ATTACH_1))
which might be a little aggressive but should hopefully hit on most
variants of these for the time being.
This particular example hits on __DC_IMG_TEXT_RATIO,
__LOCAL_IMAGE_NONAME and __PNG_ATTACH_1 triggering the meta rule.
