Re: newbie question / problem

At 19:31 2002-06-16 -0700, Scott Stark did say:
> 1. My path is not actually /home/.procmailrc; I just changed it to that 
> rather than give the whole cumbersome path.
Useful to know, since a fair number of errors magically "go away" when 
people rewrite their recipes for public display.
> 2. My .forward file:
>
> "|IFS=' '&&exec /usr/local/bin/procmail #slugger4"
See my disclaimer page for a more elaborate forward construct, specifically:

"|IFS=' ' && exec /usr/local/bin/procmail -f- || exit 75 #youruserid"

You should VERIFY THAT PROCMAIL IS AT THE PATH YOU'RE SPECIFYING.  There's 
a few comments about the above syntax and the required permissions on the 
file there on my page.
> (is there a way to specify the location of the .procmailrc file? I think, 
> Sean, that's what you're implying I should do.)
No, I was saying that the constructs you were using would lead others to 
infer that you were writing an /etc/procmailrcs file 
_as_a_system_wide_filter_ ($LOGNAME really isn't of interest outside of a 
system wide filter, except occasionally for a generic filter that must 
access a user-specific file outside of their $HOME directory - similar to 
my comment about emitting "$LOGFILE" into the log, if it is a user-specific 
log, then $LOGNAME is redundant as well -- who else's email is going to be 
logged there?), and your logging and other path choices reinforces this, 
though you never said as much.  As such, your role as sysadm v. user also 
wasn't clear, and that affects what your access to changing system configs 
and referring to system logfiles is (my suggestion to check 
/var/log/maillog and whatnot isn't of much help if you're a vanilla user 
who CANNOT EVEN READ THE FILE in the first place).
> :0 hfwi
> * ^To:.*PROCMAILTEST
> | /usr321/home/s/l/slugger4/procmailtest.pl
Note that if the above were really a critical operation, and is writing to 
a file, that the perl script should perform locking on it, or the recipe 
should lock the execution of the script -- with an explicit lockfile 
name.  Since you declared that it is there just to demonstrate that 
procmail is in fact executing (which a successful logging operation would 
manage to do), then it isn't so critical (though it is a good idea to get 
into the habit of setting things up properly anyway).  I suspect my earlier 
comments about the lockfile - and how procmail determines the implicit name 
may have been confusing.
> 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?
Normally, users have some sort of mail directory in their home dir, which 
is where their user mail agent (Elm, Pine, Mutt, whatever) stores read 
mail, etc.  Is is to here which most mailboxes are presumed to be stored 
when you write a mailbox.  By specifying MAILDIR, you are in essence 
changing the current directory - filters and mailboxes which do not specify 
complete paths will be deposited in that directory.  If this is done, then 
delivering to a variety of mailboxes is made easier because you don't have 
to prefix each one with a hard-coded path or some other variable specifying 
the path -- you just use the mailbox filename.
Other users may do things differently, but I specify a separate variable 
and prefix for my procmail files:  $PMDIR, which keeps the procmail files 
"over there" (in a subdir off of my homedir, keeping the clutter out of the 
way), separate from my mailbox files.  I suspect you'll find most 
experienced procmail users do something similar.  Therefore, on an included 
RCFILE, you'd do:
        INCLUDERC=$PMDIR\somercfile.rc

Whereas, delivering to a sorted mailbox:

        :0:
        * somecondition
        somemailbox

somemailbox will be delivered to the file in the directory $MAILDIR, and 
the somercfile will be loaded from $PMDIR (which must be EXPLICITLY used in 
the path, otherwise it would assume $MAILDIR).
$DEFAULT should be your system mailbox file, and unless you know what 
you're doing, there should be no reason to change it (though if you do, you 
can always reset it to $ORGMAIL, which is your system mailbox -- EXCEPTING 
when your procmail script is being invoked from -m -- i.e. not as an 
LDA-delivered message, but invoked as a separate script).  If, at any time 
prior to the end of your filters, you need to take a "default" action, that 
isn't TO the system-defined $DEFAULT, then you don't need to redefine 
$DEFAULT in order to do so: you can specify the mailbox in that filter there.
That isn't to say that you will always just leave $DEFAULT defined as it is 
by the system, or that you'd never use $DEFAULT from within a recipe.  For 
instance, on a manually invoked rcfile - say from a system alias, or from 
within a sandbox (see my website), you can redefine it because the $DEFAULT 
wouldn't be the user mailbox.  On my sandbox for instance, I redefine 
$DEFAULT to be /dev/null -- I'm throwing messages at the test filter FROM A 
FILE WHICH I'LL STILL HAVE WHEN ALL IS DONE, and the only ones I want to 
have stored back to disk are the ones caught by the test filter - anything 
not addressed by the filter falls to the end of the test filter and gets 
discarded by default.
Because I still use a POP client for email, and I use procmail to insert 
tags for filtering, many of my delivery recipes resemble:
:0
* ^Sender: procmail-admin(_at_)lists\(_dot_)rwth-aachen\(_dot_)de
{
        :0c:
        | formail -A"X-some-identifier: PROCMAIL" >> $DEFAULT

        :0:
        |gzip -9fc >> procmail.gz
}

Yes, I tack a compressed copy into a file - this allows me to maintain 
volumes of email in much less space (though it isn't readable by a mail 
client right there on the server unless you extract it to an mbx 
first).  Note the delivery to default involves tacking an additional header 
on the message in the process.
> 6. I don't see any log file anywhere. Where is this supposed to be?
Well, according to your .procmailrc, it should be in your home directory, 
with the name procmail.log.
As an aside, since I archive my mail off of the server every so often 
(there's just so darned much of it, even when I compress), I put the 
logfile into the MAILDIR, so that when I move the mailbox files, the 
logfile which is associated with them comes along for the ride:
# dir must exist though
MAILDIR=$HOME/Mail
LOGFILE=$MAILDIR/log

(OTOH, this tosses a file into your mail dir which your MUA (Mail User 
Agent - the prog with which you locally manipulate mail) may want to list 
as a mailbox when you're choosing files to view, which isn't necessarily a 
bad thing anyway.)
>  I assume since it's not getting created as specified in the recipe file, 
> .procmailrc is not getting used at all.
A generally correct assumption.

> 7. What's an LDA? (I told you I'd embarrass myself.)
Local Delivery Agent.  Mail is not placed into the local mailboxes (whether 
though advanced filtering or not) by Sendmail or whatever your MTA (Mail 
Transfer Agent - "intersystem mail" if you will -- but which is still 
invoked to determine what is and is not intersystem) is.
> 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"
Which is "gee, I couldn't figure ANYTHING, so I'm using a default 
catch-all"  this is workable, but not ideal, since if you have other 
recipes that fail to determine an implicit lockfile, they'll be using this 
same default, and holding up unrelated deliveries.
> 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,
Q: have you gone to my disclaimer page and downloaded the procdiag script, 
viewed it, and executed it?  If you have too broad of permissions on files, 
that'll lead to procmail expressly ignoring your .procmailrc because of 
security issues.  Also, the .forward won't be necessary if procmail is 
already configured as the LDA, and if not, the PATH to procmail should 
still be verified ('which procmail' for instance).
Additionally, your provider may be using a different host for processing 
incoming email, which can provide some complications due to the way that 
your home directory gets mounted.
[big kersnip - no need to send it all back]

---
 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