Re: newbie question / problem

Hi folks, well I'm going to have to embarrass myself and admit some 
ignorance here. First though, thanks to Sean and Udi for taking the time to 
help me out.
Most of the text from the .procmailrc file I sent was copied from various 
Procmail FAQ and example sources, so I didn't necessarily understand why 
they were there, such as "SHELL=/bin/sh" and "LOG="--- Logging ${LOGFILE} 
for ${LOGNAME}, ."  I've been a UNIX user for years but my understanding of 
it is limited. (That's probably obvious.) I tried a lot of different 
.procmailrc variations trying to get it to work in the simplest way, but 
for me it's kind of shotgun style, hoping I'd hit something.
Anyway some things I left out and a couple of questions (since I still 
can't get it to work). For simplicity purposes I won't intersperse my replies:
1. My path is not actually /home/.procmailrc; I just changed it to that 
rather than give the whole cumbersome path. My home directory is really 
/usr321/home/s/l/slugger4. That's where my .procmailrc and .forward files 
live, as does the perl script. (slugger4 is my login.)
2. My .forward file:

"|IFS=' '&&exec /usr/local/bin/procmail #slugger4"

(is there a way to specify the location of the .procmailrc file? I think, 
Sean, that's what you're implying I should do.)
3. My new .procmailrc file (in my home directory), based on your suggestions:

#SHELL=/bin/sh               #Use the Bourne shell (check your path!)
#MAILDIR=/var/mail            #First check what your mail directory is!
LOGFILE=$HOME/procmail.log
VERBOSE=yes
LOGABSTRACT=all

:0 hfwi
* ^To:.*PROCMAILTEST
| /usr321/home/s/l/slugger4/procmailtest.pl

4. My real intention is not to run the perl script of course, but to run 
hypermail to update a mail archive, based on the To: header. The perl 
script is just a useful check to see if procmail is working while I figure 
out hypermail.
5. I'm not sure about the MAILDIR variable; is it referring to the location 
of my actual mailbox (/var/mail) or should there be a Mail directory in my 
home directory? Would $HOME/Mail be better? I don't understand this. Do I 
even need to set this variable?
6. I don't see any log file anywhere. Where is this supposed to be? I 
assume since it's not getting created as specified in the recipe file, 
.procmailrc is not getting used at all.
7. What's an LDA? (I told you I'd embarrass myself.)

8. In answer to Sean's question " How is it you know that it is 
successfully locking ANYTHING anyway?", in the log file for the proctest 
script:
procmail: Couldn't determine implicit lockfile from 
"/usr321/home/s/l/slugger4/procmailtest.pl" 

procmail: Locking 
".lock"
procmail: Executing 
"/usr321/home/s/l/slugger4/procmailtest.pl"
procmail: Assigning 
"LASTFOLDER=/usr321/home/s/l/slugger4/procmailtest.pl"
procmail: Unlocking 
".lock"
procmail: Notified comsat: 
"slugger4@:/usr321/home/s/l/slugger4/procmailtest.pl"
9. Again, I've still not been able to get it to work, after using Udi's 
suggestions. My suspicion is the .procmailrc file isn't even being 
accessed, as nothing at all is happening.
Thanks again, and sorry if this is convoluted. I'm just trying to get a 
simple mail archive set up.
Scott


At 01:16 PM 6/16/2002 -0700, Professional Software Engineering wrote:
> 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 mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail