Red Hat Bugzilla – Bug 207049
all mail is being marked as spam even if the score doesn't make it spam
Last modified: 2015-01-04 17:28:47 EST
From davej Mon Sep 18 16:02:22 2006
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on
X-Spam-Status: Yes, score=0.4 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
* 3.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
* -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
* [score: 0.0000]
X-Spam-Status should be : No
Every mail that I'm recieving seems to be doing this.
Actually I take that last part back, it's not doing this to all mail, but a
sizable chunk of it. I'll try to determine a pattern in the affected mails.
UNPARSEABLE_RELAY may result from not properly interpreting a Received header.
If it happens often, it may be the Received header from a local mail server,
perhaps one of your MX servers if it doesn't happen every time. There have been
some fixes to recognize certain headers that were flagged as unparseable.
However, it is most likely that you are seeing the rule hit based on Received
headers for a local server that should be listed using the internal_network
and/or trusted_network options, as explained in
Created attachment 136596 [details]
complete headers for a failing message.
The Received: lines in this header look ok to me.
(I munged some of the addresses in this message, but the pertinent fields
btw, even if the unparsable headers rule was problematic, that doesn't explain
Yes, score=0.4 required=5.0
Even if that rule was being triggered correctly, 0.4 is still < 5.0, so why it
chose "Yes" instead of "No" is mysterious.
The UNPARSEABLE_RELAY comes from the header
Received: from pobox.devel.redhat.com ([unix socket])
The headers are correctly parsed and recognized as ALL_TRUSTED in the current
SpamAssassin 3.2 development tree (upstream), but not the 3.1 branch.
I didn't notice the anomaly in the scores. Aside from it being labeled as spam
even though the score does not exceed the 5.0 threshold, it does look like
something is wrong with the configuration. UNPARSEABLE_RELAY is supposed to have
a score of 0.001. It is not a spam sign. It is only used as part of identifying
Received headers that can be used for determining things, and as an
That doesn't answer what caused this message to be labeled spam. The output from
spamassassin -D applied to the message would show what is going on. I can't
reproduce the scoring problem myself.
Hmm. I saved one of the affected mails, stripped out the spamassassin headers,
and fed it to spamassassin -D. It marked it as ham.
X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,
UNPARSEABLE_RELAY autolearn=ham version=3.1.4
Very strange. It's running the same version of spamassassin as it was yesterday,
with the same config files. Very puzzling.
UNPARSABLE_RELAY was set to 3 in my local config as part of some test I was
doing a while ago, that I forgot to remove. I've removed it now.
Something that's really baking my noodle -- Since I filed this bug, it hasn't
reproduced itself. My spamfolder now only contains spam again.
You haven't actually mentioned how you're calling SA. Are you using
spamc/spamd, spamassassin, or a third-party milter/daemon/etc ?
Sorry about that. I have spamd running as a daemon, with spamc being triggered
This hasn't reoccured since that one evening, so I'm happy to close this unless
you'd prefer to keep digging. The lack of reproducability severely impairs any
effort to root cause it though. :-/
reopen if you're able to find a reproducer.