SA Bugzilla – Bug 2025
"full" tests not applied to (some) MIME bodies?
Last modified: 2004-01-24 11:46:04 UTC
In my user_prefs, I have a test for KLEZ body of the form: full KLEZ_CONTENT /TVqQAAMAAAAEAAAA/ This string occurs in the first line of application/x-msdownload, base64-encoded MIME attachment of a piece of KLEZ-infected mail. This test worked well in earlier versions of SA (when it was a rawbody test), but it doesn't work at all any more - it's as if the "full" patterns are not being run over this block of MIME base64 text. Maybe this is a feature not a bug, but the documentation suggests that "full" tests are run over every part of the raw message, regardless of whether they are binary or not. A "full" test for a string in the first (text) part of the same message does work correctly.
From 50_scores.cf: > # highly generic tests for viruses that are scored just high enough to run > > score MICROSOFT_EXECUTABLE 0.100 > score MIME_SUSPECT_NAME 0.100 The first one is exactly the same as your rule. Raise the score if you wish. Note that it's not KLEZ, but any MS executable. Does this solve your problem?
Indeed, this is a bug -- spamassassin 2.55 is skipping non-text MIME parts even in "full" tests. You can see this easily by making a rule that matches everything and running spamassassin -t -D rulesrun=255 to see what's being matched: full TESTING123 /.*/s describe TESTING123 testing 1 2 3 testing score TESTING123 123 The above rule matches the entire message. But the debug output shows that the matched string has the non-text MIME parts elided. Here's an excerpt: ... --FHh3uZg20E616qMK8 [skipped audio/x-wav attachment] --FHh3uZg20E616qMK8 [skipped application/octet-stream attachment] --FHh3uZg20E616qMK8 [skipped application/octet-stream attachment] ... To further confirm this, try a rule that matches the string "skipped". It will actually match these "[skipped ... attachment]" strings. Example: full TESTING123 /\[skipped.*\]/ describe TESTING123 testing 1 2 3 testing score TESTING123 123 debug: Ran full-text regex rule TESTING123 ======> got hit: match='[skipped audio/x-wav attachment]'
sa doesn't act on binary attachments (unless a MUA will display them as readable text, ie. they can act as a spam payload). The performance hit of applying the sa ruleset to binary attachments is huge, so we disabled it a long time ago. You're much better off using a virus scanner -- or even a procmail rule -- to do this. SA is not a virus scanner, it's a spam scanner, that's its aim. However the doco is misleading; it states that "full" applies to attachments as well. so we should fix that.
My rule doesn't need the body of the attachment to be scanned. It's enough if the mime headers for the attachment are scanned. Sure, email worms/viruses technically are something worse than spam, but there's not much practical difference, especially when you're using GNU/Linux and thus your system isn't vulnerable to the viruses anyway. Viruses are just more junk clogging up my mailbox. If mime headers could be scanned, this rule would catch most viruses that are currently around -- it used to work in SpamAssassin 2.43, but broke when I upgraded to 2.55: full IE_VULNERABILITY /Content-[Tt]ype:\s+(application.octet-stream|audio.x-midi|audio.x-wav|application.x-msdownload);\s+[Nn]ame\s*=.[^\n]+\.(exe|pif|scr|bat)/s describe IE_VULNERABILITY Exploits an IE bug score IE_VULNERABILITY 150
1) full didn't used to allow access to attachments 2) 2.70 does, at least so far. :)