[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