Kyle Ferrio gave us more detail:
Well, that is a problem right there. Maybe you don't want logabstracts in
the normal course of things, but if you're debugging you should try to get as
much information as possible. Set LOGABSTRACT to ALL for now.
| * ^Subject:.*gimmie
| * ! ^Subject:.*Re:
| | /bin/echo "Take that." > $HOME/gift
| If I send mail with subject 'gimmie' to myself at "user", I get the
| intended 'gift' file in my home directory.
| If instead I send the same mail to myself at "user(_at_)FQDN", I get no file.
I'd guess at first that it was some weird permission problem, but if you
get log entries either way, procmail must have the permissions it needs.
And if you get log entries either way, procmail is getting invoked for both
kinds of addressing.
| Apparently procmail thinks the pipe went ok, but it didn't in the second
| case, which is obviously the case that matters.
Without a `w' or `W' flag, procmail will think that the pipe went ok as long
as the command -- or in this case, the shell that runs the command, because
you have a character from $SHELLMETAS there -- accepts the input. I'd recom-
mend an `i' flag as well, since the command won't actually use the input.
But definitely try a `w' and look at the logs again.
I wonder if perhaps the problem is that mail to "user" stays in that machine,
whereas mail to "user(_at_)FQDN" bounces off another machine and back, so its
extra Received: headers make it just long enough that it needs a second
write; but then why would $HOME/gift not even get created? So that's not
likely, but it's easy enough to test by putting a `b' flag onto the recipe
so that only the body is written to $HOME/gift, and it will be the same
length whether you write to "user" or to "user(_at_)FQDN".