Bug 6193 - score NO_RELAYS same as ALL_TRUSTED
Summary: score NO_RELAYS same as ALL_TRUSTED
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.2.5
Hardware: All All
: P5 minor
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-04 09:01 UTC by Stephen Gildea
Modified: 2019-06-19 15:22 UTC (History)
2 users (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 Stephen Gildea 2009-09-04 09:01:30 UTC 
In my environment, NO_RELAYS should be treated as a special case of
ALL_TRUSTED.  That is, the mail came from inside, and it is not spam.
However, while ALL_TRUSTED has the useful score of -1.8, NO_RELAYS has
a -0.001 score.  I think NO_RELAYS should have the same default score
and priority as ALL_TRUSTED.

Bug 4283 suggests this minimalist score is left over from early 3.0
days.  But we are past that now; both these rules seem to work and are
the foundation of my spam filtering at work.
Comment 1 Matt Kettler 2009-09-04 18:41:12 UTC 
In most environments NO_RELAYS indicates that all the Received: headers are unparseable. Because in most environments, even internal mail gets at least one Received: header (client delivering to server, even if it's localhost-to-localhost).

The rule was created as a warning to administrators that something is tragically wrong with their mail system.

While in your setup this may be "normal" it's certainly not the case for most networks.

Clearly this is NOT a rule that should have a significant negative score.

I strongly oppose this change, as it will introduce false negatives for administrators of servers with malformed received: headers. 


Vote: -1 (opposed)
Comment 2 Henrik Krohns 2019-06-19 15:22:37 UTC 
Closing old bugs. -1 :-)