How to use procmail to get a message into a variable

I'm trying to get changes logged by our RANCID install to be logged and sent to an internal comms broadcasting system we have. I can talk to this directly via netcat, for example this will work:

echo "Hello world" | netcat localhost 12345

RANCID sends changes by email, so I'm trying to use procmail to intercept these emails and get them send to our local pastebin and then pipe the response (which contains the URL) to netcat.

I can replicate this entire flow on the command line as follows:

testmail=$(cat testmail.txt)
URL=$(curl --silent -d "text=$testmail" -d "title=Logged Activity" http://paste/api/create) && echo "RANCID logged some changes: $URL" | netcat localhost 12345

Here is my .procmailrc at the moment:

## store the body in MESSAGE
:0 b
MESSAGE=|

##Send that message to Wirehive pastebin
:0
| URL=$(curl -d "text=$MESSAGE" -d "title=Logged Activity" http://paste/api/create) && echo "RANCID logged some changes: $URL" | netcat localhost 12345

Checking the mail log, the mail routing is working fine. With the file all commented out and checking the receiving users mailbox in mutt I can see the message come in. With the file uncommented the message does not appear in the mailbox, so .procmailrc is being processed and the message is passing in to it.

It's probably worth noting this is on Ubuntu 12.04.

The MESSAGE assignment does not work the way you wrote it. Try this:

:0b
MESSAGE=| cat

Furthermore, the URL=... assignment is not a valid command; you have to refactor the variable assignment to be outside the recipe:

URL=`curl --silent -d "text=$testmail" -d "title=Logged Activity" http://paste/api/create`
:0
| echo "RANCID logged some changes: $URL" | netcat localhost 12345

... or perhaps you could make it work by making it invoke a shell, typically by adding one of the SHELLMETAS:

:0  # notice semicolon at end
| URL=$(curl -d "text=$MESSAGE" -d "title=Logged Activity" http://paste/api/create) \
  && echo "RANCID logged some changes: $URL" | netcat localhost 12345 ;

... but I actually like the former, more readable alternative.

If you can somehow refactor the curl command line to read standard input and write to standard output, this could be made more elegant, at least so as to avoid the separate MESSAGE variable, and possibly even be refactored into just a one-liner.