[PLUG] Need help w/ a procmail recipe
Travis Spencer
travislspencer at gmail.com
Tue Dec 20 09:15:07 UTC 2005
On 12/18/05, Steve Beattie <sbeattie at suse.de> wrote:
> On Fri, Dec 16, 2005 at 12:35:10PM -0800, Travis Spencer wrote:
> > LOGABSTRACT=all
> > PATH=$HOME/bin:$PATH # munpack is in $HOME/bin.
> > TMPDIR=/tmp/procmail.$$
> > TRAP="rm -rf $TMPDIR; $TRAP"
> > VERBOSE=yes
> >
> > :0 Wic
> > * ^Content-Type: multipart.*
> > |mkdir -p $TMPDIR
> >
> > # Message is multipart/alternative. First part is text
> > # and should be discarded. Second part is HTML and should
> > # be converted.
> > :0 w
> > * ^Content-Type: multipart/alternative.*
> > |munpack -t -C $TMPDIR && \
> > lynx -dump -force_html $TMPDIR/part2 | \
> > cat -s
> >
> > # Message is multipart/mixed or related. HTML is first part.
> > :0 w
> > * ^Content-Type: multipart.*
> > * ! ^Content-Type: multipart/alternative.*
> > |munpack -t -C $TMPDIR && \
> > lynx -dump -force_html $DIR/part1 | \
> > cat -s
> >
> > :0:
> > other
...
> Perusing my own .procmailrc, all the rules I have that act as filters
> are prefixed with:
>
> :0 fw
>
> rather than just the bare:
>
> :0 w
>
> that you have, so you might try that.
Adding the `f' did cause the other two recipes to be considered after
the first was applied. Thanks for that; however, the results are
still not what I was hoping for. After telling procmail that the
first recipe is a filter, the log entries it produces are like this
one:
procmail: [17988] Tue Dec 20 00:56:06 2005
procmail: Match on "^Content-Type: multipart.*"
procmail: Executing "mkdir,-p,/tmp/2005-12-20-00-56-procmail-17988"
procmail: Assigning "LASTFOLDER=mkdir -p /tmp/2005-12-20-00-56-procmail-17988"
>From foo at yahoo.com Sun Dec 4 22:41:19 2005
Subject: Some subject
Folder: mkdir -p /tmp/2005-12-20-00-56-procmail-17988 5312
procmail: Match on "^Content-Type: multipart/alternative.*"
procmail: Executing "munpack -t -C $TMPDIR && \
lynx -dump -force_html $TMPDIR/part2 | \
cat -s"
procmail: No match on "^Content-Type: multipart.*"
procmail: Locking "other.lock"
procmail: Assigning "LASTFOLDER=other"
procmail: Opening "other"
procmail: Acquiring kernel-lock
procmail: Unlocking "other.lock"
Folder: other 1398
However, if I delete the file `other', touch it, list it and see that
it is a zero byte file, run my test script that executes procmail with
the given recipes, and list the file `other' again, it is still zero
bytes. If I run the command
munpack -t -C $TMPDIR < ~/misc/procmail/foo at yahoo.com.txt && \
lynx -dump -force_html $TMPDIR/part2 | \
cat -s
The output to the screen is a beautiful text message :/
> A couple of other misc notes, not related to the issue you're having:
>
> - you might wrap up everything into a script, so that you don't have
> to have that funny rule+trap to mkdir/rmdir.
Perhaps I'll do this, but then I have to remember to transport the
script too if I need/want to use the recipes on a different box.
> - /tmp/procmail.$$ is a pretty guessable/DOSable path, use mktemp(1)
> (and create/use a ~/tmp/ as well)
I don't have mktemp available to me on Solaris where I do some of my
work. I try to use stuff in Linux that will be portable to that OS
too in case I need to use it there too. (Of course I can't always do
this, but I try when I can.) However, I did switch the declaration of
`TMPDIR' to this:
TMPDIR=/tmp/`date +%Y-%m-%d-%H-%M`-procmail-$$
I'm not sure if that is safer because I don't understand how naming a
file `/tmp/procmail-1234' could lead to a denial of service. (I'm
sure it could, but I just don't understnad how.)
> HTH.
It certainly did. Thanks, Steve.
--
Regards,
Travis Spencer
More information about the PLUG
mailing list