My logic of blocking certain sorts of attachments outright
Once we started knowing more about what sort of attachments our
users get (both good and bad), as we now do,
we drifted into the obvious next step of starting to block some of
them. Our current set of blocks are conservative and have basically
been drive by seeing what our commercial anti-spam package already dislikes. Is it identifying basically
everything with a single
.js file in a ZIP archive as bad? Well,
let's just go ahead and block those outright.
Now, there's a perfectly sensible question that one could ask here: if our anti-spam package is already detecting this stuff as bad, why bother doing anything to preempt it? We're essentially going to some amount of effort to duplicate work that's already being done for us.
(How we do this may result in somewhat less load on the overall system, but our external email gateway system isn't particularly burdened in the first place so this isn't something we care about.)
My biggest reason for arguing in favour of general early blocking
is simple: it's unwise to count on recognizing all malware.
Unless the commercial package we use has adopted rules that are
just as general as ours (and we can't tell, it's a black box), it's
using some sort of signatures or pattern analysis or recognition
system to pick out malware. It may be batting a thousand on those
.js files now, but there's no guarantee that this will
always be the case; at some point in the future the
may mutate so that the package doesn't recognize it for a while.
So where we can use them, our general blocks act as a safety backstop
to the more nuanced detection that the commercial package is doing.
(There are cases where we can't use general blocking. Our users get
a certain amount of legitimate Java
.jars and Office documents
with macros, so we can't block either of those outright despite
both of them being vectors for malware. Instead we have to cross our
fingers that the commercial package's recognition is good enough and
our users will be sufficiently suspicious of anything that does slip
In our situation a secondary reason is to shield the commercial anti-spam package from having to apply potentially buggy code to potential malware files. The package definitely has had bugs in the past and probably will in the future; if we're sufficiently confident that we don't want certain things no matter what, we can sidestep any potential problems in the package's parsing and recognition systems by just refusing things first without peering into them.
(Of course if you start thinking too much about this you wind up gibbering in the corner. The infosec world and AFL have been very good at blowing giant holes in complex parsers, which is exactly what pretty much every anti-spam and anti-malware system has.)