You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Jason Gauthier <jg...@lastar.com> on 2005/01/21 16:55:44 UTC

Help analyzing the determination of spam

Nice subject!

I attached a message to this email that got an incredibly low spam
score.
When I run the message through spamassassin -t it gets a spam score as I
would expect.

I know I don't have much more details, but can anyone give me ideas why?



Content analysis details:   (2.7 points, 5.0 required)

 pts rule name              description
---- ----------------------
--------------------------------------------------
-2.8 ALL_TRUSTED            Did not pass through any untrusted hosts
 0.2 HTML_IMAGE_RATIO_04    BODY: HTML has a low ratio of text to image
area
 0.0 HTML_MESSAGE           BODY: HTML included in message
 1.5 RAZOR2_CF_RANGE_51_100 BODY: Razor2 gives confidence level above
50%
                            [cf: 100]
 1.2 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts
 0.1 RAZOR2_CHECK           Listed in Razor2 (http://razor.sf.net/)
 0.5 URIBL_WS_SURBL         Contains an URL listed in the WS SURBL
blocklist
                            [URIs: powerfulquotes2.com]
 2.0 URIBL_OB_SURBL         Contains an URL listed in the OB SURBL
blocklist
                            [URIs: powerfulquotes2.com imn6.cc]

Help analyzing the determination of spam

Posted by Matt Kettler <mk...@evi-inc.com>.
At 10:55 AM 1/21/2005, Jason Gauthier wrote:
>Nice subject!
>
>I attached a message to this email that got an incredibly low spam
>score.
>When I run the message through spamassassin -t it gets a spam score as I
>would expect.
>
>I know I don't have much more details, but can anyone give me ideas why?
>
>
>
>Content analysis details:   (2.7 points, 5.0 required)
>
>  pts rule name              description
>---- ----------------------
>--------------------------------------------------
>-2.8 ALL_TRUSTED            Did not pass through any untrusted hosts

ALL_TRUSTED would be why. That REALLY should never hit for mail from the 
outside.

Usualy this is caused by having a NATed mailserver, or some other IP 
configuration that confuses the automatic trust path code.

Look into manually declaring trusted_networks in your config. Only add 
local mailservers that add Received: headers to the list of trusted hosts.

(Note: Don't try to use trusted networks as an IP based whitelist 
mechanism, it's not. Trusted here means trusted to generate non-forged 
Received: headers, and has subtle implications on a lot of rules.)