[Dovecot] use of deliver from procmail advisable?

[Kyle Wheeler]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://dovecot.org/pipermail/dovecot/attachments/20070816/1362d6c6/attachment-0001.bin