I'm having a problem whereby Spamassassin is sometimes being killed by SIGPIPE before it's written-out the email to stdout, and then returns a zero exit-code.
Whilst I'd be keen to eliminate the SIGPIPE problem, the more important problem is the return of the zero exit-code, because it turns delayed mail into lost mail. Getmail treats it as success, delivers an empty email with just it's own headers, and deletes the original off the server. If I hack Spamassassin's default signal handler to return 1 then everything works correctly, the delivery is aborted, the email gets left on the pop/imap server, and gets delivered on the next check. Arguably, it might be pragmatic for the handler to return 0 (not spam) if the "-e" option is used, but if it isn't then it should return a non-zero error code. I'm using SpamAssassin 3.2.5 on FreeBSD 7.1, and using the spamassassin script directly with no command-line options (i.e. without the -e option)
