On Wed, 25 Feb 2004, Matt Kettler wrote:
> SA's mime hander removes any octet-stream or other binary sections before
> running any rules, even rawbody ones.
> Thus, you cannot create a SA rule which will match attachment filenames for
> binary types.
As noticed earlier today, using the FULL test *does* permit scanning of
attachment file names, hence, the following works:
full LOC_DBLEXT /name="?[^"]*\.(?:html?|txt|doc|jpe?g|gif|wpd|pdf|zip)\.(?:pif|exe|com|cmd|bat|scr)/i
describe LOC_DBLEXT Message attachment has VIRUS-style double extension
score LOC_DBLEXT 0.5
In case line-truncation ate the first line, here it is, line-wrapped:
full LOC_DBLEXT /name="?[^"]*\.(?:html?|txt|doc|jpe?g|gi\
f|wpd|pdf|zip)\.(?:pif|exe|com|cmd|bat|scr)/i
Someone be kind enough to run this through a corpus for me?
- Charles
> SA's mime hander removes any octet-stream or other binary sections before
> running any rules, even rawbody ones.
> Thus, you cannot create a SA rule which will match attachment filenames for
> binary types.
As noticed earlier today, using the FULL test *does* permit scanning of
attachment file names, hence, the following works:
full LOC_DBLEXT /name="?[^"]*\.(?:html?|txt|doc|jpe?g|gif|wpd|pdf|zip)\.(?:pif|exe|com|cmd|bat|scr)/i
describe LOC_DBLEXT Message attachment has VIRUS-style double extension
score LOC_DBLEXT 0.5
In case line-truncation ate the first line, here it is, line-wrapped:
full LOC_DBLEXT /name="?[^"]*\.(?:html?|txt|doc|jpe?g|gi\
f|wpd|pdf|zip)\.(?:pif|exe|com|cmd|bat|scr)/i
Someone be kind enough to run this through a corpus for me?
- Charles