On Tue, 2003-12-09 at 15:42, jpff@??? wrote:
[Hmm.. was the original directly sent to the list - if so where did it
bounce?]
> For some time we have had a system filter derived from Nigel
> Metheringham's one to catch Windows executables, and return a polite
> message saying that we do not accept raw executables, and please zip
> it if the sender really meant to sent it. At some stage, unknown, but
> possibly when upgrading to exim4, this ceased to work always. It
> works when executables are mailed from inside (we can test that
> easily), but we noticed (well actually I noticed and questioned) that
> the "Microsoft Security patches" malware was getting through, although
> it contains an .exe file.
You can't reliably parse mail/mime headers out of a message with a
regexp so the filter approach was doomed to failure.
> I suspect that with exim4/exiscan one should use the demime option in
> acl_check_content to set acl_m0 and then have a router that fires on
> that and does the mail to $return_path in a pipe transport. Is the
> accepted way, or is there some simple thing I have missed?
Don't send an autoreply back - if you do then you just end up spamming
lots of people when the next worm comes out that sends copies of itself
using forged sender addresses. Instead reject the transaction within
the SMTP session, ie I use:-
# Reject known virus spreading file extensions.
# Accepting these is pretty much braindead.
deny message = contains $found_extension file (blacklisted).
demime =
exe:com:vbs:bat:bas:ade:adp:chm:cmd:cpl:crt:eml:hlp:hta:ins:inf:isp:js:jse:lnk:mdb:mde:msc:msi:msp:mst:pcd:pif:reg:scr:sct:shs:url:vbe:wsf:wsh:wsc:doc
[NB this is on the exim.org machine - you may consider rejecting .doc
files to be too aggressive, but that machine has no need to accept them]
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
