procmail
[Top] [All Lists]

Re: One more time - how to re-process messages without

1999-02-02 22:16:29
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?