Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
I ran into a similar problem when setting up procmail initially and found that I did not need the .forward; Local mail delivery (Sendmail) config may already be set to invoke procmail (which looks for your $HOME/.procmailrc); Procmail log can be set with the "LOGFILE" variable. Make sure any dir's named in variables actually exist or are created before .procmail is set to run; So .procmailrc could look something like the following: SHELL=/bin/bash PATH=/bin:/usr/bin:/usr/local/bin:/export/home/IMeMine MAILDIR=/export/home/IMeMine/Mail MBOXDIR=/var/mail/IMeMine LOGFILE=$HOME/procmaillog LOCKFILE=$HOME/procmail/.lockmail CURMONTH=`date +%Y%m` # VERBOSE=ON # 4 Lines below are extra; they create a numeric name for a directory for each # month under your $HOME/Mail dir - named like: yearmonth # (yyyymo); # Still have to cleanup periodically; Nice thing: each month has # a separate log - so the file size doesnt get excessive... :0 Wic * ? test ! -d $MAILDIR/$CURMONTH |mkdir $MAILDIR/$CURMONTH DEFAULT=$MAILDIR/$CURMONTH LOGFILE=$DEFAULT/procmaillog :0 BHh * ^Content-Type: multipart/(mixed|alternative) * ^Content-Type:.*(audio/x-|application|x-rasmol) * name=.*\.(scr|com|bat|pif|lnk|exe) { :0 $HOME/sobig.f } . . (various and sundry recipe lines...) . # Catch-all recipe just in case - at the end... :0 * . { :0 $MBOXDIR } Hope this helps... -Louis ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Wed, 24 Sep 2003, Duane Morin wrote: Message: 2 Date: Wed, 24 Sep 2003 22:43:33 -0400 (EDT) From: Duane Morin <dmorin at lear.morinfamily.com> To: discuss at blu.org Subject: Debugging procmail I'm trying to get procmail running (thanks for the recipes!) but nothing's happening. I know that my .forward file is being invoked because if I make it equal to just another email account, email is forwarded. So, .forward equals: "|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #dmorin" So far so good? I know that procmail is in /usr/bin/procmail. The thing is that nothing seems to be happening with procmail at all. I can't even really tell if i have a syntax error. Here's the file, it's an assortment of things I'm trying to get some evidence that it's working: # Copy all incoming messages to backup folder :0 c backup # If message is to Microsoft anything, move to spam :0: * ^TO*icrosoft spam # Got these from the list, sobig/swen killers. # http://www.xs4all.nl/~rsmith/spamblock.html # gaaaah! :0 BHh * ^Content-Type: multipart/(mixed|alternative) * ^Content-Type:.*(audio/x-|application|x-rasmol) * name=.*\.(scr|com|bat|pif|lnk|exe) $HOME/sobig.f I am still regularly getting mail with MS attachments. There's nothing in my backup directory, nor is there a sobig.f file or directory. Clues? Is procmail dumping its output someplace I can look? Duane --__--__-- Message: 3 Date: Thu, 25 Sep 2003 00:01:38 -0400 (EDT) From: Chris Devers <cdevers at pobox.com> Reply-To: Chris Devers <cdevers at pobox.com> To: Duane Morin <dmorin at lear.morinfamily.com> Cc: discuss at blu.org Subject: Re: Debugging procmail On Wed, 24 Sep 2003, Duane Morin wrote: > Clues? Is procmail dumping its output someplace I can look? I think we may need more information about your set up -- what mail server software are you using, and are you sure it is invoking things properly, etc. Without knowing a little bit more, the most I can do is guess -- but maybe others can glean more than I can :-) That said, one of the best things you can do in your ~/.procmailrc is to generate a log file. That'll at least tell you if procmail is being invoked in the first place. It's great for debugging, and personally I like leaving a `tail -f` running on my log file to let me know what mail I have coming in & where it's getting filed away. My ~/.procmailrc was written mostly by reading Nancy McGough's tutorials at <http://www.ii.com/internet/robots/procmail/qs>. (Note: url is LONG, not very well organized, occasionally repetitive, etc -- but there is a lot of decent information there.) I've pasted the relevant bits from my ~/.procmailrc below; feel free to use & adapt it as you see fit: # Next may be needed if you invoke programs from your procmailrc # Details in Check Your $SHELL and $PATH in Troubleshooting below SHELL=/usr/bin/bash # Directory for storing procmail configuration and log files # You can name this environment variable anything you like # or, if you prefer, don't set it (but then don't refer to it!) PMDIR=$HOME/.procmail # Put ## before LOGFILE if you want no logging (not recommended) LOGFILE=$PMDIR/log # To insert a blank line between each message's log entry, # uncomment next two lines (this is helpful for debugging) LOG=" " # Set to yes when debugging VERBOSE=no # Remove ## when debugging; set to no if you want minimal logging ##LOGABSTRACT=all # Replace $HOME/Msgs with your mailbox directory # Mutt and elm use $HOME/Mail # Pine uses $HOME/mail # Netscape Messenger uses $HOME/nsmail # Some NNTP clients, such as slrn & nn, use $HOME/News # Mailboxes in maildir format are often put in $HOME/Maildir # NOTE: Upon reading the next line, Procmail does a chdir to # $MAILDIR and relative paths are relative to $MAILDIR MAILDIR=$HOME/mail # Everything above has been "infrastructure", setting up how the # procmail system will work for me. The next few lines call in # the actual recipes. Once nice thing about doing it this way is # that it's easy to comment out a whole block of rules if needed, # or rearrange the order in which they get called, etc. INCLUDERC=$PMDIR/personal_mail INCLUDERC=$PMDIR/antispam INCLUDERC=$PMDIR/work INCLUDERC=$PMDIR/mailing_lists # Messages that fall through all your procmail recipes are delivered # to your default INBOX If you don't see anything useful to you here, you may want to look at samples from dotfiles.com too. There is a decent collection of config files for various tools there, including procmail. -- Chris Devers --__--__--
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |