On Mon, 2004-12-06 at 22:52 -0800, Loren Wilton wrote: > Received: from CM02.outbound.mail (mailer4.monteraymedia.com [66.63.189.28] > (may be forged)) by mail.camerontech.com (8.13.1/8.13.1) with ESMTP id > iB75ihQg015990 for <[EMAIL PROTECTED]>; Mon, 6 Dec 2004 > 23:44:44 -0600 > Received: by CM02.outbound.mail (PowerMTA(TM) v2.0r6) id h4mn9a050u48; Mon, > 11 Jun 2001 22:47:13 -0700 (envelope-from <[EMAIL PROTECTED]>) > > Remember "all trusted" really means "no untrusted links in the recieved > headers that we were able to parse". > > If SA can't parse a received header line, it simply tosses it and continues > with the next one. This may not be the best plan, and there are various bugs > open about the exact meaning and handling of all-trusted. > > The second header shown above doesn't have any ip addresses in it, so it > would get tossed (or maybe considered as local, I'm not positive). > > That leaves the first header, which at a glance would seem to not come from > your network, so shouldn't be trusted. I'm guessing that there is something > about the format of this header that SA doesn't much care for, so it ended up > tossing it as unreadable. > > That would leave you with no received headers, which would mean that the mail > had been sent locally, so was obviously trusted. :-( > > There was a patch in the works a month or so back to somehow take account of > unparsable headers in determining all-trusted. I was out of town for most of > November and lost track of the status of that change. Assuming that the > problem here is the first received header was unparsable, that patch may help > matters if it is approved. > > Loren
Then I guess my next option is to set score ALL_TRUSTED 0 0 0 0 in /etc/mail/spamassassin/local.cf until this gets resolved? Thomas
