Thanks. I tried adding the /32 to the end, but that didn't have an effect. I did run the headers through spamassassin -D and got the following.
debug: received-header: unknown format: from U075209.ppp.dion.ne.jp (U075209.ppp.dion.ne.jp debug: metadata: X-Spam-Relays-Trusted: debug: metadata: X-Spam-Relays-Untrusted: Thus, it was tagged as ALL_TRUSTED. What is really odd, is this only happens to direct delivered mail, any message relayed via another host, doesn't get the ALL_TRUSTED flag. Thanks, John > mouss wrote: >> John T. Yocum wrote: >> >>> Hello, >>> >>> I've recently noticed that a lot of spam is getting through >>> SpamAssassin, >>> and it's getting the ALL_TRUSTED test listed on it. The issue with that >>> is, I only have one IP trusted, and that's my own mail server. >>> >>> <snip from local.cf> >>> # Trusted Networks >>> trusted_networks 69.25.118.171 >>> </snip> >>> >>> As you can see in the below set of headers the message came from >>> 218.222.75.209. Yet, it's trusted. >>> >>> Return-Path: <[EMAIL PROTECTED]> >>> Received: from U075209.ppp.dion.ne.jp (U075209.ppp.dion.ne.jp >>> [218.222.75.209]) >>> by kangaroo.publicmx.com (8.13.4/8.13.4) with ESMTP id >>> j6OKabJS014331 >>> for <[EMAIL PROTECTED]>; Sun, 24 Jul 2005 13:36:40 -0700 >> >> >> My understanding (but I may be wrong) is that ALL_TRUSTED means all >> received headers are trusted, which seems the case. It doesn't mean the >> origin client is trusted. >> > > You are incorrect mouss. It does in fact mean that all hosts involved are > trusted hosts. Well, it actually means there are no untrusted hosts, but > unless > there's an unparseable header it's the same thing. > > Suggestions: > > 1) add a /32 to the end of your trusted networks statement. The docs SAY > it will > work without a netmask, but my experience with 2.6x is that it did not > work, so > I always specify a mask. > > 2) the other causes when SA fails to be able to parse the Received: > headers. > That header looks normal to me, but try running the message through > spamassassin > -D and see what SA has to say about the Received: path in it's debug > output. >
