On Thu, Jan 20, 2005 at 07:20:45PM -0600, Pettit, Paul wrote:
-----Original Message-----
Google Kreme
On Thu, 20 Jan 2005 17:33:51 -0600, Pettit, Paul
<ismanager(_at_)ccbnpts(_dot_)com> wrote:
:0
*^Content-type: (multipart/mixed|application/octet-stream)
^Content-type:.*(multipart/mixed|application/octet-stream)
{
:0 HB
Don';t use H
Is that because procmail parses the Header by default or is that just a
personal preference?
1) Because it's the default; 2) because there is a known procmail
bug that if you turn it on there you can never subsequently turn it
off. See, e.g., Nancy McGough's QuickStart pages, which highlight
the old discussion about that point.
*^Content-Disposition: (attachment|inline);
why?
Why not?
To date this filter has worked 100%, in my experience if it isn't broken
don't fix it. All I want to do is "add" to how the filter works but if I
can't then the filter keeps plugging away. :)
I believe that not all attachments will have a Content-Disposition header-
field.
Here, from my handy-dandy running-last-200 virus stash:
2:03pm [~/Mail/virus] 239[0]> grep -l -i ^Content-Disposition: msg.* | wc -l
144
2:03pm [~/Mail/virus] 240[0]> egrep -l -i '^Content-Type:.*(attach|multi)'
msg.* | wc -l
200
So 56 of those would have gotten through.
*filename=".*\.(vbs|wsf|shs|exe|chm|pif|vbe|hta)"
This will work for most, but will fail if there is a new line, which
there often is in bad attachments:
filename =
"badfile.src"
Never thought of that but so far I've never seen one slip through
because of that. Lucky maybe? I'll have to think up a way to cover for
this. Good catch. :)
You are reinventing the wheel, anyway. There are several procmail-based
anti-viral plug-ins available. Not the least of which is one by some
dude named Dallman Ross. http://vsnag.spamless.us
{
:0f
| /path/to/demime
SHELL=/bin/sh
why?
Again, why not?
As far as I know it's to give a shell to run sed in. In all the examples
I've seen SHELL is defined.
You are setting the shell after the fact of our pipe to the shell.
This is like locking the barn doors after the horse was stolen.
Procmail is a linear programming environment; things happen in order of
incidence or appearance. A shell assignment should come very near the
top of your rcfile.
:0 fhbw
|/usr/bin/sed \
- -e 's/^Subject:/Subject: **ATTACHMENT REMOVED**/'
again, why?
This is to prepend the message to the original subject that an
attachment was removed.
I don't have your original message anymore, but I suspect Kreemy was
objecting, in addition to the needless sed statement, to running the hb
flags. You are operating on the header only, and you do not want or
need the b flag.
# Define $WS to contain a space and tab
:0
* $ ^Subject:$WS*\/[^$WS].* { SUBJECT=$MATCH }
:0 f
| formail -I "Subject: ATTACHMENT REMOVED (Was $SUBJECT)
Different method but same result as far as I can tell. The sed regex
statement does a fine job with low overhead so why switch it?
1) Its overhead is not all that low.
2) Formail's overhead is very low; about the lowest around for
rewriting a header.
3) It's precisely the job procmail was written for and part of
why it comes in the procmail package.
Didn't really answer the original question, will the modified filter
work? From what I can infer, it will but it'd be nice to know for
sure. I will test it out and let you know.
Brush up on running a diagnostic "test harness" or "sandbox." If you
search the list archives at www.procmail.org or look at Nancy's
QuickStart, you can find many references to this. Then you can test
easily, out of the loop of your live mail system and without having
to wait for mail. Also, a simple "point-n-shoot" testing script
comes with the Virus Snaggers(tm) package (link above).
--
dman
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail