Created attachment 3650 [details]
Sample mail that disguises a .exe file using an audio content type

(In reply to comment #0)

the original code before I made my change is actually

foreach my $p ($pms->{msg}->find_parts(qr/^(application|text)\b/)

> spammers seem to know that can can avoid check_microsoft_executable in the AntiVirus.pm plugin if 
> they use a non-sensicle content type when attaching executable code. the plugin is too specific 
about 
> what content-types it checks and for this check I don't see why you cannot check all types.
> 
> Instead of 
> 
> foreach my $p ($pms->{msg}->find_parts(qr/^(application|text|audio|image)\b/)
> 
> I prefer
> 
> foreach my $p ($pms->{msg}->find_parts(qr/^\w+\b/))
> 
> or alternatively don't use find just use the parts list all together and check all parts.
> 
> check_microsoft_executable and it's use in determining if a message is spam or not does not really 
> relate to virus checkers and so this all could be performed outside of the context of "virus checking" 
> some people might want the rule to indicate spam whilst others simply don't care especially those 
using 
> windows so consider making the set of content types to check configurable thru user_prefs

I'm tempted to close this as WFM.  The "AntiVirus" plugin is meant to mostly
show that it's possible, not necessarily to catch viruses.  I'm also tempted to
move it to contrib or the wiki.

I don't want to go down the rathole of trying to keep up with virus writers in
addition to spammers.

Thoughts?

This in fact had nothing to do with whether or not the file has a virus. All I 
was saying was that the code that fires the rule doesn't handle .exe files 
correctly when the content type has been disguised as is evident from the 
original included sample email.

On a mac I simply do not care for messages that have .exe attachments so I 
simply want to know when a message has such an attatchment virus or not and I 
will bin the email. 

The point is simply that you shouldn't make assumptions about what content type 
is used when a .exe attachment is included.

IIRC there was great woe and gnashing of gums when the original rule was 
removed from the core ruleset.  While I haven't used it much recently, I still 
believe it is a valid test for SA to implement.  As others point out, this has 
little to do with whether the mail is a virus or not - this is a content type 
indicator that can be used (usually with a meta) to detect some kinds of spam.  
And yes, some kinds of virui.

Lacking the test moving back into the core rules, I;d at least like to see the 
plugin remain in the standard distribution.  It might be nice if it was updated 
along the lines of the suggested patch line.  But even lacking that it is 
worthwhile as-is.

> This in fact had nothing to do with whether or not the file has a virus.

Yes and no.  The code just looks for something that's an exe, regardless of
being a virus, but that's more of a virus-scanning thing than a spam-scanning
thing, hence the name of the plugin.

> All I was saying was that the code that fires the rule doesn't handle .exe files 
correctly when the content type has been disguised as is evident from the 
original included sample email.

Right.  I understand your issue.  My POV is that the plugin is really available
as an example of what can be done with a plugin, so I don't want to "waste" time
working on it.

That said, I'll put up a little patch in a minute which I think does the right
thing -- ignore the content-type, and look only at leaf nodes in the tree.

Created attachment 3764 [details]
suggested patch

As committed to 3.2:

Sending        lib/Mail/SpamAssassin/Plugin/AntiVirus.pm
Transmitting file data .
Committed revision 483138.

+1 (although I really would prefer not to have to do another 3.1.x ;)

+1

[dos@FC5-VPC 3.1]$ svn ci -m "bug 5052: update AntiVirus plugin to ignore
content-type when looking for exe files"
Sending        lib/Mail/SpamAssassin/Plugin/AntiVirus.pm
Transmitting file data .
Committed revision 485837.