Ah. This is a bit of a soft question, but I though there might be some here that can share some insight.

I'm a developer. Sometimes I need to send a (bugfixed) DLL or EXE file to a customer. If this customer is in a big company, here's what I do:

  1. Rename the executable file (module.dll -> module.d__)
  2. zip the file with password so that it cannot be unzipped by the mail server
  3. rename the zip file (module.7z -> module.7.txt)
  4. send this via email and add a lengthy explanation for the guy at the other end on how to get at the file
  5. cross fingers that it'll get through the filters

Now, I can understand that email filters won't allow bare exe attachments.

What I fail to grasp is, how making email server filters unzip all attachments and then additionally check the unzipped files for executables regardless of their extension is adding any security. A zip-file won't suddenly explode in the users face. He'll have to unzip the file to get at any potentially malicious content. If you can get him to unzip a file, you get get him to jump through the hoops I described above.


  • 2
    If I need to send someone an executable in those conditions, I usually just send them a link and post the file on a public web-server in some hidden (randomly named) directory. Then just delete the file after a few days. I might password protect it, but if it's safe enough to send by e-mail, it's probably not that sensitive anyway.
    – beetstra
    Sep 27, 2011 at 14:34
  • 2
    This question and answers reminded me some "manual virus" and so on. Especially this one: thedailywtf.com/Articles/Manuallypropagating-Worm.aspx Sep 27, 2011 at 19:42
  • If you do all of these except the password encryption stuff, Linux/OSX may still identify the file to be zip even if it is renamed .txt (It has happened to me once, will try to confirm again now). Perhaps some sort of content sniffing. Add this to "Open files after downloading", you have the same situation as sending a bare .exe
    – Nivas
    Sep 28, 2011 at 2:53

2 Answers 2


Well, a bare executable is dangerous in that some users will try to execute it. They should not, they were told they must not, yet they do.

A Zip file, possibly renamed, containing possibly renamed executable files, is also dangerous because some users will rename files, do the unzip, and execute what they find within. They should not, they were told they must not, yet they do.

I have received email virus which used a renamed Zip archive with renamed contents and a password. The email contained detailed instructions on how to "open" the archive, and a "motivation speech" (usually, the promise of a naked female celebrity, sometimes threats of a fiscal nature). That I have received such emails shows that at least some users, somewhere, followed the instructions and got infected. Sad but true.

Email filters try to strike the right spot between insecurity and extreme user annoyance. So they will let pass some cleverly concealed threats, if blocking them would imply stop doing any business. In your case, you are quite happy to be able to send your EXE or DLL through. In that view, blocking unrenamed Zip archives is a "minor annoyance" (which you are effectively working around, hence the "minor") but does block a substantial amount of virus and malware. Blocking more would be "more secure" but would escalate the annoyance to "major" level.

  • I'd say that you have received such mails does not show that anyone has followed through. (Although I tend to agree that someone, somewhere probably has.) Still you raise a good point: The more complicated it is, the more likely it may be users only will follow through for legit mails.
    – Martin
    Sep 27, 2011 at 14:19
  • 1
    +1 for "They should not, they were told they must not, yet they do."
    – DanBeale
    Sep 27, 2011 at 14:29
  • @Martin - look at the number of people caught by 419 scams. People do plenty of tricky stuff if they think it's worth it.
    – DanBeale
    Sep 27, 2011 at 14:31

I think there is definitely an element of truth in your last sentence there - the problem is that the perimeter controls aren't effective.

If you are going to scan at the perimeter you need to make sure your controls are set up so that either the file gets scanned, or it doesn't get allowed through. Then it works as expected - anything entering is scanned for malicious payload.

What you have described, however, is a workaround which can reduce security, as it takes advantage of a very simple check - looking for a zip file by extension, which fails - thus allowing any content to pass the perimeter controls.

A correct way to do this (there are others) is to implement an enterprise secure email solution that provides secure transport, assesses a file based on what it is, not what it's extension is, as well as a way to scan everything at the perimeter, both incoming and outgoing.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .