On Sat, Mar 24, 2007 at 01:49:49PM -0700, Bart Schaefer wrote:
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.
Well, check the specification of the problem and if you can find a
better solution I'm all ears.
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.
Because that's the only way to have multiple deliveries of one mail
done.
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.
The issue was outlined in my first post - it's rather simple: I want
to have multiple deliveries of the same mail with different
conditions. And I want to not lose mail.
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.
That would be infinitely better than losing the mail.
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.
Why would I need it there? Since every (masked) delivery action seems
to need to be paired by :0e counterparts I know where the mail was
heading to. And the sanest thing to do when such a failure comes up is
to set EXITCODE and have the mail bounce back, since it is really for
the catastrophy scenario (disk bad or full, over quota etc).
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 }
(why would I need SWITCHRC? This is the last recipe)
For one if the disk is bad or some other catastrophy has happened I
don't have /path/to/safe/backup/location. Instead I want procmail to
error out.
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.
And how do I know that the message was not delivered elsewhere? ;)
I'd have to check the contents of /path/to/safe/backup/location before
nuking it, and that rather defeats the whole purpose of automatically
preprocessing and sorting the mail. And /path/to/safe/backup/location
is not quaranteed to exist at all - as said we're talking about mild
catastrophy scenarios where the disk refuses write access for whatever
reason, it could already be just out-of-quota condition.
--
Axel.Thimm at ATrpms.net
pgpmtWkeUVOPv.pgp
Description: PGP signature
____________________________________________________________
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