See:
<
http://www.securityfocus.com/templates/archive.pike?list=1&
date=2000-07-15&msg=75256BFE0332D4118969009027E77E7C0FB7BB@
static-5-14.dhcp.nai.com>
.asd files bypass macro security options in Microsoft word. :^(
So, I add .asd to a definition, re-run m4 to get a filter file
(basically the one posted to the list) and send an announce. And it
doesn't get through.
So I check the logs for that message. Entries such as:
2000-07-30 17:32:49 13Iuqp-000Ntg-00
Error in message_filter file:
string is too long in line 26 of filter file (max = 256 chars)
(whitespace fiddled for clarity)
The currently commented-out section has this:
#if $message_body matches "(?:Content-(?:Type:\\\\s*[\\\\w-]+/[\\\\w-]+|Disposition:\\\\s*attachment);\\\\s*(?:file)?name=|begin\\\\s+[0-7]{3,4}\\\\s+)(\"[^\"]+\\\\.(?:vb[se]|ws[fh]|jse?|exe|com|bat|chm|cmd|pif|sh[sb]|hta|asd)\"|[\\\\w.-]+\\\\.(?:vb[se]|ws[fh]|jse?|exe|com|bat|chm|cmd|pif|sh[sb]|hta|asd))[\\\\s;]"
#then
Which, as the log says, has a pattern string which is too long.
I've temporarily commented out the $message_body match, leaving us with
the $header_content-type: one.
I thought of re-compiling with a larger constant, but I want to
double-check here first. It's our company's mail gateway. :^)
filter.c has a stack-stored buffer[256] in read_condition(). This size,
via sizeof(), is then passed to the function nextitem(). However, a
large number of exim functions (in other files) also use a hard-coded
256 character array. So - is it safe to simply increase the size of
this one buffer in read_condition()?
Or is this opening an unpleasant can of worms?
I'm reluctant to stretch it to a third pattern match on all incoming
mails, just to break up the string size.
Thanks,
--
"We've got a patent on the conquering of a country through the use of force.
We believe in world peace through extortionate license fees." -Bluemeat
