Attachment blocking – harder then it sounds


My intention with this post is not to grade or evaluate the solution described here. My only point is to be sure you are aware of the potential side effects of using this particular configuration. Also, as not being a subject-matter expert, this post only reflects what I learnt and understood after few hours of testing.

Background story

When you have a spam filter/mail gateway (of any kind), you want to use it to block “dangerous” attachments, right? You don’t want your users to receive executables for instance. I know, a simple Word file with a macro is as dangerous as an EXE, but unfortunately you can’t block Word files. So you just try doing your best.


We set up two types of blocking rules. One was blocking files based on their extension. Simple file name matching rules (e.g. *.jar, *.exe, *.bin). Yes, it can be bypassed by a 7-year old, I know that. However, a) it doesn’t hurt to turn this on (oh yeah.. it can hurt as we learnt) and b) if the bad guys need to rename their hack.exe to hack.ex_, we already gained some advantage. Nothing happens if the user double-click on the “hack.ex_” file, so it’s something 🙂

The other thing we did was MIME-Type blocking. We were blocking MIME-Types that may indicate dangerous files – among others we had “application/octet-stream” in the list.

Lessons learnt

We learnt three important lessons within 2 hours :). Needless to say we blocked hundreds of e-mails in the first hour which was more than suspicious.

You can’t fully trust in mime-types. No, I’m not talking about maliciously changing it, but valid e-mails with valid attachment stating incorrect mime-types.

When we checked the console we saw lots of e-mails being blocked by our mime-type rule: application/octet-stream. Checking the e-mails showed that they contained PDFs, GIF images, that sort of things. As you know a PDF should be application/pdf while GIF is image/gif. Well.. in theory. In reality sometimes they’re sent as application/octet-stream.

As you can see the attachment was a PDF, however it was sent with the mime-type of application/octet-stream. Ergo, it was blocked.


So you can’t really block application/octet-stream because of the huge number of the false positive hits. Sad… really sad.

If you turn on the inspection of the archive containers, it’ll extract EVERYTHING it can. As it’s well known, the new Office file formats (xslx, docx, pptx etc.) are archives. So the mail gateway can and will extract those files. It’s a good question whether it’s the expected behavior or not, but it’s a fact. The only problem you may face (if you want to filter the *.bin extension) is that these Office files may contain *.bin files. For instance, most of them has a “printerSettings1.bin”.


This means, you can’t really block the *.bin files without blocking most of the MS Office files as well.

Of course you could set up exceptions. Yes, you could, if you’re lucky enough to have a mail gateway supporting such nice features 🙂

The last lesson – never trust the “Delivery status” column of your mail log. So here is the thing, let’s say you blocked couple of  hundreds of e-mails by accident, so you have to release them manually. This is not a problem, every mail filter has this functionality.

The following two pictures show the status of a blocked e-mail before and after it was delivered.



If you can’t find the difference, you’re right… there is no difference!! So you can’t be sure whether the e-mail was really delivered to the recipient or not after you clicked on the “Deliver” button. And believe me, when you’re in the middle of fixing the mess you’ve created, you really want to know the delivery status. Actually, this is the only thing you care about!

I think the take away here is what we already know. It’s easy to write security recommendations and guidelines, but the road of implementation is full of bumps and roadblocks. And sometimes even the simplest things are impossible to do.