(In reply to omoeller from comment #0)
> Observed with an incomplete 3.4.0 installation-from-scratch, where
> step INSTALL:
>    4. Install the SpamAssassin ruleset using "sa-update":
>           $HOME/bin/sa-update
> has not been executed:
> 
> After filtering mails, instead of the mail body there is *only* the following
> error message at end of the INBOX:
> 
> config: no rules were found!  Do you need to run 'sa-update'? at
> /usr/bin/spamassassin line 407.
> 
> (possibly duplicated times the number of mails received)
> 
> If the mail has been fetched via POP3, the mail is effectively lost and
> there is no way to recreate it.
> This should never never never never happen with spamassassin.

SpamAssassin cannot delete mail on its own. It only checks and if configured, tag as spam/ham/etc.

Mail is being deleted by whatever glue you're using

Assuming it's procmail, you're using a faulty recipe.
Please post whatever steps we can use to reproduce your "bug" or request help in the SA user's list

I had a look at the 'glue' I'm using, which is vm-spamassassin
http://vm-spamassassin.cvs.sourceforge.net

Apparently the code there bluntly filters all incoming mail through spamassassin and takes whatever the output as "marked mail":

-- emacs lips sniplet from vm-spamassassin.el, slightly older version ----
       (message "Assassinating new mails... ")
       (call-process-region (point) (point-max)
       (or shell-file-name "sh")
       t t nil shell-command-switch
       (concat vm-spamassassin-formail-program " "
        vm-spamassassin-formail-program-options " "
        vm-spamassassin-program " "
        vm-spamassassin-program-options))
       (message "Assassinating new mails... done")
---
In bash speak (and resolving all the symbols) this roughly translates to
   cat input-mail-NN.txt | formail -s spamassassin > output-mail-NN.txt

I agree that it is rather disappointing of vm-spamassassin to have no sort of error handling here, so the glue is indeed to blame.


Nevertheless IMHO spamassassin should always echo the input (if any), i.e.,
yield

  config: no rules were found!  Do you need to run 'sa-update'? at /usr/bin/spamassassin line 407.
  `cat input-mail-NN.txt`

The data would then be at least present.

It does not help the user much if you can just tell him that her glue is broken.

(In reply to omoeller from comment #2)
> I had a look at the 'glue' I'm using, which is vm-spamassassin
> http://vm-spamassassin.cvs.sourceforge.net
> 
> Apparently the code there bluntly filters all incoming mail through
> spamassassin and takes whatever the output as "marked mail":
> 
> -- emacs lips sniplet from vm-spamassassin.el, slightly older version ----
>        (message "Assassinating new mails... ")
>        (call-process-region (point) (point-max)
>        (or shell-file-name "sh")
>        t t nil shell-command-switch
>        (concat vm-spamassassin-formail-program " "
>         vm-spamassassin-formail-program-options " "
>         vm-spamassassin-program " "
>         vm-spamassassin-program-options))
>        (message "Assassinating new mails... done")
> ---
> In bash speak (and resolving all the symbols) this roughly translates to
>    cat input-mail-NN.txt | formail -s spamassassin > output-mail-NN.txt
> 
> I agree that it is rather disappointing of vm-spamassassin to have no sort
> of error handling here, so the glue is indeed to blame.
> 
> 
> Nevertheless IMHO spamassassin should always echo the input (if any), i.e.,
> yield
> 
>   config: no rules were found!  Do you need to run 'sa-update'? at
> /usr/bin/spamassassin line 407.
>   `cat input-mail-NN.txt`
> 
> The data would then be at least present.
> 
> It does not help the user much if you can just tell him that her glue is
> broken.

<sigh> 10 year old abandonware...

as per SA's INSTALL file:

...........
After installing SpamAssassin, you need to download and install the
SpamAssassin ruleset using "sa-update".  See the "Installing Rules"
section below.
.........

If the user doesn't follow the steps in the docs, you can't really blame SA for it, can you?

Well, SA is not to blame - ulitimately, the user is.
Also the glue has some fault to bear, since it apparently skips error flow completely.


Despite that, it is a reasonable assumption that whatever goes into spamassassin
also comes out again (though maybe slightly modified).

Due to the wide use, I do not believe this is an isolated problem.
Writing out the input (if any) on error is worth considering.

(In reply to omoeller from comment #4)

> Writing out the input (if any) on error is worth considering.

That is what normally happens unless you use spamc -x (--no-safe-fallback). spamc defaults to passing through the mail without an error code to prevent mail backing-up on error.  I tried to reproduce this by renaming /var/db/spamassassin/, but spamd failed to start. Running spamc without spamd does cause the mail to be passed through by default.

The lisp script on sourceforge seems to be set-up to use spamc, but I also tried the spamassassin script and that does return an error code and writes the error message you quoted to stderr.

Can you reproduce this without emacs, e.g. by running:

 echo "hello" | spamc

 
If what you are seeing comes from spamc then this is a bug, but I'm guessing that you probably aren't using spamc.

(In reply to RW from comment #5)
> (In reply to omoeller from comment #4)
> 
> > Writing out the input (if any) on error is worth considering.
> 
> That is what normally happens unless you use spamc -x (--no-safe-fallback).
...

Using spamc instead of spamassassin directly seems like the right idea, thanks.
I'll make sure my glue does that (and that spamd is started by my init scripts).

(The version on sourceforge does that already, but mine was a bit outdated, compare original post)