[ 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
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)
- Doesn't check the error code
- Since the version is 1.0, assumes that no header lines
- 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)