> > For more info as to why what we're doing is silly, see this post:
> > http://archives.neohapsis.com/archives/postfix/2002-04/1914.html
>
> Great theory, but poor in practice. If I can block any significant
> percentage of executable attachments by assuming a certain Base-64
> prefix, then that is always going to be an effective method to use _in
> addition to some other scanning method_. The Base-64 scanning is a
> very low cost alternative to a full virus scanner, and isn't silly in
> the slightest.
Huh? I don't see how shortening the prefix does anything except:
- improve accuracy of prefix match -- no Base-64'ed EXE files will
slip through
- prevent us from having to maintain a list of prefixes
> I suspect that, although that explanation is accurate as far as it
> goes, in reality the number of variants is going to always be small.
> The vast majority of executables are produced using some version of
> Micro$loth's tools, and the default DOS stub is going to be relatively
> invariant. Prefix matching should never be used instead of a full
> virus scanner, but it is a very effective way to block most Win32
> executables (without having to resort to file extension matching).
We *know* the virus writers are smart. They will find an easy way to
vary some number in the header, and blow out all but the short prefix
matching.
I don't see how it's a bad thing to only look for "TV"? We'd only
check for that if the mime header says it's base64'ed, and that's very
unlikely[1] to have a false positive.
-R
Footnotes:
[1] Obviously, there is still a chance, but there's always a risk.
