need a little help with .procmailrc

Web hosting discussion, programming, and shared and dedicated servers.
6 posts Page 1 of 1
by dja » Thu Jan 05, 2012 11:53 am
Hey Guys,

I've been racking my brain on this for a few days now and I still can't seem to get it. I'm piping my mail through a program that takes it's input through standard input and encrypts my mail to my public key (I plan on encrypting it to everyone's public key that's on the list so I can't just pipe it through gpg). When I call my program from the command line, it works perfectly so I've narrowed it down to it's interaction with procmail. Here's my procmail file:


:0 fbc
| /home/d/dja/bin/gpgspread.py



I've used this same recipe before but actually piping through gpg and using my public key and the pipe works, so I'm thinking it's something going on with my program.... not sure, any advice would be greatly appreciated. Thank you!
by augie » Thu Jan 05, 2012 5:02 pm
Does your program print back out to STDOUT after it works on the message?
by kgc » Thu Jan 05, 2012 5:23 pm
Enable verbose logging too!

LOGFILE=procmail.log
VERBOSE=yes

You'll want to comment it under normal operation. My first guess is to update the script to use the full path to gpg. However, python on the mail servers is quite (read very very) old. You might have better luck using bash or perl.
Kelsey Cummings
System Architect, Sonic.net, Inc.
by dja » Thu Jan 05, 2012 8:38 pm
Thanks for the help guys! I really appreciate it. I was able to get it to work but only after turning on logging. I was trying to figure out how to print out debug statements but I just couldn't figure it out. That totally helped! Thanks Augie, Thanks Kelsey! You guys are rock stars!

Kelsey, that was a good call on the Python. I have no idea what version of Python that is, but it's gotta be ancient. I was getting yelled at for trying to use split on a string. I figured that would have been in every version of Python, but for some reason it didn't like it.

Thanks again guys!

sidenote: piping your messages through a program that sends messages to your address is a bad idea! Exponential growth on an infinite loop! no bueno! Luckily, a while ago I setup a script that would mass delete messages out of my inbox based on sender or subject. ( I only added the last part about my mass delete tool as a means to redeem myself from the birdbrained mistake I made with that loop, lol!)
by kgc » Thu Jan 05, 2012 9:21 pm
Causing mail loops can also get you noticed by your (usually) friendly operator. If your procmail forwards mail in any way it is always a very good idea to put in loop protection. The easiest way to accomplish this is to add a header to your mail before you do anything else just after deleting (or delivering directly to your mail) every message with that header in it. This doesn't prevent problems if you are also calling a program in that can generate email but prevents you from causing loops if you later forward mail to another address.


#scan the entire message, including the body (in case you have a DSN that contains a copy of your message)
#and deliver it directly to Inbox (or if you prefer /dev/null also works.)
:0 B
* X-Loop: Been Here
$DEFAULT

#add your X-Loop header and then proceed as normal.
:0 fwh
| $FORMAIL -A "X-Loop: Been Here"
Kelsey Cummings
System Architect, Sonic.net, Inc.
by dja » Thu Jan 05, 2012 10:02 pm
thanks for that... definitely don't want to bug my local server gurus!!!

I'm totally stoked about what little knowledge I have about this, seems if one were to get good at formail and procmail, one could devise a system for almost-real time inter-machine communication just through email. very cool!

Thanks for the knowledge, if you'd like to impart any more wisdom to me, I'm all ears!!! Thank you, Thank you, Thank you!
6 posts Page 1 of 1

Who is online

In total there are 9 users online :: 0 registered, 0 hidden and 9 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: No registered users and 9 guests