When I suggested this code,
| > :0 fhw
| > * ! ^TOwebmaster(_at_)type2\(_dot_)com
| > * ! ^X-Loop: webmaster(_at_)bigkitty\(_dot_)azaccess\(_dot_)com
| > | formail -i"From: Mail_Filter(_at_)type2(_dot_)com" \
| > -rtkA"X-Loop: webmaster(_at_)bigkitty(_dot_)azaccess(_dot_)com" && \
| > cat path/to/spambounce.txt
| >
| > :0a
| > ! -t
Ken Hooper asked,
| I don't understand why "&&" in the fifth line. Is the logic that the first
| pipe might fail? Why would it fail?
Yes, the logic is that the first command might fail, and it might for any
number of reasons (but failures will be far rarer, if they ever occur, than
successes). If formail -r fails, we can't send the result out, so there is
no reason to take the trouble to cat the canned file. The action will return
failure, and procmail will recover the previous text and skip (`a' flag) the
forwarding action.
Likewise, if formail succeeds but cat fails, procmail will recover the pre-
vious text and skip the forwarding action.
| Why don't we just pipe the thing straight through?
If we put a semicolon between the two commands instead (or did something like
formail | cat - file), but then formail failed but cat succeeded, the action
would have a successful exit code and the filter would produce no real
headers, just the canned file (spambounce.txt) plus the original body. We
can't very well feed that to $SENDMAIL -t!
| I've never seen a recipe like the second one (well, that doesn't mean much
| given my experience)-- "! -t" accomplishes what "| $SENDMAIL -t" would?
Pretty much.