From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux)
Description of problem:
spamd is started via the initscript when the system boots; no complaints, and no defunct processes.
The first time a user account gets mail and spamc is called, a defunct spamd process is created, owned by the user who called spamc.
[root@grithr root]# ps -ef | grep defunct
graydon 1387 1368 0 22:22 ? 00:00:00 [spamd <defunct>]
The mail is processed correctly; the additional headers in the mail look like (for some non-spam mail)
X-Spam-Status: No, hits=0.0 required=5.0
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
the procmail rule in the user .procmailrc file looks like:
Subsequent mail gets through ok, gets through spamassassin, gets the header markup, and the same original defunct process is still sitting there.
spamassassin-2.50-4.8.x produces the same errors.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. put a :0fw rule calling spamc in a user .procmailrc file
2. have that user get mail
Actual Results: got the mail ok, but have a defunct spamd process -
Expected Results: Should have got the mail without spamd creating a defunct process.
The self-same .procmailrc file worked fine in RH 8.0; the breakage occured sometime between Phoebe 2 and Phoebe 3.
Here's my take on this one...
I first noticed this problem when my wife recieved a mail from her boss... After
that mail checking through ipop3d failed, complainting about invalid mailbox
format(the mailbox (/var/spool/mail/username) at this time is 1 byte in size
containing only a '0x0a' char).
Please notice that I do NOT get the affected mail, ever!
Checking my mail when the error has occurred (over ipop3d) results in an
error... That error only goes away after sending a new message(blank or
something) because that "repairs" my /var/spool/mail/username file.
I have not been able to track down the exact problem, but I produced a mail-file
that will trigger the error... Just run 'cat test_mail_bad |spamc' and a
following 'ps aux' will show the defunct process.
I have upgraded to SpamAssassin version 2.53 and cant seem to reproduce with the
same mails now.
Hope this is of help!
Created attachment 91208 [details]
test mail that triggers the problem
This mail triggers the problem... 'cat test_mail_bad |spamc' and notice that no
output is produced and there is a defunct spamd process afterwards
I think we can justify a higher prio on this one, since users can actually loose
mails as a result of this problem!
Could the bug potentially be exploited? If so, maybe an even higher
priority/severity may be required!
spamassassin in rh9 definitly looses mails in the way described before at
our site, too, there should really be done something against this.
*** This bug has been marked as a duplicate of 86029 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.