On 3/24/07, Axel Thimm <Axel(_dot_)Thimm(_at_)atrpms(_dot_)net> wrote:
Of course, but once in a decade the fs is allowed to have troubles
like a bad disk or fs full. procmails does look a bit fragile in this
light, especially I one now has to manually check all recipes for
success or failure like above. :/
It seems to me you're bringing this on yourself. There's a reason for
the first-delivery-stop design; if the delivery fails, processing
doesn't stop, so $DEFAULT is always a failsafe. It's your algorithm
that's "fragile": the mail isn't "lost" until you explicitly throw it
away by assigning to HOST.
I surmise that you're using :0c: followed later by setting HOST
because you want to deliver the mail to more than one non-$DEFAULT
mailbox, but never both to any other mailboxes and also to $DEFAULT.
Consider that, in the absence of any explicit error checking, even if
procmail behaved the way you want (did not set LASTFOLDER on a
delivery failure), you could still have a case where delivery to one
non-$DEFAULT folder fails, but the next non-$DEFAULT folder succeeds
and sets LASTFOLDER. You'd never find out about the first failure.
The final step where you discard the message is just a special case of
this pervasive problem.
If LASTFOLDER were left unset on failed deliveries, then one could not
make use of its value in the :0e recipies that you're unhappy about
needing.
One possible approach to fix your problem without completely rewriting
your recipies is to replace
{ HOST=stop }
with
{ DEFAULT=/path/to/safe/backup/location
SWITCHRC }
and then periodically [automatically, e.g. daily with logrotate] clean
out the backup location. Then if you run into a problem where a
message got delivered nowhere else, you can go retrieve it from the
backup.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail