1998-11-11-23:36:57 Joel Brooks:
I'm trying to create a simple filter for email based on subject line. My
ISP suggested I use procmail.
Good choice. It's a viciously cryptic tool, but it's fast, it's reliable, and
all of a sudden after a distressingly long hiatus it's even under active
development again.
Here is what I've been able to put together so far:
:0:
* ^Subject:.*Test Subject
/dev/null
I'd make two recommendations. First thing, put something like
LOGFILE=$HOME/.procmail-log
VERBOSE=on
at the top of your .procmailrc; this will tell you a lot about what's going
on. Leave those lines there; just comment 'em out with # when you're not using
them, as the "verbose mode" they enable is just dandy for debugging.
If .procmail-log doesn't get created after you enable this, then check your
$HOME/.forward and make sure you're really invoking procmail. If procmail is
in your home dir, a .forward might be as simple as
|/home/joelb/bin/procmail
and work fine. If you're using a system-wide install it might work a bit
better if you go something like
|/usr/local/bin/procmail#joelb
as the comment at the end will be stripped, but sendmail may notice it and
decide that your procmail invocation isn't the exact same delivery as someone
else's, and doesn't need exclusion locking from them.... The procmail(1) man
page recommends something really heroic like
"|IFS=' '&&p=/usr/local/bin/procmail&&test -f $p&&exec $p -Yf-||exit 75 #joelb"
I'm optimistic that the combination of horrible problems that that invocation
is designed to defend against won't be around to toast my hiney, but I may be
wrong.
So anyway, you're sure procmail really is being invoked for you, you're
getting logging in .procmail-log, you're set to really debug. I suspect the
problem with your recipe is that procmail is having trouble locking /dev/null.
But you don't need to get an exclusive lock on /dev/null, so leave off the
colon at the end of the first line:
:0
* ^Subject:.*Test Subject
/dev/null
-Bennett