I to am having a similar problem, below is one of the headers.  I'm getting a 
lot of spam with ALL_TRUSTED being fired.  I'm running exim4.43+exiscan+sa3

Return-path: <bounceto-10006-1814118845@bounceto.staghug.com>
Envelope-to: lancev@interpod.net
Received: from localhost ([127.0.0.1] helo=staghug.com)
	by mail.interpod.net with smtp (Exim 4.43)
	id 1CGvNo-0007Eq-R0
	for lancev@interpod.net; Mon, 11 Oct 2004 03:18:17 -0500
Content-Type: multipart/alternative; boundary="----------=_1097462325-10565-0"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
To: <lancev@interpod.net>
Received: from img.staghug.com by staghug.com id
 <10006.288622.1814118845@staghug.com> for lancev@interpod.net;
 Mon, 11 Oct 2004 08:15:11 GMT
From: "P.T.P." <P.T.P.-replyto-10006-1814118845@lists.staghug.com>
Subject: Complimentary Computer- find out how to get it!
Date: Mon, 11 Oct 2004 08:15:11 GMT
Message-ID: <10006.288622.1814118845@staghug.com>
Errors-To: <bounceto-10006-1814118845@bounceto.staghug.com>
Reply-To: P.T.P.-replyto-288622-1814118845@lists.staghug.com
List-Unsubscribe: <http://www.staghug.com/unsub.php?id=BIBEBBIIEF5BAAAG600>,
 <mailto:P.T.P.-unsubscribe-10006@lists.staghug.com?subject=unsubscribe>
X-Spam-Score: 0.5 (/)
X-Spam-Report: Spam detection software, running on the 
system "mordor.interpod.net", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or 
label
	similar future email.  If you have any questions, see
	abuse@interpod.net for details.
	Content preview:  Do you need a laptop? Here's your chance to get one 
for
	free! http://www.staghug.com/link.php?BIBEBBIIEF5CIIGCC4IACEIH00 It's a
	New Member Incentive Promotion- Complete the program and get a
	complimentary IBM Laptop computer! [...] 
	Content analysis details:   (0.5 points, 5.0 required)
	pts rule name              description
	---- ---------------------- -------------------------------------------
-------
	0.5 FROM_ENDS_IN_NUMS      From: ends in numbers
	-2.9 ALL_TRUSTED            Did not pass through any untrusted hosts
	2.4 MARKETING_PARTNERS     BODY: Claims you registered with a partner
	0.0 EXCUSE_3               BODY: Claims you can be removed from the 
list
	0.0 EXCUSE_7               BODY: Claims you can be removed from the 
list
	0.0 HTML_80_90             BODY: Message is 80% to 90% HTML
	0.8 HTML_TEXT_AFTER_BODY   BODY: HTML contains text after BODY close 
tag
	1.1 HTML_IMAGE_RATIO_02    BODY: HTML has a low ratio of text to image 
area
	0.0 HTML_MESSAGE           BODY: HTML included in message
	0.0 HTML_TEXT_AFTER_HTML   BODY: HTML contains text after HTML close 
tag
	-1.7 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
	0.1 MIME_QP_LONG_LINE      RAW: Quoted-printable line longer than 76 
chars

I would also like to mention that I am having Interscan Viruswall loading 
exim.  viruswall scans the msg and the exim handles the rest.

Subject: Re:  ALL_TRUSTED

On Mon, Oct 11, 2004 at 01:31:22AM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> I to am having a similar problem, below is one of the headers.  I'm getting a 
> lot of spam with ALL_TRUSTED being fired.  I'm running exim4.43+exiscan+sa3

ALL_TRUSTED says that the message is received without even going through an
untrusted machine.

> Received: from localhost ([127.0.0.1] helo=staghug.com)
> 	by mail.interpod.net with smtp (Exim 4.43)
> 	id 1CGvNo-0007Eq-R0
> 	for lancev@interpod.net; Mon, 11 Oct 2004 03:18:17 -0500

This is the only usable Received header available, which specifies the message
was sent from localhost (127.0.0.1).  Therefore the message is considered
"trusted".

It looks like either exim or exiscan either isn't putting in proper Received
headers before calling SA, or the message actively came from localhost
somehow.

I think the problems are from Interscan's Viruswall, on the same machine as 
exim.  Viruswall passes the scanned message to exim, thus coming from 
localhost.  Is there a way around this, without disabling or moving Viruswall 
to another machine?  This sounds like the same problem rdzek is having with 
the AV program passing the message from within the network, then becoming 
trusted.

Subject: RE:  ALL_TRUSTED




Ray Dzek
Network Operations Supervisor
Specialized Bicycle Components
PH:  408-782-5420
FX:  408-782-5421 

-----Original Message-----
From: bugzilla-daemon@bugzilla.spamassassin.org
[mailto:bugzilla-daemon@bugzilla.spamassassin.org] 
Sent: Monday, October 11, 2004 9:46 AM
To: rdzek@pop.specialized.com
Subject: [Bug 3814] ALL_TRUSTED


http://bugzilla.spamassassin.org/show_bug.cgi?id=3814





------- Additional Comments From lancev@interpod.net  2004-10-11 09:45
------- I think the problems are from Interscan's Viruswall, on the same
machine as 
exim.  Viruswall passes the scanned message to exim, thus coming from 
localhost.  Is there a way around this, without disabling or moving
Viruswall 
to another machine?  This sounds like the same problem rdzek is having with 
the AV program passing the message from within the network, then becoming 
trusted.



------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

This header should be preventing it from being ALL_TRUSTED. Whatever is adding
this header meeds to use a proper format for Received headers.

Received: from img.staghug.com by staghug.com id
 <10006.288622.1814118845@staghug.com> for lancev@interpod.net;
 Mon, 11 Oct 2004 08:15:11 GMT

This doesn't say anything about why the originalo bug reporter is seeing this
header from comment 1 treated as trusted:

Received: from www55.bestproductcarrier.com ([83.69.178.33])
 by mail2.specialized.com (SAVSMTP 3.1.1.32) with SMTP id M2004092316462421631
 for <rdzek@specialized.com>; Thu, 23 Sep 2004 16:46:25 -0700

Does anyone have insight on that?

yeah, I don't know -- I can't repro Ray's bug.  If I paste those into a file and run

    ./spamassassin -D -Lt < tst

I get these debug lines in the output:

debug: metadata: X-Spam-Relays-Trusted:
debug: metadata: X-Spam-Relays-Untrusted: [ ip=10.1.0.22
rdns=mail2.specialized.com helo=mail2.specialized.com by=pop.specialized.com
ident= envfrom= intl=0 id=89EEC3EDC ] [ ip=83.69.178.33
rdns=www55.bestproductcarrier.com helo=www55.bestproductcarrier.com
by=mail2.specialized.com ident= envfrom= intl=0 id=M2004092316462421631 ]

in other words, the two handovers are *not* trusted.   it's possible that inside
specialized.com's network, the first one would be trusted, but that'd leave the
second one as untrusted, so it should work fine.

Ray, do you have trusted_networks or internal_networks set in your local.cf? 
can you try the command above and see what those two lines look like for you?

Sidney and Theo are right for the second mail.

--j.

I do not have trusted or internal networks defined in my local.cf  

Here is the debug header output from spamassassin -D -Lt

debug: received-header: parsed as [ ip=10.1.0.22 rdns=mail2.specialized.com helo
=mail2.specialized.com by=pop.specialized.com ident= envfrom= intl=0 id=89EEC3ED
C ]
debug: received-header: parsed as [ ip=83.69.178.33 rdns=www55.bestproductcarrie
r.com helo=www55.bestproductcarrier.com by=mail2.specialized.com ident= envfrom=
 intl=0 id=M2004092316462421631 ]
debug: is DNS available? 0
debug: received-header: 'from' 10.1.0.22 has reserved IP
debug: received-header: cannot use DNS, do not trust any hosts from here on
debug: received-header: relay 10.1.0.22 trusted? yes internal? no
debug: received-header: cannot use DNS, do not trust any hosts from here on
debug: received-header: relay 83.69.178.33 trusted? no internal? no
debug: metadata: X-Spam-Relays-Trusted: [ ip=10.1.0.22 rdns=mail2.specialized.co
m helo=mail2.specialized.com by=pop.specialized.com ident= envfrom= intl=0 id=89
EEC3EDC ]
debug: metadata: X-Spam-Relays-Untrusted: [ ip=83.69.178.33 rdns=www55.bestprodu
ctcarrier.com helo=www55.bestproductcarrier.com by=mail2.specialized.com ident=
envfrom= intl=0 id=M2004092316462421631 ]

that looks fine -- it identifies the correct trusted handover, and the correct
untrusted handover.  did it hit ALL_TRUSTED that time?

hmm, maybe some insight on this then..  here's a legit email I sent from my 
yahoo account, below are the headers, received from localhost like the 
previous header but ALL_TRUSTED was not fired.  I'm confused now.. Since my AV 
program is acting as a frontend and passing the email to exim, then it will 
always come from localhost, so then why would some emails fire ALL_TRUSTED and 
other's don't..  I'm not seeing that much of a difference in headers, alteast 
no the received from part.  The email's I get from here for bugzilla, they get 
fired with ALL_TRUSTED.... 

Return-path: <altere987@yahoo.com>
Envelope-to: lancev@interpod.net
Received: from localhost ([127.0.0.1] helo=web51909.mail.yahoo.com)
	by mail.interpod.net with smtp (Exim 4.43)
	id 1CH6p8-0001v6-0M
	for lancev@interpod.net; Mon, 11 Oct 2004 15:31:14 -0500
Message-ID: <20041011203116.59358.qmail@web51909.mail.yahoo.com>
Received: from [66.90.168.76] by web51909.mail.yahoo.com via HTTP; Mon, 11 Oct 
2004 13:31:16 PDT
Date: Mon, 11 Oct 2004 13:31:16 -0700 (PDT)
From: Lance Vavricka <altere987@yahoo.com>
Subject: test from yahoo acct
To: lancev@interpod.net
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.2 (/)
X-Spam-Report: Spam detection software, running on the 
system "mordor.interpod.net", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or 
label
	similar future email.  If you have any questions, see
	abuse@interpod.net for details.
	Content preview:  testing headers from yahoo acct. Do you Yahoo!? 
Yahoo!
	Mail Address AutoComplete - You start. We finish.
	http://promotions.yahoo.com/new_mail [...] 
	Content analysis details:   (0.2 points, 5.0 required)
	pts rule name              description
	---- ---------------------- -------------------------------------------
-------
	0.2 FROM_ENDS_IN_NUMS      From: ends in numbers

Lance, I think I see your problem. I thought that in your example in comment #1
the second Received header was added by the virus scanner and was the problem. I
see from your second example that I was wrong about that. The second Received
header is inserted by the sender, so you don't have any control over it and
don't need to. Yahoo happened to put something there with an ip address so
SpamAssassin used it, while in your first example staghug.com did not. But that
is just circumstantial.

The real problem is that the virus scanner is not inserting any Received header,
yet it is acting as an SMTP relay. Mail is received from the sending relay, in
the first case staghug.com and in the second case web51909.mail.yahoo.com, but
the virus scanner does not create a Received heder showing that. It does pass
the name of the server to Exim in the helo, but Exim just sees mail arriving via
SMTP from localhost.

This has to be a configuration problem in your installation of the Symantec AV
server.

Changing target milestone so this doesn't get lost. I don't have time to fix it
right now but the fix is too trivial to put off indefinitely.

If anybody gets around to this soon, consider putting it in 3.0.1. It's minor,
but annoying if you happen to be installing on a system that uses port 9 for the
discard service.

My suggested fix is 1) change the port to 8; 2) add a warning if the rule fails
saying that if port 8 is already in use by a service the test should be changed
to use an unused port.

Ack! I did that in the wrong window. Ignore last comment. Changing milestone
back to where it was.

for people reading this bug, you might want to read bug 3406 since ALL_TRUSTED 
is directly releated to trusted_networks.

I'm closing this WORKSFORME.   it's definitely something that needs to be fixed
in the AV scanner; it's simply not recording the external hop *at all*.  this is
*not* a normal situation ;)

either fix the AV scanner, or set ALL_TRUSTED score to 0.   I'd recommend fixing
the AV scanner, because you'll miss a massive amount of useful rules without
that data getting into the headers.  there's a huge amount of data that is used
in spam-detection based around what the last untrusted machine claimed as HELO,
what its IP was, what its rDNS was, etc. etc.