-----Original Message-----
From: Dallman Ross
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.
I read about that bug but I didn't feel it was relavent, plus I wasn't
sure the bug was still "alive" being that it was from 2+ years ago. I'll
remove it and see if the recipe functions the same.
Nancy's page is very valuable and informative. I have yet to read it all
so thanks for point out even though I had it bookmarked already.
In the comment on the 'Hhb' default however it seems to imply that if
you do use flags in a recipe, the defaults will not be implied. Thus if
I were to do a ':0 B' then the headers would not be checked (i.e. the
'B' overrides the defaults). Is this correct or no?
*^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
I've looked at your tool and might try it out. I'm just taking one thing
at a time and trying to understand how it all works. Learning IS
reinventing the wheel so to speak. :)
{
: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.
I think some of the above should be put into context so here is the
complete recipe:
#####
:0
*^Content-type: (multipart/mixed|application/octet-stream)
{
:0 HB
*^Content-Disposition: (attachment|inline);
*filename=".*\.(vbs|wsf|shs|exe|chm|pif|vbe|hta|bat|cmd|com|hlp|jse|pcd|
reg|scr|lnk|url|cpl)"
{
SHELL=/bin/sh
:0 f
|/usr/bin/demime -
:0 fhbw
|/bin/sed \
- -e 's/^Subject:/Subject: **ATTACHMENT REMOVED**/'
:0 c
/tmp/virus
}
}
#####
My bad for not putting the whole thing out previously.
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
Never said I didn't know HOW to test, just that I needed to test it. :)
I was looking for input on how to make it better. So far it works but I
figured it probably isn't the greatest way to do it.
One thing that I did find out (from testing) is that the demime call has
to be '|/usr/bin/demime -' not '|/usr/bin/demime' as Google Kreme had
posted. The '-' is a special switch that directs all the out put back to
STDOUT instead of handling it internally. This is confirmed on another
mailing list that I reviewed the archives of.
I'll look into formail more but please review the "complete" recipe and
let me know if it changes your feedback.
Thanks all for the help.
Paul P.
____________________________________________________________
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