On 3/24/07, Axel Thimm <Axel(_dot_)Thimm(_at_)atrpms(_dot_)net> wrote:
Well, check the specification of the problem and if you can find a
better solution I'm all ears.
[...]
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.
Well, no, that's one way to stop delivery into the $DEFAULT mailbox.
You can have multiple deliveries without assigning to HOST, as long as
one of the multiples is $DEFAULT.
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.
The only possible reason for assigning to HOST is that one possible
outcome of your conditions is "do not deliver to the $DEFAULT
mailbox." However, procmail's built-in solution to "not lose mail" is
to deliver to the $DEFAULT mailbox! If you want to subvert that,
you've got to do the additional programming yourself; but you don't
want to do any additional programming. You've created set of
constraints that it's impossible to satisfy.
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?
The folder name may be a computed value concatenated from several
other variables. It might even be something pasted together by an
INCLUDERC written and maintained by your system administrator, so that
you don't know when it might change.
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).
Procmail does that -- but it only does it automatically when final
delivery to $DEFAULT fails, because in every other case the programmer
has the opportunity to handle the error.
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)
If it's the last recipe, you don't need HOST=stop either (cf. the
DELIVERED variable). One assigns a "wrong" value to HOST to abort
*all* further processing; SWITCHRC is the closest analog that stops
processing the current file but allows procmails's default fallthrough
to continue. So for anyone else reading this post later, where the
assignment might not be their last recipe, SWITCHRC is the right thing
to do.
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.
Which is what will happen if automatic final delivery to $DEFAULT
fails! By assigning $DEFAULT and allowing procmail to attempt
delivery, you invoke the failsafe mechanism that returns an error code
to the MTA and allows the MTA to decide whether to queue or bounce the
mail.
And how do I know that the message was not delivered elsewhere? ;)
Check procmail's log file for delivery error reports, the same way you
found out at the beginning of this thread.
I'd have to check the contents of /path/to/safe/backup/location before
nuking it
Don't nuke it outright, rotate it out of the way so that you have a
few days worth of backups, and either configure logrotate to, or set
up another cron job to, grep for errors in the procmail log and notify
you somehow.
____________________________________________________________
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