Bug 7937 - T_DOC_ATTACH_NO_EXT flaw in logic?
Summary: T_DOC_ATTACH_NO_EXT flaw in logic?
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-21 00:27 UTC by Alek
Modified: 2021-10-21 04:01 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alek 2021-10-21 00:27:11 UTC 
Hey there

We are seeing a high rate of detections against the T_DOC_ATTACH_NO_EXT test which looks like so

T_DOC_ATTACH_NO_EXT   __ATTACH_NAME_NO_EXT && (__PDF_ATTACH || __DOC_ATTACH_MT)

The logic here I don't think is quite right its saying: 

If there is no attachment extension AND its a PDF or Document - then fire

However, the behavior we are seeing in production is:

There is an email with multiple attachments say 5 attachments
4 images (thanks email signatures :( ) with no extensions and 1 PDF file
The test is triggering because the image files don't have a extension. 

I believe the logic should be: 
(__ATTACH_NAME_NO_EXT && (__PDF_ATTACH || __DOC_ATTACH_MT))
To tie the missing extension to the detection of the PDF and Document clause. 

I don't know the logic well enough to confirm if this is legal in the language but.
Comment 1 Bill Cole 2021-10-21 04:01:39 UTC 
There is no way to bind the 3 detections to the same attachment. The addition of parentheses would have no effect. 

Because the rule is a test rule (name begins with T_) it scores a meaningless 0.01 by default, and because it has not proven to be useful in the rule QA process it is not being rescored into relevance. 

As the score is too low to be causing misclassifications, I don't see any compelling reason to remove the rule.