|File attachments in a business environment||mrmekon||9/8/10 12:21 PM|
Our small engineering company is paying for Google Apps Premier Edition for e-mail and calendar hosting, and until now it has been wonderful to have such a complete system with practically no configuration. However, we have just become aware of a horrible design flaw in Google's mail delivery system that is threatening to make Google Apps useless for our company: Executable File Filtering (see Google's official explanation here: http://mail.google.com/support/bin/answer.py?hl=en&answer=6590). I have requested to have it disabled for our domain, and have been informed that it cannot be. For our safety, you know?
Now, don't get me wrong, executable filtering for general free e-mail services is a sensible idea. But have a look at what Google is doing and you'll see that their solution is terribly flawed. Google blocks files based on their filename extension, seemingly without any concern for the actual contents. They even go so far as to dive into zip and tarballs to hunt them down. Tarballs! Consider what this means: any file with the extension ".cmd" cannot be e-mailed directly or in a standard archive format by or to a Gmail or Google Apps user. Yes, that means you can't send a Windows CMD file. It also means you can't send some uncompiled, plain-text VIM command scripts. It also means you can't send some uncompiled, plain-text LD linker scripts. It also means you can't send data files generated by some FPGA tools. EVEN IN AN ARCHIVE! So when our paying customers try to e-mail us a small archive with some data they collected that happens to end in a ".cmd" extension, they get a rejection letter from Google, and the e-mail is not delivered at all. And what are we going to tell them, please rename those 300 files to something else to bypass our e-mail filter? But, no, really, trust us with your engineering tasks, we know what we're doing.
Our customers also have virus filtering in place in their e-mail system. Their filtering system detects the Portable Execution file format, standard Windows executable files, and filters it out, and still delivers their message with a warning about the filtered file. Their filtering system doesn't reach its grubby hands into their archives. We can get around Google's filter simply by renaming an EXE to EXE_, but it gets blocked by their filter that actually knows how to detect an executable. To e-mail them an actual Windows executable, we have to rename it to EXE_, archive it, then mail it.
E-mail is not an appropriate way to transfer files, and this filter can be defeated using bzip, or PGP encryption, or renaming the files, or uploading to an FTP site, or any variety of other means... but the point here is that we are made to look like fools to our customers when they can pass data back and forth among themselves in the way they have been doing for decades, and we have to point them to the flaming hoop and say, "jump through that if you want to send us anything." We look like amateurs, we hinder *their* business, which hinders *our* business, and we have no control over it.
So, Google, how do we turn this garbage off for our domain?
|Re: File attachments in a business environment||Atul2010||9/10/10 11:43 AM|
Many web hosting block .exe or .vb etc. file. But they allow it in zip file.
And google is also not allowing it in zip file. I understand your situation. May Google work on it.
Now, You can try this ( I never tried this). this is not a solution, just alternate.
change the extension from .exe to some thing .123 and tell other party to download and change it back to .exe
Try Google Docs , upload and share with your customer.
Have A Nice Day !
Save Paper ! Save Tree ! Switch to Google Apps !!!
|Re: File attachments in a business environment||mrmekon||9/10/10 12:33 PM|
Changing the extension or uploading to a hosting site is fine when I'm communicating with another engineer, but that sort of thing doesn't work when dealing with managers or marketing or VPs at other companies who couldn't care less about network security. Those guys are going to e-mail us whatever they please, and if we can't receive it they are going to take their business elsewhere. Like it or not, the business world is not amenable to changing its ways. We aren't going to turn away business just because they are doing something insecure (after all, they're the ones who need us the most!), and that should not be Google's decision to make.
Again, this is not Gmail, this is Google Apps Premier Edition. Google's own description: "Reliable, secure web-based office tools for any size business" that "helps you save money and reduce IT hassles." But blocking our e-mail is not my definition of reliable, money-saving, or hassle-reducing.
|Re: File attachments in a business environment||fiskmacdowell||9/15/10 8:38 PM|
I have to stand with mrmekon on this. I'm a software developer. I send zip files with executables in them all the time. I was so happy to find Google Apps as a mail solution, only to find it will not be feasible for me because of this poorly thought-out policy. I have to send exe files to customers, often inside of zip files. I can't rename them. Nothing is gained by denying me the ability to send these files. In a free account, sure, do all the filtering you want. But don't censor my paid account. That just will not fly.
|Re: File attachments in a business environment||mbdrake||9/16/10 12:45 AM|
Having worked for a multi-million pound post-production and visual effects facility which is forever sending files back and forth for Hollywood productions, email was actively discouraged. We didn't use Google Apps, but I made sure that we filtered particular extensions and severely limited attachment sizes to ensure that mailboxes weren't abused. And amazingly nobody ever complained. We used a combination of FTP, SCP and web-based file sharing services for these files. The latest Harry Potter films have been using CrushFTP running on a Mac workstation to pass files around. Believe me, media types can be the most technophobic people ever, and they managed to cope with the concept of not sending files by email (a couple of PDFs and photos - fine - software updates, patches and entire clip sequences - no).
As Atul2010 has said, in Google Apps, Google Docs is the best place to share the executable/zipped/tarred archives and you link to them in the email. Alternatively there are other services such as Box.net, Dropbox and other file sharing solutions. Some of which even tie into Google Apps via the Marketplace While I appreciate it must be difficult for your clients wanting to send everything by email, they have to realise that it is not that practical (the overheads alone in encoding a binary for text transmission is bloody annoying, cumbersome and adds so much extra to the original file).
The only reason we have the ability to send files by email now is that there were very limited options back when email started becoming popular. But now there is absolutely no excuse, and we need to get out of the habit of insisting of sending everything by a text-only medium. It's a legacy. And one that Google is actively attempting to discourage. It's built tools for sharing files, and people should be using them.
|Re: File attachments in a business environment||mrmekon||9/16/10 8:03 AM|
mbdrake, your reasoning is correct for within a large corporation. We don't e-mail files within our company, nor to the vast majority of our customers. Most engineering firms have FTP sites and know how to use them. But not *all* of them. And, unfortunately, it is entirely inappropriate for a small consulting firm like ours to push correct e-mail protocol on our less-informed clients. Our company, and our families, depend on us getting as many contracts as possible. Like it or not, pissing off those who are not as technically savvy is not the way to do that. I support banning all e-mail attachments, but as long as our customers expect us to be able to receive them I expect Google to allow me to receive them. I am, after all, paying them to assist my business.
|Re: File attachments in a business environment||Spacexplosion||9/16/10 8:33 AM|
The argument against searching inside a business's attached archives has merit, but I think a far more disturbing aspect that everyone seems to be ignoring is the fact that this filter doesn't even block executables. The implementation is ineffectual to begin with. What about executables for operating systems that don't use filename extensions? What about all the false positives that mrmekon mentioned? It would be easy to examine the actual file content to see if it is an executable. I know of other email providers that take that approach. If your email provider is going to pass all your incoming traffic through a stupid, broken filter you would think the least they could do would be to offer the option of turning it off.
|Re: File attachments in a business environment||mbdrake||9/16/10 9:44 AM|
That's intriguing. I took a 64-bit ELF executable from my own Linux server and sent it via Gmail. It accepted it with no issues at all. It's trivial to determine whether a file is an executable or not, yet Gmail is very biased to towards Windows executables.
|Re: File attachments in a business environment||mrmekon||9/16/10 10:36 AM|
Yes, that's precisely the problem. Gmail does not block file attachments, Gmail blocks "executables". We are not e-mailing executables, we are e-mailing small text files (on the order of 500 bytes). Gmail is identifying them incorrectly and blocking them. That is not cool, and that is not configurable.
|Re: File attachments in a business environment||mrmekon||9/16/10 10:43 AM|
|Re: File attachments in a business environment||Atul2010||9/16/10 9:47 PM|
Well, As I said changing extension is not proper solution (and I never tried on gmail).
Yes ! I agree with mbdrake, sending large files as attachment will put huge overheads on email system. Best option is Google DOCS or any other service. Even FTP works well for it. ( You can resume your upload / download, very IMP for large files).
And also sending/ recd. executable on every day basis, is unique situation. Normally all business send/ recd. doc., ppt, xls, zip, pdf, jpeg, gif ...... all data files.
|Re: File attachments in a business environment||T_F_S||12/8/10 2:50 PM|
The only option I have found is to use .RAR files, with a password, and set the option to "Encrypt File Names". This bypasses Google executable check.
|Re: File attachments in a business environment||wwcanoer||1/22/11 5:16 AM|
Incredible. I confirmed that I receive no notice when gmail rejects and exe file. This is astounding. At least let me know an email was rejected to that I can proactively contact the sender/customer on how to send me the exe file!
My solution: Ask people to use 7-zip because gmail does not recognize an exe file zipped in unencrypted 7z format.
I don't understand why gmail and goolge apps are so popular. There are so many poor design/usability choices.