At 14:03 02-02-99 -0500, Stan Ryckman wrote:
formail -b to not escape
formail -f to not generate a From_
(I presume you were referring to From_ rather than From: )
Yes, but if one ALREADY exists, shouldn't it NOT be generating one? As I
read it, -f is supposed to force formail to _pass along any non-mailbox
format_, not generating a 'From ' line -- but since I DO already have one,
why wouldn't it be seeing that (besides, that's what it is splitting the
messages on)?
Also, I'm getting the escaping even when I use the -b on original delivery
(I kind of noted that in the last paragraph of my message).
I've done further testing - it actually _does not_ appear in my gzipped
archives, but _does_ appear when the message has been sent from procmail
into $DEFAULT (the mail spool). So apparently, it isn't a formail thing.
I tracked down the cause of the second "From " line in man procmail:
(3.11pre7)
When in explicit delivery mode, procmail will generate a leading
`From ' line if none is present. If one is already present
procmail will leave it intact. If procmail is not invoked with one
of the following user or group ids : root, daemon, uucp, mail, x400,
network, list, slist, lists or news, but still has to generate or
accept a new `From ' line, it will generate an additional `>From ' line
to help distinguish fake mails.
Though I'm not sure on the wording of "but still has to generate or accept
a new..." -- that seems to imply that it WILL ALWAYS do this.
Even with this vaguary, this explains why the >From is a new sight to me --
I was reprocessing the mail from within my user account, not as root, which
is what I'd done in the past.
However, it seems if you're delivering mail to YOURSELF (recipient user =
invoking user), this regenerated From line stuff should really be bypassed
(IMO).
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395