From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
spamd is running. When spam-like mail arrives, no filtering occures.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start spamd, enter proper configuration in /etc/procmailrc:
:0fw * < 256000
| /usr/bin/spamc -f
* ^X-Spam-Status: Yes
2. post a spam-like mail
Actual Results: Although spam is recognized, no filtering occures (message
headers remain unchanged)
Expected Results: Procmail should perform filtering (spamc should alter message
headers to identify spam)
The following entries appear in /var/log/maillog:
Nov 19 11:39:01 maciejka spamd: connection from maciejka.net [ 127.0.0.1 ]
at port 32878
Nov 19 11:39:01 maciejka spamd: info: setuid to mkycler succeeded
Nov 19 11:39:33 maciejka spamd: identified spam (31.1/5.0) for
mkycler:1002 in 32 seconds, 4858 bytes.
Nov 19 11:39:33 maciejka spamc: failed sanity check, 7694 bytes claimed,
7709 bytes seen
I was seeing this issue as well (along with "Malformed UTF-8 Character"
warnings, etc). It seems that SpamAssassin does not handle UTF-8 locales very
well. A suggested workaround is to put "export LANG=C" in the
/etc/sysconfig/spamd file and do "service spamassassin restart".
In a default RH8 installation there is no /etc/sysconfig/spamd. Do you mean
I don't see any problem with "Malformed UTF-8 Character", but I do have the
problem that procmail doesn't seem to process its rules. Is there any fix or
sounds like a utf8 issue; try the latest perl and spamassassin from rawhide?
can you confirm whether it works with the latest, or if the LANG=C fixes the
"export LANG=C" in /etc/sysconfig/spamassassin solved the problem.
I haven't tried the latest perl nor spamassassin.
*** Bug 89613 has been marked as a duplicate of this bug. ***
same problem exists on RH9, same workaround applies.
Is this still an issue on RH9?
Closing old bugs