|Summary:||spamc eats mail if spamd encounters an error|
|Product:||[Fedora] Fedora||Reporter:||Owen Taylor <otaylor>|
|Component:||spamassassin||Assignee:||Warren Togami <wtogami>|
|Status:||CLOSED INSUFFICIENT_DATA||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-06-08 18:50:49 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Owen Taylor 2003-03-12 17:33:57 UTC
[ 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.
Comment 1 Chip Turner 2003-03-15 16:20:44 UTC
can you test this with spamassassin-2.50-2.8.x?
Comment 2 Warren Togami 2004-02-29 06:22:14 UTC
*** Bug 88246 has been marked as a duplicate of this bug. ***
Comment 3 Warren Togami 2005-04-03 10:31:55 UTC
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.
Comment 4 Owen Taylor 2005-04-03 12:40:38 UTC
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)
Comment 5 Warren Togami 2007-06-08 18:50:49 UTC