SA Bugzilla – Bug 5104
"spamc -e" that returns EX_TEMPFAIL when spamd unavailable
Last modified: 2010-11-12 20:44:42 UTC
I'd like a spamc invocation suitable for simple use with Postfix's after-queue content filtering via its "pipe" daemon. I've described its expectations at <http://wiki.apache.org/spamassassin/ IntegratedSpamdInPostfix>. The short version is this: 1. If spamc returns 0, Postfix assumes spamc has accepted responsibility for delivering the message. 2. If spamc returns EX_TEMPFAIL or EX_OSERR, Postfix defers the message. 3. Otherwise, Postfix bounces the message. Given #1, any direct invocation of spamc needs the "-e" argument to pass to sendmail. I want to defer messages when spamd is unavailable, not deliver or bounce. When using -e, none of spamc's various return code options do this: $ echo foo | spamc -t 1 -U /nonexistent -e /bin/cat; echo $? foo 0 $ echo foo | spamc -x -t 1 -U /nonexistent -e /bin/cat; echo $? foo 0 $ echo foo | spamc -E -t 1 -U /nonexistent -e /bin/cat; echo $? foo 0 $ echo foo | spamc -E -x -t 1 -U /nonexistent -e /bin/cat; echo $? foo 0 My workaround is to launch spamc through a script, keep the message in a tempfile, and then launch sendmail myself. (I pasted such a script into the wiki page.) It works, but it's awkward and less efficient. Postfix documentation says: "With the shell script as shown above you will lose a factor of four in Postfix performance for transit mail that arrives and leaves via SMTP. You will lose another factor in transit performance for each additional temporary file that is created and deleted in the process of content filtering."
> I want to defer messages when spamd is unavailable, not deliver or bounce. > When using -e, none of spamc's various return code options do this: > $ echo foo | spamc -x -t 1 -U /nonexistent -e /bin/cat; echo $? > foo > 0 I am unable to reproduce this. The -x option disables the default of "safe fallback" as documented, and spamc exits with proper return codes. In fact, I am using the -x option for a long time already in procmail. $ echo | spamc -x -t 1 -p 7830; echo $? 69 Using an invalid port (the command above, equivalent to spamd not running) returns EX_UNAVAILABLE, service unavailable. Using an invalid socket (as comment 0 does) spamc returns 70, EX_SOFTWARE, internal software error instead. Additionally using the -e option does not change anything, the return codes are the very same, exactly as documented. Neither does -t timeout change the result. Assuming this issue has been fixed since.