Michael Helm asked,
| I noticed something interesting, disturbing while testing
| some changes in procmail recipes ( cat message | procmail ).
You should save a process and write,
procmail < message
but that's not the reason for the problem.
| Given this rule:
|
| :0
| * ^TO_admin-pgp-public-keys
| /dev/null
|
| This is how it's interpreted on inbound mail:
|
| procmail: No match on
"(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparent
| ly(-Resent)?)-To):(.*[^-a-zA-Z0-9_.])?)admin-pgp-public-keys"
|
| This is how it's interpreted on "cat message | procmail"
Again, that's a poor way to feed a file to a command, but it isn't the
problem here.
| procmail: No match on
"(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparent
| ly(-Resent)?)-To):(.*[^a-zA-Z])?)_admin-pgp-public-keys"
|
| [in other words, as "^TO" + "_", not "^TO_"]
|
| Why the difference?
^TO_ is a recent introduction to procmail, but ^TO has been around longer.
Apparently your shell logins are using a version of procmail that doesn't
understand ^TO_ and does grok ^TO, while your incoming mail is fed to a more
recent release of procmail.
So either your incoming mail deliveries are handled on a different machine
from the one that takes your shell logins and they have different procmail
versions installed, or the procmail binary earliest in the $PATH of your
interactive sessions is older than the one that handles your incoming mail.