Sean Straw told us more about his >From_ trouble:
| 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.
That will also happen if you use procmail's -f option. It's definitely
procmail, not formail, at work. You can prevent it by setting TRUSTED_IDS
to {0} in config.h before you compile.
Sean, does your .forward invoke procmail with the -f option?
| 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.
It should do it only if the From_ line is *new*, then ... generated in the
absence of one or accepted with a change per the -f command line option.
| However, it seems if you're delivering mail to YOURSELF (recipient user =
| invoking user), this regenerated From line stuff should really be bypassed
| (IMO).
You're doing it -d yourself? Why? If procmail is already running as user
pse, what is the purpose of -d pse? Anyhow, when I try procmail -d dattier
with a 3.11pre7 binary where I'm not compiled in as a trusted user, there is
no extra >From_ added. Maybe it's different if it's invoked interactively
from a shell process already running as me rather than from .forward?