Re: newbie question / problem

At 09:14 2002-06-16 -0700, Scott Stark did say:
> Hi all, I'm pulling my hair out trying to figure out why I can't get 
> procmail to work here. Here's my recipe file:
It helps if you specify up front WHERE this file is located.  Even if the 
content might be taken to imply it's location in one place, perhaps that 
isn't where you've placed it.
> SHELL=/bin/sh               #Use the Bourne shell (check your path!)
The above is unnecessary if YOU actually have a proper shell defined for 
your account (as per /etc/passwd), which procmail will use by 
default.  OTOH, if this is in /etc/procmailrc, it may be necessary if some 
accounts explicitly don't have shell privledges (such as POP or FTP-only 
users who may have a special shell defined that tells them how they're not 
allowed to log into a shell -- such a program wouldn't interpret shell 
commands, but WOULD be their shell in the case of email).
> MAILDIR=/var/mail            #First check what your mail directory is!
This is the default dir in which procmail does things - loads path-relative 
rc files and stores path-relative mailboxes.  Chances are, this isn't 
appropriate if you're writing anything other than procmail-defined 
$DEFAULT, and in that case, $DEFAULT should have a full path 
anyway.  Consider carefully WHY you're setting this.
> LOGFILE=/home/procmail.log
Not, /home/(yourusername)/procmail.log, which would be $HOME/procmail.log 
?  Or, as a global log, /var/log/procmail.log (or even maillog.procmail)?
What sort of permissions does the logfile have -- I'd advise against it 
being readable other that (root) owner, since other users shouldn't be 
permitted to view statistics about mail to OTHER users ("hmm, user root got 
an email from so-and-so with a subject referring to me...").
> LOG="--- Logging ${LOGFILE} for ${LOGNAME}, "
I don't want to be pedantic here, but considering that you'd be VIEWING 
$LOGFILE in order to see this log entry, it's undoubtedly unnecessary to 
dump the logfile name into the log on each arriving email, don't you think?
You might also want to follow that with a newline.  Some of us define a 
variable:
NL="
"

(yes, the closing quote is on the following line), so that we can do:

LOG="--- Logging for $LOGNAME$NL"

Although you can emit the log with the closing quote on the following line 
- it is just often not pretty to see that throughout an rcfile, and the $NL 
construct helps define what you're doing.
I take it that this recipe is in /etc/procmailrc, rather than a personal 
.procmailrc file, since otherwise you wouldn't need to log the userid?
Note that /etc/procmailrc DOES NOT HAVE A LEADING DOT, unlike the 
~/.procmailrc file users use.
> :0:
> * $ ^To:.*PROCMAILTEST
> | /home/procmailtest.pl
Generally speaking, I wouldn't advise tossing scripts and other files into 
the /home/ dir.  It has no bearing on your problem, but it's something to 
keep in mind.  Run a orderly config, rather than depostiting files into 
places they shouldn't go.
Why are you using the $ flag on the conditions line?

> :0:
> ${DEFAULT}
If this is the last recipe in the file, $DEFAULT is, uhm, the default 
delivery action anyway.
> The "procmailtest.pl" script is a simple perl script that increments a 
> number in a file by one.
Note that if it is super-simple, you could use perl -e "contents of the 
script" to achieve this, which would keep the script logic local to the 
procmailrc file.  That isn't necessary, merely a possibility.
> When I send an email to PROCMAILTEST(_at_)hi-beam(_dot_)net, the message goes through 
> without, apparently, running the script or generating a log file.
Have you checked your system or maillog log files for error messages which 
procmail would emit as the LDA?  Is procmail ACTUALLY your LDA?  Have you 
verified this?
> I have been able to get procmail working using Timo Salmi's proctest script.
Timo's proctest is manually invoking your procmailrc file with 
procmail.  It won't demonstrate that procmail is your LDA, or in your 
.forward, one of which is necessary for procmail to be invoked 
automatically.  Thus, you can have a syntactically correct procmailrc, but 
your MDA isn't invoking it.
Sound familiar?

>  There is a line in the output from that script that says "Couldn't 
> determine implicit lockfile from /home/procmailtest.pl". Not sure what 
> that means, but it does successfully lock and execute the script.
It means that since you're delivering via a pipe (rather to a file, which 
would be the basis for the lockfile name), and there's no redirect (such as 
'procmailtest.pl >> somefile') from which it might determine the output 
file, it can't rationalize a guess as to what the lockfile name really 
should be.  How is it you know that it is successfully locking ANYTHING anyway?
Is there any message in the proctest log about the delivery FAILING, say 
because the invoked script doesn't read the full message?  Refer to Udi's 
post about some flags you should consider using if the perl script is 
really supposed to just be a counter and not an actual delivery (i.e. 
doesn't care what was passed to it because it doesn't read it).  I'd add 
'i' to the flags on that recipe as well - as per the manpage, it says "even 
if the invoked program doesn't read the whole message, procmail won't take 
that to mean that it failed to do what it was supposed to."
Although there are some minour syntactical issues with your script, none of 
them would be cause for your procmailrc to not be invoked.  At a minimum, 
you should get logging (though you should check VERBOSE=ON when testing, 
and certainly when you run into troubles), even if delivery to the perl 
script isn't just right.  It is likely your procmailrc isn't being invoked 
simply because procmail isn't your LDA.
Check out my disclaimer link for my 'procdiag' script, which will collect 
information about your system config - including (but only for sendmail 
MTAs though) what your LDA is.  Consider reviewing that script, then 
running it and reviewing the output -- it may identify your configuration 
problem.
---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail