On Sun, Mar 25, 2007 at 01:57:23PM -0700, Bart Schaefer wrote:
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."
Which obviously does not apply for delivery recipes that are in
blocks, because the block as a whole is a non-delivery recipe.
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.
The only workaround was the pairing of recipes, not a thrilling idea:
wc -l rc.*| tail -1
2662 total
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.
Only that I'm not using :0 c:
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".)
But please be as fair as to read the very next sentence, which is
clearly a lie. FWIW I already refered to that doc bug two days ago, so
you should perhaps check the thread - perhaps procmail lost your mail,
too? ....
Anyway, here it comes:
On Sat, Mar 24, 2007 at 06:17:58PM +0100, Axel Thimm wrote:
| The documentations says "This variable is assigned to by procmail
| whenever it is delivering to a folder or program. It always
| contains the name of the last file (or program) procmail delivered
| to. If the last delivery was to several directory folders together
| then $LASTFOLDER will contain the hardlinked filenames as a space
| separated list."
|
| The definitely wrong part is "It always contains the name of the
| last file [...] procmail delivered to" implying that LASTFOLDER
| points to successful deliveries.
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".
No, not at all. I don't care about "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?
Yes, I only asked here for a better solution other than redoing all
the work by stuffing e-conditions all over my already bloated procmail
recipes.
The manually throwing away is a neccessary evil if one wants to have
multiple deliveries with different conditions/actions. The conclusion
is that these simple constraints are not really solvable with procmail
w/o converting the recipe files to a nightmare of double recipes for
manually checking what the MDA's job should had been.
I think maildrop is calling out for me.
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.
Oh, whatever - the should-be-unneccessary pairing is the issue not the
:0 e
You can even come up with a recursive-include scheme
Ouch() {
say "Ouch";
Ouch();
}
As an exersize for a class that would be nice, but in practice: I just
say fragile and (lack of) performance.
Anyway, I'm evaluating maildrop vs sieve. Looks like maildrop makes
the run.
Nevertheless, I'd like to thank procmail authors and maintainers for
giving me tool to last a decade.
--
Axel.Thimm at ATrpms.net
pgpE6jX7wuOKa.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