From davej Mon Sep 18 16:02:22 2006 Return-Path: <fedora-extras-list-bounces> X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on pressure.kernelslacker.org X-Spam-Level: X-Spam-Status: Yes, score=0.4 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Report: * 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.
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 http://wiki.apache.org/spamassassin/TrustPath
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).
btw, even if the unparsable headers rule was problematic, that doesn't explain this.. 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 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.
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 from .procmailrc
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.