On Thu, Mar 22, 2007 at 04:02:24PM +0100, Axel Thimm wrote:
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,
Not sure why you call that "cheating," but whatever.
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 [. . . .]
and the check of LASTFOLDER implies that it was delivered which it was
not! So the mail is lost.
[. . . .]
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?
Well, I don't know of any documentation that implies that LASTFOLDER
is equivalent to a zero exit status. Why don't you check the exit
status? Hmm, I just checked, and a failed write doesn't affect
the exit status. Hmm.
Well, the e flag does work. If you're having file system trouble,
that would seem to be a useful thing to do.
:0
* conditions
{
:0:
badpermshere
:0 e:
errorfolder
}
Anybody see a cleaner way?
(I think you should find out what's going wrong with your filesystem.)
Dallman
____________________________________________________________
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