Problem opening docx Word attachments in Communications Express

Question

We have a problem where some Word documents of the .docx type won't open properly in IE. IE will treat the docx file as a zip file, and offer to open it up using zip, instead of Word. The strange thing is that some docx files open fine into word, but others don't. Also, we have yet to see any such problem in Firefox. The basic work-arounds are to right-click on the attachment link and save, and then open it in Word, or to suggest the user uses Firefox.
We're at a point where we think the problem is with the version of Word (or OpenOffice or whatever) that creates the document, and that it's putting weird things into the headers of the document. Our thought was that adding "docx" to the MIME types for Word could fix the problem, so I did the following on our test system. I opened up /var/opt/SUNWwbsvr7/https-{SERVER-HOSTNAME}/config/mime.types and changed the following line:
type=application/msword exts=doc,dot,wiz,rtf
to read:
type=application/msword exts=doc,dot,wiz,rtf,docx
I then stopped the webserver, removed the cached(generated) files, start the webserver, deleted the cache on IE and tried again. IE still treats the docx file as a ZIP file. Our patch level for UWC is 122793-30.
Is there some other place to look at for modifying MIME types for UWC?

Answer 1

Kdcypher wrote:
On our test server, which has both UWC & Messaging Server running on the same box (in prod, these functions are on separate hardware), I made these changes in /var/opt/sun/comms/messaging64/config/mappings and [same_path]/conversions, which I understand to be the config dir for the back-end Messaging Server (in case you hadn't guessed, I'm not necessarily our mail guru, but his plate is extremely full at the moment, and I'm getting to learn more about Messaging Server by working this problem). Do I need to be setting this up elsewhere, as in under UWC?You only need to configure these files at the MTA level. Make sure the conversions file is owned by the messaging server user/group (mailsrv:mail by default).
Also make sure the mappings entry is exactly how I provided (including leading spaces).
My testing yesterday, using your configuration suggestions, was all from Firefox, which could explain why your code wasn't working because (as I understand it) your code was set to convert anything with a content-type of "application/x-zip-compressed" and would ignore anything with "application/octet-stream"You can add additional rules to the conversions file to handle the various scenarios.
So it did not get changed by the server.Please provide the mail.log_current entry for the above attempt.
Is there any way to tell "imsimta cnbuild" to be verbose and actually tell me what it's doing?The cnbuild command compiles the MTA configuration files. It either works or it doesn't.
Or is there a log file that contains details of what it's doing?You can enable more verbose MTA logging e.g.
=> add "slave_debug" to the source channel (e.g. tcp_intranet) in the MTA imta.cnf file
=> add MM_DEBUG=3 to the MTA option.dat file
=> run ./imsimta cnbuild;./imsimta restart
=> re-run your test, this should result in a file called tcp_local_slave.log-<something>
In that file you should see something like the following:
12:22:48.59: Checking CONVERSION entry #1
12:22:48.59:   IN-TYPE pattern: application, actual type: application
12:22:48.60:   IN-SUBTYPE pattern: x-zip-compressed, actual subtype: x-zip-compressed
12:22:48.60:   Checking IN-DPARAMETER-NAME #0
12:22:48.60:     Dvalue: filename, pattern: *.docx, actual value: SR7285240.docx
12:22:48.60:   Out channel pattern: ims-ms, actual out channel:  ims-ms
12:22:48.60:   Entry matched.
12:22:48.60:   New content type: application
12:22:48.60:   New content subtype: vnd.openxmlformats-officedocument.wordprocessingml.document
12:22:48.60:   New content disposition: attachmentRegards,
Shane.