Axel Thimm <thimm(_at_)physik(_dot_)fu-berlin(_dot_)de> writes:
Stan Ryckman <stanr(_at_)sunspot(_dot_)tiac(_dot_)net> writes:
<deleted>
Since this trick is not very intuitive, I'm wondering what's wrong
with something easier to remember (and to explain!) such as:
:0:
* LASTFOLDER ?? .+
{
...etc.
Am I missing something?
Also could one use DELIVERED instead? You would have to nest the actions and
set DELIVERED cluttering them up, which is not nice. But as I understand (can
of course be completely wrong :) DELIVERED is used to flag (to mailer) the
delivered status w/o stopping processing the mail. The last rules would ask
this variable if it has been delivered and store it to a default folder, if
not.
The drawback is nested (bigger, ugly and slower) rules, but it seems to fit
the semantics better.
DELIVERED does not do what you think it does. It doesn't affect
procmail's processing in anyway, except that procmail will return
success even if it can't deliver it at all. In fact, procmail will
fork, and the parent will instantly return success to the mail system,
leaving the orphaned child to continue processing of the .procmailrc.
Note that this doesn't stop procmail from attempted delivery to DEFAULT
or ORGMAIL.
For all the questions I've answered or seen answered on this mailing
list, only once have I seen a case where setting DELIVERED was useful,
and that was for a rcfile run via procmail -m. Looking back through my
outgoing mailbox, I see that there was actually another, cleaner method
of solving the problem in that instance, so I guess you could say that
I have never seen an actual need for DELIVERED.
Philip Guenther