https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6672
--- Comment #11 from Karsten Bräckelmann <[email protected]> 2011-10-13 18:15:56 UTC --- (In reply to comment #10) > > [...] spamc is a lightweight client for spamd, deliberately "dumb" > > if you want to say so, and passes on what spamd passed back. > Accepted, and agreed about configuring the glue properly, but having > spamc/spamd silently "fail" leads to things like, well, this bugzilla entry. Or a question on the users list. However, this is by far not a frequent topic, and the behavior of passing back un-processed is properly documented. Given the reporter actually investigated the situation, used -c and obviously did read the man page (cf "0/0 response"), I can only guess he overlooked the part where -s size is documented. And, frankly, did not read the provided procmailrc.example, which clearly explains and includes a size limit for the glue. ;) > How about having spamc log something like that to syslog? spamd logs the > processing of the messages, it seems reasonable to me that spamc should > somehow > log the message being skipped for whatever reason. Logging would also introduce unnecessary complexity to spamc. Maybe a return code could indicate skipping due to exceeded size limit... But then, almost no one actually checks for the spamc return codes anyway, do they? Frankly, at least with the -c switch, as obviously used during debugging here, this condition *is* detectable. While the "0/0" states either an error or exceeding size limit, the return code of 0 clearly says not an error. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
