On Wed, 3 Sep 2003, Larry Gilson wrote:

> It appears that even though spamc aborts the attempted spamd connection
> after 3 retries, it will not produce a non-zero exit code.  Is it my
> recipe or spamc?

It's spamc.  From the manual page:

       -f   Cause spamc to safe-failover if it can't connect to
            spamd -- what this means is that in case spamc fails
            to connect to spamd, it will not return with an
            exitcode set, it will instead dump the original
            message to stdout, allowing the message to be
            delivered, albeit unscanned for spam.  Without this
            flag, connection failures to spamd will cause message
            delivery failures.

            Even with this flag set however, if spamc connects
            successfully, and then encounters an error at a later
            stage of communication, it will still return an
            exitcode.

            This now defaults to on, and can't be turned off.
            This flag is accepted though for backwards-
            compatibility.

So spamc is going to exit 0 when either the message is processed or spamd
is not reachable, and nonzero when spamd gets an error after connecting.

However, you might try:

       -x   Don't use the 'safe fallback' error-recovery method,
            which passes through the unaltered message if an
            error occurs.  Instead, exit with an error code, and
            let the MTA queue up the mails for a retry later.

That would mean (compacting your recipe a bit):

  :0
  * SAONOFF ?? on
  * ! ^X-Spam-Status: Yes
  * B ?? < 256000
  {
    :0 fw
    | spamc -x

    :0 efw: spamassassin.lock
    | spamassassin -a
  }

However, I've never personally tried the -x option, so ...

Some assorted comments on recipe writing:

> # I set SAONOFF to be able to turn the test on or off
> :0 w
> * SAONOFF ?? on
> {

The "w" flag is useless there.  Use "w" (or "W") only with "f" or "c", and
with "c" only when the action begins with an open brace.

>    :0 
>    * ! ^X-Spam-Status: Yes
>    {
>       :0fw: spamassassin.lock
>       * < 256000
>       | spamc

The lockfile isn't necessary there.  If you want to limit the number of
spamc connections, you should be running spamd with the "-m" option.

Also, you really don't want to put large messages through spamassassin
either, so the "< 256000" test should go outside the braces with the
X-Spam-Status test.  Besides:

>       SCANNED=$?

As you've written it this is going to be 0 or an unwanted value (from some
unknown previous recipe) any time the "< 256000" test fails.  You really
want to use this trick only when the condition line runs a program.

>       :0 Afw: spamassassin.lock
>       * ! SCANNED ?? ^^0^^
>       | spamassassin -a
>    }
> }
> 
> :0 w
> * ^X-Spam-Status: Yes
> {
>    stuff
> }

Useless "w" again.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

Reply via email to