Red Hat Bugzilla – Bug 86029
spamc eats mail if spamd encounters an error
Last modified: 2007-11-30 17:10:31 EST
[ spamc has been largely rewritten in spamassassin CVS and is considerably better, but it still doesn't actually check the response code that spamd sends back ] $rpm -q spamassassin spamassassin-2.44-11.8.x Things work very badly in 2.44-11.8 if spamd dies with a protocol error on a message (see bug 86028). It returns a 0 error status (so procmail thinks it succeeded) but outputs a blank message. Details of what goes wrong. spamd's response is: SPAMD/1.0 76 Bad header line: (Content-length mismatch: 5768 vs. 5764) Spamc (spamd/libspamc.c:message_filter()) - Doesn't check the error code - Since the version is 1.0, assumes that no header lines follows. - Compares the 0 additional bytes it gets to the unitialized expected_len variable, and quite likely concludes that evrything was OK.
can you test this with spamassassin-2.50-2.8.x?
*** Bug 88246 has been marked as a duplicate of this bug. ***
Owen, do you still see this problem with FC3 or FC4? Or do you still care? Otherwise I'm closing these old bugs against ancient versions.
I certainly don't stil have the test configuration around ... it shouldn't be that hard to do code inspection to see whether an error code returned from spamd is checked or not. (If not, reporting the bug upstream and closing this UPSTREAM is OK, otherwise it could be closed FIXED)
Closing old