The very problem I had was serving an ODT-file from VPP folders. It always returned the file with MIME-type application/octet-stream - which just is not correct. Most browsers handle this fine, and see the ".odt" in the file name, and open the file in Office/OpenOffice. However - drumroll - Internet Explorer doesn't. It wants to open the file as a ZIP-file. To be fair, this isn't wrong, since the file itself really is just a ZIP-file in disguise, but it's not very practical.

If I put the file in the application folders, however, IIS' MIME mappings came into action and served the file correctly as application/vnd.oasis.opendocument.text. So obviously, EPiServer's StaticFileHandler does something with the response headers that IIS' file handler does not.

The solution 

After some digging, I found that the class EPiServer.Web.MimeMapping has a method AddMimeMapping(string extension, string mimeType). So my final solution was to add the following to Application_Start in Global.asax.cs:

MimeMapping.AddMimeMapping(".odt", "application/vnd.oasis.opendocument.text");

...and of course, creating functionality for retrieving MIME-types from IIS or some other source shouldn't be a problem, but this is the essence of the solution.

I'm not sure I like this however. I can't see any reason why EPiServer doesn't use IIS' own built-in MIME mappings like the web application itself does. I guess it might be legacy code, but still - as far as I know, support for a customizable MIME mapping table has existed in all web servers since forever.