procmail
[Top] [All Lists]

Re: Bouncing messages (was Re: Uses for HOST in procmailrc???)

1996-01-20 22:31:15
cc: pakp(_at_)cs(_dot_)acu(_dot_)edu, 
procmail(_at_)Informatik(_dot_)RWTH-Aachen(_dot_)DE
Date: Sat, 20 Jan 1996 23:00:19 -0600
From: Philip Guenther <guenther(_at_)gac(_dot_)edu>

David Mazieres <dm(_at_)amsterdam(_dot_)lcs(_dot_)mit(_dot_)edu> writes:

[I want to put information in a bounce message by writing to stderr
of procmail...]

Yes, but how do you write to procmail stderr from within the
procmailrc.  Anything I send to stderr from a "|" or "``" ends up in
my logfile instead.

Uh, hmm, scratch, pause, wellll...

After reading through the source again (3.11pre3), I begin to recall
that this has come up before, and the answer then was "once you set
LOGFILE, you can't get to stderr ever again".  The workaround (as
opposed to a solution, which this isn't) is therefore to place anything
that needs to see the original stderr at the top above the setting of
LOGFILE.  I still think this is a bug, or at least 'non-optimal behaviour',
but as I can't think of any particularly elegant ways to have procmail
do otherwise, I haven't complained very loudly.

I commented out the LOGFILE line, and this works.  Unfortunately, I
would really like to be able to log mail messages.

I can't move my bounce message echoing to the start of my procmailrc
before setting LOGFILE, however, because I only decide to bounce the
message after I have tested it for delivery to a number of different
mail folders.  (And actually, I currently even bounce some messages
that I do deliver to some files... though I know this is a bad idea.)

I guess I may have to hack my procmail source.  If so, what do people
think about the following possibilities:

  * Dup the stderr file descriptor and make it some well known
    file descriptor, like 3.  This would require setting SHELL to
    /bin/sh because csh closes all file descriptors above 2, but I am
    willing to live with that.

  * Add a fake variable STDERR, which if you say "STDERR=foo" will
    write foo to the original standard error of procmail.

Any comments?  Any possibility of getting this or a more elegant
solution into procmail?

Thanks,
David