On Sun, Mar 25, 2007 at 10:31:14AM -0700, Bart Schaefer wrote:
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.
No, what you suggest is *unconditionally* fill them into
$DEFAULT. That defeats the purpose of having mail processed and sorted
by a program.
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."
Like for any list mail which make up 99.9% of my mail traffic.
However, procmail's built-in solution to "not lose mail" is to
deliver to the $DEFAULT mailbox!
What makes you think that? procmail's purpose is to do something with
the mail other than stuffing it into $DEFAULT, even dropping spam
altogether.
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.
There is nothing to subvert, I'll repeat my very simple constraints:
o no loss of mail (should be self-understood, but anyway)
o multiple delivery actions per incoming mail with different conditions
procmail never says that you will have to put everything in $DEFAULT,
you're misquoting it.
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.
Well, I still have the concatenation of several other variables pasted
together by whatever two lines further up, no need to abuse LASTFOLDER
for that. Anyway that's not the reason LASTFOLDER is wrongly set to the
non-delivered folder, that's clearly a simply bug.
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.
The $DEFAULT again ... :)
procmail claims nowhere that delivery to $DEFAULT is a must. It would
be rather useless if all mail (or a copy of each) ended there.
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.
No, it's not, because in this setup you don't want to have everything
dumped into $DEFAULT.
Remember that as I wrote on Thu, Mar 22, 2007 at 04:02:24PM +0100,
Since procmail has a first-delivery-stop design, I'm cheating as
everybody else by making extensive use of blocks (w/o a "c" flag,
So procmail will always think the mail has not been delivered and
stuff it into $DEFAULT. That is at best a backup plan, which also
doesn't really work, because there is nowhere a notification of mail
not having been sorted properly other than your boss calling and
complaining that you still didn't process his mails ...
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.
$DEFAULT is under /var/mail which has a different quota/fs size than
my $HOME, and this is true for many setups, as well, if not most.
And how do I know that the message was not delivered elsewhere? ;)
Check procmail's log file for delivery error reports,
Which are also on the same filespace, so whatever cause writes to fail
causes logs to fail, too.
the same way you found out at the beginning of this thread.
Yes, a week later ...
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.
That's all more hackery than a solution: Filesystems can and do fill
up temporarily and get to a normal level back. During that time mail
can be "lost into $DEFAULT". So I now need a daemon checking for fs
full and notifying me that I need to check for lost mail. Only that
even this mail will have been lost, too ... :/
procmail has two bugs/weaknesses:
a) There should be a switch that is the opposite of -t, a hard-fail
switch that triggers when any delivery attempt fails
b) LASTFOLDER is wrongly set contrary to the documenation even for
failed attempts. It should undo the setting of LASTFOLDER if the
delivery was not successful.
If either a) or b) were given this thread would not exist and the
constraint of multiple deliveries with different conditionals/actions
would be possible.
As it stands the only way is the pairing of each recipe with :0 e
bloat. Sad, but true.
--
Axel.Thimm at ATrpms.net
pgpCnDl2EpiKR.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