Bug 207049 - all mail is being marked as spam even if the score doesn't make it spam
all mail is being marked as spam even if the score doesn't make it spam
Product: Fedora
Classification: Fedora
Component: spamassassin (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
Depends On:
  Show dependency treegraph
Reported: 2006-09-18 19:21 EDT by Dave Jones
Modified: 2015-01-04 17:28 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-13 01:10:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
complete headers for a failing message. (3.01 KB, text/plain)
2006-09-18 22:48 EDT, Dave Jones
no flags Details

  None (edit)
Description Dave Jones 2006-09-18 19:21:55 EDT
From davej  Mon Sep 18 16:02:22 2006
Return-Path: <fedora-extras-list-bounces@redhat.com>
X-Spam-Flag: YES
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 
        autolearn=no version=3.1.4
        *  3.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
        *      lines
        * -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.
Comment 1 Dave Jones 2006-09-18 19:41:31 EDT
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.
Comment 2 Sidney Markowitz 2006-09-18 20:33:51 EDT
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
Comment 3 Dave Jones 2006-09-18 22:48:43 EDT
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
remain untouched).
Comment 4 Dave Jones 2006-09-18 22:55:09 EDT
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.
Comment 5 Sidney Markowitz 2006-09-19 01:29:16 EDT
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
informational indicator.

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.

Comment 6 Dave Jones 2006-09-19 13:52:31 EDT
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.
Comment 7 Theo Van Dinter 2006-09-19 14:03:10 EDT
You haven't actually mentioned how you're calling SA.  Are you using
spamc/spamd, spamassassin, or a third-party milter/daemon/etc ?
Comment 8 Dave Jones 2006-09-19 16:59:50 EDT
Sorry about that.  I have spamd running as a daemon, with spamc being triggered
from .procmailrc
Comment 9 Dave Jones 2006-10-12 16:49:04 EDT
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. :-/
Comment 10 Warren Togami 2006-10-13 01:10:30 EDT
reopen if you're able to find a reproducer.

Note You need to log in before you can comment on or make changes to this bug.