You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2009/09/04 18:01:31 UTC

[Bug 6193] New: score NO_RELAYS same as ALL_TRUSTED

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6193

           Summary: score NO_RELAYS same as ALL_TRUSTED
           Product: Spamassassin
           Version: 3.2.5
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P5
         Component: Rules
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: stepheng+apache@gildea.com


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.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6193] score NO_RELAYS same as ALL_TRUSTED

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6193


Matt Kettler <mk...@verizon.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mkettler_sa@verizon.net




--- Comment #1 from Matt Kettler <mk...@verizon.net>  2009-09-04 18:41:12 PST ---
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)

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.