I have a client who uses an application that uses *.fr3 files, which as far as I am aware are nothing more than binary files in a proprietary format. Those files are periodically emailed from the software company to my client. Using Outlook (2003 or 2010) the client can save the attachment and then copy the file to the application that uses them. No problems and nothing unusual so far.
When the client uses OWA (Exchange 2003), even on the same machine, and tries to save the attachments they result in zero byte files. The solution they have employed for those staff members who only have access via OWA has been to ask the software vendor to zip them up and resend them. This works fine as far as the file goes but involves extra steps and bother that shouldn't be required.
I can find nothing to explain why this only happens with *.fr3 files. All other attachments they receive, such as *.zip, *.pdf, *.doc(x), *.xls(x), etc. save perfectly. The anti-virus software (Avast) is not treating *.fr3 as anything special either.
Are *.fr3 files something special as far as OWA is concerned that I'm unaware of? How can I convince OWA to treat them the same as other file types, which all save without issue? This isn't a show-stopping problem but is just one of the annoyances I'm trying to clean up for the client.
I had the same problem with OWA 2003 a while back, using a custom extension. Apparently the cause was a combination of no valid MIME type returned by the server, and IE detecting the MIME type incorrectly from the header of the file.
I'm still not sure why downloads were zero bytes (this can happen with XML files specifically, but I haven't read anything about it happening with binaries), but this solved it:
Add the
.fr3
extension with theapplication/octet-stream
MIME type on the IIS instance that serves OWA. (If you can find a more appropriate MIME type for the files, use it instead --application/octet-stream
is for generic binaries).Follow the steps posted by Brad_Saide to disable MIME handling and MIME sniffing on the client. This is the short of it:
The linked posting does not address zero byte downloads, and says that one or the other solutions (either on the server or on the client) should fix DOCX download issues. I made both changes and it solved my problem; Unfortunately I didn't try making the changes incrementally, so I'm not sure if one or the other would fix it.
Try adding the extension/MIME pair to the server first, and then test and move onto the clients.