Procmail problems

[Lynn David Newton]

I've used procmail for since at least 2000, maybe
longer, so let me take a guess on this one.

  >> Current .procmailrc in my home directory is this:
  >> SHELL=/bin/bash
  >> MAILDIR=${HOME}/.Maildir
  >> DEFAULT=$HOME/.Maildir/
  >> LOGFILE=$HOME/procmail.log

  >> :0:
  >> * ^X-Spam-Status: Yes
  >> $MAILDIR/.Spam/

o You have a / on the end of your target. Did you mean
  $MAILDIR/.Spam ?

o I believe that target files need to pre-exist as an
  empty file. So then:

  cd $HOME/.Maildir
  > .Spam

  I might be wrong about that, but try it if it's not
  there.

  d.h> You might need to do something other than the /
  d.h> to indicate Maildir.

Don't know what d.h means by this. Mine is set as:

MAILDIR=$HOME/mail

... works fine that way.

  d.h> Don't forget your failsafe for when you work
  d.h> with procmail.

  d.h> # make a backup of all incoming mail before going on to sort mail...
  d.h> :0 c
  d.h> backup

  d.h> :0 ic
  d.h> | cd backup && rm -f dummy `ls -t msg.* | sed -e 1,200d`

Amen! d.h speaks truth on this one. That formula must
come from the man page, as it's byte for byte identical
to the first rule in my own .procmailrc, except I save
512 messages, not 200.

That backup has saved my butt on a lot of occasions.

One horrible, horrible, very bad and evil thing about
procmail is that if you get a rule wrong, it will
gladly throw away all your mail for you and you'll have
no way to recover it. So just do the backup as shown.

Be aware, too, that the order of rules is important. 
Which also means that mail may be discarded before it
even gets to some rule you think will handle it when
you don't realize it's already been flushed. So not
only do you waste a lot of time wondering why your rule
isn't working, you stand a chance of losing mail while
trying to debug it. (Or of forwarding penis enlargement
spam to your boss or some such other unpleasant side
effect.) All of which makes trying to debug .procmail a
real pain in the patushka, especially if you have a
large number of rules. And is why I rarely tinker with
it any more.

-- 
Lynn David Newton
Phoenix, AZ