procmail
[Top] [All Lists]

Re: newbie needs help with attachment filter

2003-02-18 20:05:58
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

<Prev in Thread] Current Thread [Next in Thread>