Martin Hepworth wrote: > Jake > > have a look at the output of "spamassassin -D --lint mailmessage". You > might be trusting the secondary MX or it might be bypassing you SA > system altogether. >
SpamAssassin's concept of trust has nothing to do with it. There's no X-Spam-* headers, so SA is being bypassed completely. SA ALWAYS adds at least X-Spam-Checker-Version header, regardless of trust. (unless you use spamc and the size is over the limit for -s). Based on the procmail config that Jake posted, one of the following must be true: 1) the messages are too large to be scanned (>250k) and thus being bypassed by spamc (250k-255k) or his procmail rule (>256k). 2) the messages from the secondary are never reaching the box that runs SA via procmail, and are being delivered to a mailbox elsewhere. 3) The messages from the secondary are reaching the box running SA via procmail, but are relayed without local delivery. (procmail only gets called as the message is delivered on the local box) I suspect 2). Particularly if there's some kind of fetchmail, multi-server-pop-client, or internal groupware server involved in the picture. 3) Is really a theoretical problem, it's possible but highly unlikely. You'd have a pretty weird server that relays mail for a user only if it came in from a secondary MX. Looking at the Received: path and size of some of the messages should clear up what's going on.
