On 3/25/07, Axel Thimm <Axel(_dot_)Thimm(_at_)atrpms(_dot_)net> wrote:
procmail claims nowhere that delivery to $DEFAULT is a must.
It says about ORGMAIL: "If, for some obscure reason (like 'filesystem
full') the mail could not be delivered, then this mailbox will be the
last resort. If procmail fails to save the mail in here (deep, deep
trouble :-), then the mail will bounce back to the sender."
It also says that the startup-time value of DEFAULT is $ORGMAIL. The
above really is a documentation bug, because procmail does not attempt
to use $ORGMAIL unless $DEFAULT is not set; really, it's $DEFAULT that
is the mailbox of last resort, as can be demonstrated by changing
DEFAULT to an undeliverable location without changing ORGMAIL.
procmail has two bugs/weaknesses:
It has more than two. Perhaps its greatest one right now is that
neither the original author nor the most recent maintainer are
actively updating it, so complaining about bugs doesn't do much good
and you're better off adopting one of the workarounds you're offered.
a) There should be a switch that is the opposite of -t, a hard-fail
switch that triggers when any delivery attempt fails
According to the manual:
You can tell procmail to treat a delivering recipe as if it
were a non-delivering recipe by specifying the 'c' flag on
such a recipe.
So as far as procmail is concerned, no delivery attempt has failed,
because :0c: means the recipe is not a delivering recipe any more.
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.
The documenation says LASTFOLDER "is assigned to by procmail whenever
it is delivering to a folder or program." (Note "is delivering" not
"has delivered".) It doesn't say it's assigned to again when
something goes wrong, though I concede that "always contains the name
of the last file (or program) procmail delivered to" may be
misleading. That makes it (1) a documentation error and (2) a
disagreement between you and the author of procmail as to how procmail
should deal with failure to create "carbon copies".
Nevertheless, it's still you who are deliberately telling procmail to
throw away the original message, which is the only copy of the message
that procmail was designed to treat as important enough to bounce on a
delivery failure. You can claim that's bad design and I won't
necessarily disagree, but that doesn't help, does it?
As it stands the only way is the pairing of each recipe with :0 e
bloat. Sad, but true.
The "only way" is the pairing of each recipe with *something*. It
doesn't have to be :0e.
:0cw:
* conditions
| cat >> foldername
ALLEXITS="$ALLEXITS $?"
# ... repeat for other folders ...
:0
* ALLEXITS ?? [1-9]
{ LOG="At least one write failed$newline" }
You can even come up with a recursive-include scheme that tries the
:0c: recipes one at a time and lets you put a single :0e after the
INCLUDERC. (Which is another reason you might want LASTFOLDER set at
the :0e time.) However, I've expended enough energy on this thread
already.
____________________________________________________________
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