From email from jdeverea: "I sent a *.doc file from Open Office 1.1.2 with Evolution 2.0.2 to a customer using Outlook XP with Office XP. When the customer opens the email the *.doc that I sent is now a *.dat file. I checked my Evolution 2.0.2 sent folder and I can see the *.doc file attachment on the email. When I use my test Outlook 2003 running Windows XP SP2 I see the *.dat file. I have attached the Outlook reply email with the *.dat on this email (using the forward option to preserve the email) for your examination. I would like to know the possible cause of the file extension change?"
It appears that Evolution is incorrectly writing "application/vnd.ms-word" as the mimetype for the attachment, when it ought to be "application/msword". Outlook must have some mechanism to map back from mimetypes in emails to file extensions in Windows; my belief is that it understands the latter type but not the former. So here's a test I'd like you to carry out to confirm the diagnosis: 1: Compose a test email in Evolution on a RHEL 4 machine; attach a Word document to it; give it a "Subject" that you can search for. 2: Click on "File->Save Draft" in the composer 3: Quit Evolution 4: Launch your favourite text editor and open the file "~/.evolution/mail/local/Drafts"; thiscontains all your draft emails in one big mbox-formatted file. 5: Find the email using the Subject you gave it earlier 6: The mail consists of a number of parts, delimited by lines that look a bit like this "------=_NextPart_000_0000_01C54715.393D9670". Find the part for the attachment, it will say something like this: Content-Type: <MIMETYPE GOES HERE? ; name="test.doc" 7: My belief is that the mimetype will erroneously be "application/vnd.ms-word" but the name will correctly have a .doc extension. Please verify this. 8: Restart Evolution, and send the email and read it in Outlook: the filename extension will be bogus (.dat). 9: Repeat stages 1 through 7, at this point, manually edit the part of the Content-Type that says "application/vnd.ms-word" to "application/msword". Save it and quit the editor 10: Now restart Evolution, and send the doctored draft email to Outlook. Does the extension come out correctly this time? I believe that this problem may appear for other types, in particular, Excel and Powerpoint seem to have similar entries in the underlying shared-mime-info database (this is what Evolution uses in RHEL4 when writing the mimetype for attachments into emails).
It may be that the mimetype is getting rewritten serverside. See for example: http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/mimetypes.mspx which describes the Internet Information Services (IIS) default associations (and hence ought to interoperate with Outlook)
Assuming that our diagnosis is correct, then this is really a bug in the shared mime database rather than Evolution, though I can hack a fix into Evolution: evolution/composer/e_msg_composer_guess_mime_type calls gnome_vfs_get_file_info(..., GNOME_VFS_FILE_INFO_GET_MIME_TYPE, ...) which uses the shared mime database. I compared the other Office mimetypes between the shared-mime-info database and the MS IIS list, and I believe Word is the only one that's broken. It would be good to run an automated test on this, though. IIRC Exchange servers store this information in Active Directory, so we may be able to write an automated test suite that compares the shared-mime-info mappings with the MS view of the same.
Changing component to shared-mime-info, reassigning
The component of this request is planned to be updated in Red Hat enterprise Linux 4.5. This enhancement request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Added a patch which I think ought to resolve this into the rpm. shared-mime-info-0.15-10.1.el4
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0182.html