On Wednesday, August 15 at 06:08 PM, quoth martin f krafft:

This is exactly how I used to have it but then the need for a vacation autoresponse to the From: address (as opposed to Return-Path) arose and I had to switch to procmail:

http://dovecot.org/list/dovecot/2007-August/024766.html

Before that, I was using spamc with --pipe-to, but always had a bad feeling about that, since the manpage says:

Note that there is a very slight chance mail will be lost here, because if the fork-and-exec fails there’s no place to put the mail message.

HEH. Using procmail has the same (or worse) problems, and has the very real potential of lost mail if anything goes wrong (including fork-and-exec failure). It's *possible* to configure procmail to handle failure better, but it's cumbersome and irritating. You have to follow every rule with something like this:

 :0 e
 {
     EXITCODE=75
     HOST
 }

I mean, do you know and understand the importance of the ORGMAIL variable to procmail? Most procmail users don't, and it's critical to understanding procmail's behavior when faced with errors.

For example, if you run out of disk quota, procmail will happily fail
and exit with a successful return code, informing your MTA that the message was delivered when in fact it was not. Or it will be delivered, but to the ORGMAIL box (which most admins have never heard of), and it will simply *appear* to be gone. But if it can't deliver to ORGMAIL... according to the man page the mail will "bounce back to the sender", but do you know what that means? Will procmail exit with a non-zero exit code? Or will procmail generate its own bounce and feed it to sendmail?

and my message to SA-users on this was never answered[0].

0. http://marc.info/?l=spamassassin-users&m=115185095923772&w=2

fork-and-exec can fail if:

 1. There is insufficient memory to fork
 2. There are insufficient PIDs to fork
 3. The limit on the user's number of processes has been reached 
    (RLIMIT_NPROC)
 4. The total number of bytes in the environment is too large
 5. Search permission is denied on a component of the path prefix
 6. The script's interpreter cannot be found (if you're exec'ing a 
    script)
 7. The file to be executed, or the script interpreter, is not a 
    regular file
 8. Execute permission is denied for the file to be executed
 9. The file system is mounted 'noexec'
10. The executable is an invalid executable, or attempts to name 
    more than one interpreter
11. An I/O error occurred while reading the executable
12. The executable listed, or the script interpreter, is a 
    directory rather than a program
13. There is a loop in the script interpreter (e.g. the interpreter 
    specified in the script is itself a script whose interpreter is 
    the first script).
14. The limit on the user's number of open files has been reached.
15. The name of the executable is too long.
16. The limit on the operating system's number of open files has 
    been reached.
17. The file to be executed does not exist.
18. The executable is for a different architecture.
19. Insufficient kernel memory is available.
20. A component of the path to the executable, or to the script's 
    interpreter, is not a directory.
21. The filesystem is mounted 'nosuid', the user is not the 
    superuser, and the file has an SUID or SGID bit set.
22. The process is being traced, the user is not the superuser, and 
    the file has an SUID or SGID bit set.
23. The executable was open for writing by another process.

That's the SHORT list for why things might go wrong. Depending on the binary that you ask spamc to run, waiting for it to finish may be impossible (for example, if it does a fork/exec to handle things), so no, the spamc client cannot be expected to simply wait and tell you with certainty that the mail was delivered properly in all cases.

Now I am using procmail and at least now that failure will cause postfix to defer a message.

It may not, unless you're significantly more in-tune with procmail than your average sysadmin.

~Kyle -- If I had only known, I would have been a locksmith. -- Albert Einstein