Fixed the problem. Looks like the howto I followed for setting up spamass-milter was wrong. After redoing my sendmail config for it, all is well.
Thanks for all the help everyone. --John > I decided to run spamd in debug mode, and log what it was seeing. This is > what I found for a direct delivered message.. > > debug: received-header: unknown format: from fluidhostingc.com (unknown) > by kangaroo.publicmx.com; > > Searched around on Google, and saw a reference that atleast in > spamass-milter 0.2, the milter fakes the received header to appease SA. > However, that method doesn't work so well. > > --John > >> Thanks for the info. >> >> I fixed that Received line, by removing the line wrap, and it was no >> longer ALL_TRUSTED. >> >> Now that I know what the issue is, I just need to figure out why the >> header is getting munged. >> >> Thanks, >> John >> >>> John T. Yocum wrote: >>>> 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. >>>> >>> >>> Well, that much makes sense. SA can't parse the Received: headers your >>> server >>> generates, but it can parse ones generated by outside servers. Thus, >>> outside >>> mail with another relay will show up as having been through an >>> untrusted >>> host. >>> >>> >>> The problem you need to track down is why can't SA parse your Received: >>> headers. >>> >>> Based on the debug output you got it could be an issue with line-wrap >>> formating. >>> >>> At casual glance, the headers you quoted look correct, but it's >>> impossible >>> to >>> tell if they're really correct because they've been copy-pasted into an >>> email >>> message which adds line wraps. >>> >>> >>> To check that, you need to look at a set of pristine message headers, >>> not >>> a >>> copy-paste of them, in a hex editor. (The process of copy-pasting can >>> change >>> linewrap formats, replace tabs with spaces, and other sundry things >>> that >>> would >>> matter here). >>> >>> One thing I can tell you is that there MUST NOT be a linewrap between >>> the >>> end of >>> the RDNS hostname and the [ for the IP address. >>> >>> This quotation should be only 3 lines long: >>> >>> 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 >>> >>> >>> But I'm assuming the extra linewrap after .jp was added by your mail >>> client. >>> >> >> > >
