Re: Spamassassin rewriting headers of messages that are not marked Spam
Hi, This is the entire content of my local.cf: required_hits 5 report_safe 0 rewrite_header Subject [SPAM] I don't think that's the best configuration either. You should start with a default local.cf, then. You might also try enabling some debugging to trace the loading of plugin-ins and rules. If you're using amavisd you should be able to do something like this: amavisd -c /etc/amavisd.conf debug-sa foreground 21 | tee /var/log/amavisd.tmplog You can then view /var/log/amavisd.tmplog from the top to see exactly what it is doing. Amavis will also be live, listening for incoming mail, so you can trace it in real-time. If you're not using amavisd, (and even if you are, actually), you can run the following to produce similar output: spamassassin -D config --lint 21 | tee /var/log/spamassassin.tmplog HTH, Alex
Re: Spamassassin rewriting headers of messages that are not marked Spam
Thanks for your reply Alex! Alex-325 wrote: Hi, My spamassassin installation suddenly (since March) starting rewriting the headers of messages that are not spam. March isn't so suddenly. Why is it a problem now and not last month? I'm tolerant. However, my tolerance has limits, and I've reached them. Alex-325 wrote: Are you sure it is your system that is rewriting the headers? Is it happening on every email? It's happening on 90%, and I'm not able to discern the pattern of the other 10%. Yes I'm sure it's my system, because the header shows xspam-prev-header without [SPAM] in it. That means that spamassassin admits that it changed the header and added [SPAM] to it. Alex-325 wrote: X-Spam-Status: No, score=3.9 required=5.0 tests=AWL,BAYES_50, DNS_FROM_OPENWHOIS,FH_DATE_PAST_20XX,HTML_MESSAGE,URG_BIZ autolearn=no That says that it isn't spam, so it doesn't seem likely that your system would be rewriting the subject header to say that it's spam. It seems that my system shouldn't be doing it, but it is, which is the problem. Alex-325 wrote: What setting do you have in local.cf for reporting? Check these variables: report_safe clear_report_template report add_header all This is the entire content of my local.cf: required_hits 5 report_safe 0 rewrite_header Subject [SPAM] -- View this message in context: http://old.nabble.com/Spamassassin-rewriting-headers-of-messages-that-are-not-marked-Spam-tp28384319p28385386.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Spamassassin rewriting headers of messages that are not marked Spam
On Tue, 2010-04-27 at 23:53 -0700, Sitapati wrote: Thanks for your reply Alex! Alex-325 wrote: Hi, My spamassassin installation suddenly (since March) starting rewriting the headers of messages that are not spam. March isn't so suddenly. Why is it a problem now and not last month? I'm tolerant. However, my tolerance has limits, and I've reached them. Alex-325 wrote: Are you sure it is your system that is rewriting the headers? Is it happening on every email? It's happening on 90%, and I'm not able to discern the pattern of the other 10%. Yes I'm sure it's my system, because the header shows xspam-prev-header without [SPAM] in it. That means that spamassassin admits that it changed the header and added [SPAM] to it. Alex-325 wrote: X-Spam-Status: No, score=3.9 required=5.0 tests=AWL,BAYES_50, DNS_FROM_OPENWHOIS,FH_DATE_PAST_20XX,HTML_MESSAGE,URG_BIZ autolearn=no That says that it isn't spam, so it doesn't seem likely that your system would be rewriting the subject header to say that it's spam. It seems that my system shouldn't be doing it, but it is, which is the problem. Alex-325 wrote: What setting do you have in local.cf for reporting? Check these variables: report_safe clear_report_template report add_header all This is the entire content of my local.cf: required_hits 5 report_safe 0 rewrite_header Subject [SPAM] Just to be sure it *is* your SA installation that's writing this, try changing that (temporarily) to something like: rewrite_header Subject [SPAM Test] and see if it really is your SA doing the re-write. Don't forget to restart spamd. signature.asc Description: This is a digitally signed message part
Re: Spamassassin rewriting headers of messages that are not marked Spam
On Tue, 27 Apr 2010, Sitapati wrote: My spamassassin installation suddenly (since March) starting rewriting the headers of messages that are not spam. Here's an example: X-Spam-Status: No, score=3.9 required=5.0 tests=AWL,BAYES_50, DNS_FROM_OPENWHOIS,FH_DATE_PAST_20XX,HTML_MESSAGE,URG_BIZ autolearn=no version=3.2.5 Not that this will fix your header-rewriting problem, but if you're seeing FH_DATE_PAST_20XX hits you _really_ ought to run sa-update and get your rules updated. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Of the twenty-two civilizations that have appeared in history, nineteen of them collapsed when they reached the moral state the United States is in now. -- Arnold Toynbee --- 13 days since a sunspot last seen - EPA blames CO2 emissions
Re: Spamassassin rewriting headers of messages that are not marked Spam
Hi, My spamassassin installation suddenly (since March) starting rewriting the headers of messages that are not spam. March isn't so suddenly. Why is it a problem now and not last month? Are you sure it is your system that is rewriting the headers? Is it happening on every email? X-Spam-Status: No, score=3.9 required=5.0 tests=AWL,BAYES_50, DNS_FROM_OPENWHOIS,FH_DATE_PAST_20XX,HTML_MESSAGE,URG_BIZ autolearn=no That says that it isn't spam, so it doesn't seem likely that your system would be rewriting the subject header to say that it's spam. What setting do you have in local.cf for reporting? Check these variables: report_safe clear_report_template report add_header all It's SpamAssassin 3.2.5 (2008-06-10) running on RHEL 5.5. Anyone have any ideas on what it might be or what to look for? You should also verify the method by which the regular updates are being applied, as the FH_DATE_PAST_20XX could be a sign of an outstanding bug in the default v3.2.5 72_active.cf file. Regards, Alex
