I often have clients email zip files to me only to find out that their corporate firewall has stripped the attached file. What is the most straight-forward way to send a compressed file through email and avoid getting your attachment stripped out by over-eager firewalls?

To clarify, I'm not worried about sending files out as I can host them on my own web server for download. I'm looking for a good, simple solution for having clients email files to me.

To clarify further: since I have control over my software running on offline client systems, and I control how the data files are created, I'd still like to explore options of how I might package my data to make it as easy as possible to email specifically. I'd like to avoid requiring my clients to install any additional software or use third party websites on their end.

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Questions on Server Fault are expected to relate to server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.
If this question can be reworded to fit the rules in the help center, please edit the question.

28 Answers
28

I think you're actually on the right track with your encryption approach. Part of the problem is that an encrypted zip is still a zip, and may be blocked by some firewalls for that reason alone.

Have your software zip the data, then encrypt the file but not within the zip framework. You'll end up with a file that won't appear as any prohibited file type to the firewalls.
A simple substitution cipher might be sufficient. Save the file without an extension.

Thanks to everyone for all the great answers. I think this one is closest to what I was afraid from the start was the only answer -- complete encryption AND renaming of the zip files before they could be reliably sent. I really want one of the third-party file-upload sites to be the answer, but the original question specified email and I've already tried a few of the suggestions and found them blocked at the client's firewall.
–
jacobseeMay 6 '09 at 21:25

Usually what I do is just upload my files somewhere where they can download stuff from a server. That way, it also doesn't clog up their inbox.

If you're short on space, Dropbox is a great service that gives you 2GB of publicly-available space for free (great syncing tools, too!).

UPDATE: It seems that I misread your question initially; you were in fact asking about clients giving files to you, rather than you giving them files. Regardless, my answer remains the same. If they're at all tech-savvy, then set up an SFTP server that they can upload stuff to. But still, using Dropbox is a piece of cake. Set up a shared folder for each of your clients, then they can put files in the folder and the files will be automatically synced to your computer.

I've started using Dropbox for this purpose too. I can just drop the zipped file into the public folder of dropbox on my computer, grab the sharing URL, then paste that into the email. Once the recipient downloads it, you can either move the file to somewhere else on your PC or delete it to make it inaccessible.
–
berberichMay 2 '09 at 1:03

My solution is usually WinSCP, which has an explorer-like interface (and looks very CuteFTP-like which is familiar to lots of corporate users). But since that's not an email solution I'll refrain. I would add though that Dropbox is possibly superior to SCP/WinSCP because (1) I believe it uses HTTP so it penetrates more firewalls and (2) you don't need to set up a SSH host.
–
jhsMay 3 '09 at 18:23

+1 for the SFTP server suggestion. You could possibly have problems with Dropbox and the clients putting a file on a third party server
–
Matthew FarwellMay 4 '09 at 9:03

I've found luck with sending either a .7z file or sending a FILE.zip.potato . I then instruct the recipient to rename the file back to .zip. It works surprisingly well.

You'd think that more email clients/server would check to see what type of file it really is, but I guess the problem isn't sending zip files, it's sending viruses in zip files. If the recipient has to rename the file to get it to work, they must know reasonably well what they are doing, so they aren't likely to accidentally rename, extract, and run a virus.

I always have them rename the file extension to .dat but that didn't work in this case -- the firewall still stripped it until I changed to 7z format and added a password. I'll have to try .potato next time :)
–
jacobseeApr 30 '09 at 21:50

There are numerous file sending services out there that can receive an uploaded file via their web site and will send you a link to go download it. This keeps the strain of handling the file off of the e-mail servers. One such service is SendThisFile.

If I'm reading your question right, you have a number of clients who send you (zipped) files from time-to-time, a notable proportion of which can't due to their corporate firewalls. If i have that correct, I would suggest you need to make it clear to your clients that it is their corporate firewall that is being over-eager and that they need to include their firewall maintainers and -- most importantly -- policy setters in the discussion.

Most decent IT Security personnel will understand the problem and will appreciate being included in finding a solution, rather than being routed around. Which means they will help. That's assuming your clients actually have decent IT Security people, which is not, of course, a given. :-/

There is no 100% solution to this. For instance, my spam/malware probe not only looks at file extension, it also looks at file type. Renaming a zip to .zi_ will not work because it "smells" the zip (looks at the file's structure and fingerprint). Double-extensions are not only reduced to the "inside" extension (again, trapping it by name) but they are also expanded as well. It auto-expands zips to 12+ levels (while avoiding zip bombs), so hiding a zip within a zip doesn't work either. Even auto-extractors arriving as EXE files will be auto-expanded with the same logic.

Anytime you can hide something in a zip to "get around a scanner", an attacker can do the same. This is Not a Good Thing(tm). While it isn't common practice at the moment, about 2-3 years ago it was very common for virus payloads to be zipped and then sent, knowing full well that many male end-users couldn't resist the bait of "See barely-clothed women privately at your work computer, just unzip this and run the program", eventually resulting in a mess for the IT staff. What is a big annoyance to you, is a security measure that an admin has instituted elsewhere for their own sanity.

For some sites, allowing zip files is just fine as the security concerns aren't great or the machines are very well locked-down and have tight scanning defenses. For others, it can be a time bomb waiting to go off on a network of soft targets with no desktop scanning. Still other sites might be banning them because they don't want end-users bringing in programs from the outside, that might interfere with a specific configuration that is required for "the" application needed by the business.

We still get virus warnings now and then, and yes, some are zipped.

I'd host the file elsewhere, and have it picked up with a web browser by someone with the appropriate access.

If you clients are technical and will understand the suggestions and answers listed here then you're good to go.

You might try sending an e-mail with boiler plate text of the steps to follow to send you files. They will have something to reply to and hopefully all the answers to their possible questions. Don't forget to customize the subject line so you can find individual replies in the sea of replies you get. Maybe even a small app you can run while to push out such e-mails on demand (on the phone or IM with a client).

If however your clients are not too technical (the kind that would embed a screen shot in a power point slide) then you have other troubles. The other suggestions most likely will cause a lot of confusion and generate more questions. In this situation, you might be better off with a custom web site (or page) that walks them through uploading the file through your web page directly to you (or at least look like it is directly to you). Some of your customers might have reservations about putting what they might consider sensitive data onto what appears to be a public site, even if it really is secure. They will get a better feeling dealing directly with your site and not a third party.

The customers I deal with don't use power point. Instead they paste screen shots into a Word document. I like the idea of using own website to handle this also.
–
Jacob SchoenMay 4 '09 at 23:44

If you have the ability to host your own web site, then creating a simply file upload form is trivial. Then you can have the page email you the attachment, or, if your firewalls may also strip it, have it dump to a drive or network share that you retrieve from. You can even ask them to supply a customer number, and then dynamically change the file name to include the number (to differentiate many files uploaded). If security is an issue get a SSL cert for your site and hide it behind there. If anonymous usage is an issue require some client data to validate the upload.
–
MilnerMay 5 '09 at 13:51

Due to my experience with FogBugz renaming "suspicious" files and adding a .unsafe extension, I generally send all binary attachments with a .unsafe extension and instruct the user to rename it.

Using an extension such as .unsafe is one that will unlikely be associated with any other program, and so even if the user has "hide extensions for known file types" turned on then the extension will display in Windows Explorer. Additionally these file extensions won't be blocked by Outlook.

There's not any solution for a firewall that looks at the file type instead of extension, these are more likely to block something where the type differs from the extension. The only workaround here is to use a service

Most importantly, using the .unsafe method gets around GMail filters. Most of our staff have their email CC'd to Gmail on the server end and so we get bounces all the time from various internal mailing lists if we include executable files inside of ZIPs and they're copied to a Gmail account.

since I have control over my software
running on client systems, and I
control how the data files are created

You do not specify what kind of software they are running, but this seams quite a "normal" thing to do...

From your software, why not contact your service (WCF for example) and send a message with a file attached (or log file, or whatever you think that might help you resolving any question that this files will do) and I can give you an example:

SuperOffice CRM as an option in the assembly file (both in the Windows and Web versions) called "SendToSuperOffice" under the Logs group, if that is set to true, they will get the log file from the client software with the database key (client serial number) and all the Errors and Failures and help the client in that way... no need to put the client sending files or info witch is fantastic when dealing with end users that some have problems even how to send a file inside an email!

+1 since you already have client-side code, dispense with the email alltogether and send the file in a web-service call. If you still want to send an email, send the file in a web service call and send an email telling you that the file has been uploaded.
–
WaldenLMay 3 '09 at 18:37

oops, should have mentioned also that this is an offline application -- will update my question again!
–
jacobseeMay 4 '09 at 0:44

offline as ... no internet access whatsoever? not even to create an email with the attachment and send it or even place it in the queue?
–
balexandreMay 6 '09 at 8:11

This is totally off the wall and possibly not an ideal solution for you, but consider writing a tiny standalone app that takes a file as input and writes a new copy of that file with all bytes XORed with 0xFF. Perhaps give it the the same path but with an extra extension like .dat. Customers could put it on their desktop and just drag files on top of it. Windows should run the program with the full pathname of the source file as an argument.

That should be hardly more than a couple dozen lines of code for the encoding half.

Yeah? Yeah? I know, right! What can I say, we're all semi-programmers here.

I would add that if malware scanners are already hip to the XOR 0xFF trick then you could just use symmetric encryption with a hard-coded key. That should still be pretty simple with most scripting environments' standard libraries, .NET, Java, or whatever.
–
jhsMay 3 '09 at 18:30

We use Share File, it's not free but it does make it really easy for people to send you files. You can send them an email with a link to .sharefile.com/ (the site can have your own branding, if you're concerned about it looking like a 3rd party site) where they can upload the file(s) via HTTP.

We needed this to allow clients to send us big files (in the range 100mb to 2gb), and setting up and ftp server wasn't an option because of their firewalls polices.

If you're looking for a customer solution, this obviously needs to be as straightforward and simple as possible. Since sending ZIP files through email is inherently unreliable and requiring customers to upload via FTP is cumbersome, a web-based file uploader will be the most familiar and reliable method. YouSendIt's Business Plus plan is a good fit here.

Hosted dropbox page where customers can send you files

Brandable pages and emails to match your business

YouSendIt's SiteDrop add-on creates the best experience, in my opinion. Customers can upload files right at your website with the embedded uploader, and both you and they can receive confirmation emails as soon as the upload finishes.

I'm really liking this type of idea -- ShareFile.com is similar. Unfortunately I do know some of my clients have access to yousendit.com blocked as we used to use the free version.
–
jacobseeMay 5 '09 at 20:19

If I'm reading correctly, you're asking how your clients can reliably email you zip files when your firewall is filtering zip files, without your clients having to install any additional software.

Assuming the firewall actually checks the file structure and not just the extension, you can't. Not under these constraints.

We can suggest alternate solutions (encrypt the files, use a zip program the firewall doesn't understand, fix the firewall, etc), but without knowing more information about how the firewall is actually doing the filtering, it's impossible to know whether they'll help. A few basic questions:

What make/model is the firewall?

Why does it "sometimes" strip attachments? Why not always?

What attachments can the firewall inspect?

What does the firewall do with unknown attachment types?

Why can't you stop stripping attachments?

With the current info we have, the right answer is to either stop stripping attachments or use a non-email solution.

no, not my firewall, the firewall on the sending end, and not just one firewall, but generally all the corporate firewalls out there. which are all different. it's a tough problem :)
–
jacobseeMay 6 '09 at 4:02

This question is long closed, but stumbled upon it and to anyone else who finds it: one solution that I use is to encrypt the email itself. It is simple to do on Apple's Mail.app, and looks easy enough on Outlook as well. It does rely on both parties having digital certificates - which you can get for free for personal use (or small fee for business) from http://www.comodo.com/home/email-security/free-email-certificate.php - and of course many other digital certificate providers. I just picked Comodo since it's what I used.

If you wan't to bypass data detection, you can use Steganography - that is, hide your file within the (most commonly) image file. There are a bunch of links to free applications that can do this for you at the wikipedia link.

Firewalls/mail servers that strip out .zip or any other compressed archive are the wrong way of handling the problem, IMHO. In order to "preserve" security from 0,01% of outside users, those sysadmins are penalizing the remaining 100% of internal users.

Good antiviruses (client and server side) are a good solution.

I work for a company (4000 of employees) where .zip attachments are allowed, and almost noone has had any virus/bad software problem.

An ugly but possibly workable solution, given that you control both ends of the exchange, is basically rolling your own MIME: sending an email that's plaintext as far as SMTP is concerned, with the base64-encoded data enclosed within your own separators and with your own content description markers.

If you're not talking about sending files out, and only receiving files - then don't you control your own mail filter? Can you not tweak it to allow the specific content? (The sending mailserver will not typically strip any attachments, only the receiving one)

Mail scanners typically open whatever kind of compressed attachements they can, so that they can scan the contents of the attachment. Unknown compression techniques could cause the file to be quarantined. But there's also usually a set of banned extensions that are not allowed to be received. (such as .exe, .bin - etc.). Some mailfilters will bounce these, others will strip out the attachment.

actually in my experience the corporate network does strip out .zip attachments on the sending end. all I get is an message at the bottom saying 'CORRUPT CONTENT ALERT The content this replaces was found to be corrupt. Cause of corruption: Unknown. See your system administrator for further information. Copyright 1999-2007 McAfee, Inc.' Thanks McAffe!
–
jacobseeMay 4 '09 at 0:47

A lot of SMTP servers (not just corporate ones) are configured to scan outgoing messages, even from authenticated users. Those running the servers are concerned about fallout if one of their users (even not deliberately) starts sending out malware.
–
Tony MeyerMay 4 '09 at 9:27

Problem - There's no 100% solution that fixes the problem for everyone

You aren't going to find a foolproof way to send zip files through email that works for everyone. Some places have white lists - they block every attachment except a few that they rigorously scan. Other places don't care about the file name, they scan the file itself and if it looks like a zip file internally, then they'll still block it.

If you encrypt the file with a separate encryption program ( password protected or encrypted zip files are still detectable) then change the file name to something innocuous, then in many cases it'll get through, but then you're asking your customers to follow several steps - which adds friction and you'll lose customers.

Often you can't even do that because they can't run or install software that they don't already have on their system.

Your best bet is to provide another low-friction channel for people to use.

Solution - Web form upload (simple, cheap, easy for you and client)

Set up a website with an upload button and a web form. Instruct users that have this problem to use the webform upload version.

At that point you could even have the webform email the file to you as an attachment, so it's seamless for you.

A simple, cheap webhost is only going to cost a few bucks a month for you (or free if you want to go very low end). Very low friction for your clients.