Subject: Re: Forcing requeuing on error

From: Roman Czyborra <[email-masked]>
Date: Mon, 4 Jul 1994 17:02:38 +0200

> |foldername

The pipe symbol doesn't belong in front of a foldername, but it seems
like it didn't sneak in until you were explaining your question.

> that works fine as-is - as that's totally procmail controlled - fail
> on write leads to requeuing.

I thought a failed write would lead to further processing of the
rcfile and eventually to saving in DEFAULT or ORGMAIL. Only if all of
that failed, an error would be returned.

> |program x y z means that procmail "gives up control", so if
> "program" fails on write...

Use the w flag to make sure program succeeds.  If it happens to be a
shell script set -e in it so it will terminate on error.

> So, my questions are: are there special exit values I could use in
> "program" that would tell procmail that a write had failed?

Any nonzero exit value will do.  If you feel like implementing a more
sophisiticated error handling look at <sysexits.h>.

> or would I be better of writing to a folder (so that procmail
> controls it completely), and then have another rule that then runs
> "program" on that folder?

Usually not,  piping directly to a program saves you the hassles of
extracting the message you want to process and deleting the original.

> Also, is there an environment variable that can be set in
> .procmailrc to tell procmail to requeue-on-error instead of
> bouncing?

No, if you want to requeue upon failure insert the following after
each recipe you want to force to succeed:

	:e
	{ LASTFOLDER=**Requeued** EXITCODE=75 HOST=done }

> My query comes about because at home my Linux system uses procmail
> as a local delivery agent, so if it isn't set to requeue in
> /etc/sendmail.cf, then it isn't available as an option to users
> unless they explicitly use a .forward file (which was the whole
> reason for putting procmail in Mlocal to begin with).

TRAP='[ $EXITCODE = 0 ] || exit 75' won't change the exit code if you
haven't set EXITCODE="", and after that it can no longer tell whether
the processing failed.  Seems like they will have to add the :e rule.