Quoting Matt Kettler <mkettler...@verizon.net>:
Mark Mahabir wrote:
2009/9/3 Matt Kettler <mkettler...@verizon.net>:
Does the From: header of these messages match *...@domain.com, or are they
*...@something.somedomain.com (which wouldn't match)?
They're definitely *...@domain.com in the From: header.
Does the X-Spam-Status header show that a blacklist matched
(USER_IN_BLACKLIST)?
No, they don't (the ones that don't get tagged).
Thanks,
Mark
Interesting, then one of the following is the cause:
1) there's errors in your config, and SA isn't parsing local.cf at all.
To check for this, run "spamassassin --lint". It should run quietly, if
it complains, find and fix the offending lines.
2) You're editing a local.cf in the wrong path. Check what the "site
rules dir" is near the top of the debug output when you run
"spamassassin -D --lint".
3) the offending message has multiple From: headers, and SA is
interpreting the other one. You can try looking at the raw message
source for this.
4) The configuration being used at delivery time is over-riding the one
used at the command line. You can try pumping the message as a file
through spamassassin on the command line and see what it comes up with.
If it matches USER_IN_BLACKLIST on the command-line, but fails to match
at delivery, something is fishy about your integration and how it
configures SA.
Or, does order of comparison matter. From the documentation,
blacklist_from states to see whitelist_from. whitelist_from states:
The headers checked for whitelist addresses are as follows: if
"Resent-From" is set, use that; otherwise check all addresses
taken from the following set of headers:
Envelope-Sender
Resent-Sender
X-Envelope-From
From
If taken in that order, the From header field would be compared last.
