procmail
[Top] [All Lists]

LASTFOLDER blues

2007-03-22 09:00:55
Hi,

I'm a quite old procmail user (1 decade+), still I managed to get into
a dead-end, but maybe it's just my brain becoming rusty.

My setup checks for various mailing lists and then - if the mail
hasn't been delivered in one of them - for personal mail.

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,
e.g. non-forking). In order to still be able to tell whether something
had been delivered I'm using LASTFOLDER. So for example if after the
block processing the mailing lists is done I can query LASTFOLDER to
see whether the mail has been delivered at least once. and since most
actions happen within blocks I more or less close the recipe with

:0
* $ ! ${LASTFOLDER+!}
{ HOST=stop }

The setup worked for the last decade, but I never had any filesystem
issues in this decade. I now had a situation where the underlying
filesystem became read-only. This lead to delivery failures in the
block which didn't make procmail fail. That would be OK, if the
failures would had been noticed: The typical LASTFOLDER check was
*positive* because it is set *prior* to the attempt to write on disk.

So my logfile has

procmail: Locking "mbox-gmx.lock"
procmail: Assigning "LASTFOLDER=mbox-gmx"
procmail: Opening "mbox-gmx"
procmail: Error while writing to "mbox-gmx"
procmail: Unlocking "mbox-gmx.lock"

and the check of LASTFOLDER implies that it was delivered which it was
not! So the mail is lost.

Now, I've been checking where I went wrong. I want to have several
deliveries of the same mail based on different conditions. That means
that I need to hide delivery recipes within blocks. Error in delivery
actions don't cause procmail to stop, but it rather continues on,
hoping to be able to fulfill another recipe. I can't detect outside of
the block whether a delivery has happened or not, because the only
variable I can query (LASTFOLDER) is always set.

I think setting LASTFOLDER even when the action fails is a bug in
procmail, or at least undocumented behaviour. Nevertheless I can't
even find something to work around it. Do I need to pair every
delivery action with an :0 e action marking success or failure?
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpyNWxMioWdn.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
<Prev in Thread] Current Thread [Next in Thread>