At 19:29 2003-02-18 -0600, Joe Leske did say:
I'm testing a procmail recipe in my home folder. It's a .procmailrc file
which is invoked over a .forward file which is also in my home folder.
First, don't TEST recipes this way.  The URL in my .sig has a link to a 
setup which I refer to as a "sandbox", which is a test wrapper.  You can 
throw saved messages at it, and edit a message to have specific features 
and throw that at your recipe easily.  Without subjecting your regular 
email flow to a possibly bodged ruleset.
The purpose of the recipe is to redirect all emails with a .exe, .bat, .scr,
or .pif extension to a file called viruses located in the /home folder.
There are a lot more extensions you might consider quarantining.
I trust that you mean ~/ ($HOME) folder, not really /home.
Procmail version - 3.14
You should consider upgrading.  At least 3.15.2, if not 3.22 (I still run 
3.15 on my primary mailhost, because of an as-yet unresolved flag bug in 
3.22, though it generally isn't an issue).  The procmail history doc will 
identify for you some of the bugs which were fixed between 3.14 and 3.15 
(though no, none seem to have anything to do with your problem).
system mailbox - /var/spool/mail/root
Gaaak!
Let me give you a security suggestion here:
Alias your root (email) account to some less privleged account, and handle 
your email from there.  ESPECIALLY if you retrieve email from other 
terminals.  You should su to root only to perform certain administrative 
tasks.  Receiving email at that account promotes the unsafe practice of 
being logged in for lesser tasks.
When you bodge something as root, you're really going to hate yourself.
" | IFS=' ' && P= /usr/bin/procmail && test -f  $P && exec $P -f- || exit 75
# username"
Generally, there should not be a space between the hash and (true) 
username.  I'll assume that some extra spaces crept in with your posting 
process.  You're getting messaged _handled_ by procmail, so it's a given 
that it is being invoked.
BTW - you should check to see if procmail is already configured as the LDA, 
as the .forward would be unmecessary if that is the case.  Your MTA ia also 
a useful thing to know when discussing procmail configuration (moreso than 
the flavour of *nix even).
: 0 HB:
*^Content-Transfer-Encoding: base64
*name=.*\. (exe|bat|scr|pif)
/home/viruses
There are more precise recipes available for this, including:
        <http://www.johncon.com/john/QuarantineAttachments/>
The flags should start :0, no space between the : and zero.  That is the 
consitently provided syntax in the procmail manpages, and even if it works 
otherwise, sticking to the format provided is a good idea, if only for 
consistency.
procmail: No match on "^Content-Transfer-Encoding: base64"
procmail: Bypassed locking "/var/spool/mail/username.lock"
Note that this is a locking issue with the default mailbox, which your 
script is not directly delivering to (that is, nothing in your script is 
making reference to this mailbox).
You will find this message described in 'man procmail'.
procmail: Assigning "LASTFOLDER= var/spool/mail/jleske"
procmail: Opening "/var/spool/mail/username"
Which is it 'jleske' or 'username'?  Is this sloppy 
edit-before-emailing-personal-details, or is this what the logs ACTUALLY 
contain?
I'm suspecting this is an undedited log, and 'username' actually exists in 
the .forward file as 'username', quite literally.  That should be the 
actual username of the host account.
(I access the linux  mail server by using ssh in the putty.exe application
from an NT 4 Server)
Not an issue.
I want to know how to (if it's possible) run this recipe in everyone's home
folder without getting the bypassed locking message.
Properly, you'd do this from /etc/procmailrc, and you'd set up procmail as 
the LDA, so that it would automatically be invoked on local message 
delivery --whether the individual users invoke procmail or not, which in 
turn spares you setup work each time a new user is added, or if users might 
mangle files in their home dirs.
As per the manpages, /etc/procmailrc confers special capabilities to 
procmail when run as an LDA - unless you use a DROPPRIVS within the 
/etc/procmailrc, it is executed as root (meaning that it can do thing "for" 
the users that they couldn't do themselves).
I've covered a variety of methods which one can allow for selective user 
participation in an /etc/procmailrc rule (more commonly to allow some users 
to opt out of spam checking and the like).  If you hit the list archives, 
you can find posts from me on the topic.
If this isn't an option, is it possible to run procmail as my LDA with my
configuration? If so, how do I run procmail as my LDA?
Check with your (undisclosed) MTA configuration.  For all we know, procmail 
is already your LDA.
P.S. - If at all possible, I'd like to use the version of procmail I have.
Is it ok to use 3.14 for what I wanna use it for, or will I have to install
a new version?
Newer versions have known bugs squashed.  Refer to the revision history at 
<http://www.procmail.org/>
P.S.S. - If there's any important info I forgot to include with this email
please let me know.
Your MTA.  Perhaps there's someone using the same *nix distro as you, but 
it's better to provide that information up front.
Also, linked from my disclaimer page is a diagnostic script, 
procdiag.sh.  It can help identify some common configuration screwups, and 
extracts configuration data such as your LDA if you're running sendmail.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.391 / Virus Database: 222 - Release Date: 9/19/2002
Uh, I've mentioned it to other people in the past - people would be 
_stupid_ to believe that because a message claims that it is virus free 
that it is in fact virus free.  Mark my words - viruses will appear with 
footers like this on them someday, and the suckers who go ahead and launch 
attachments because they believe the message is safe (not having run 
trusted A/V from their end) will be in for a surprise.  Don't buy into the 
farce.
---
 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