Bug 157582 - Extension of Word document attachment changes from .doc to .dat
Summary: Extension of Word document attachment changes from .doc to .dat
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: shared-mime-info
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Bastien Nocera
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-12 20:42 UTC by Dave Malcolm
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: RHBA-2007-0182
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-05-01 22:49:38 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0182 0 normal SHIPPED_LIVE shared-mime-info bug fix update 2007-04-27 21:17:13 UTC

Description Dave Malcolm 2005-05-12 20:42:32 UTC
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

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?"

Comment 1 Dave Malcolm 2005-05-12 20:47:20 UTC
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).

Comment 2 Dave Malcolm 2005-05-12 20:49:16 UTC
It may be that the mimetype is getting rewritten serverside.

See for example:
which describes the Internet Information Services (IIS) default associations
(and hence ought to interoperate with Outlook)

Comment 3 Dave Malcolm 2005-05-12 20:54:38 UTC
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.

Comment 4 Dave Malcolm 2005-05-20 18:03:14 UTC
Changing component to shared-mime-info, reassigning

Comment 10 Daniel Riek 2006-09-05 17:08:45 UTC
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. 

Comment 13 Christopher Aillon 2007-01-19 17:38:00 UTC
Added a patch which I think ought to resolve this into the rpm. 

Comment 18 Red Hat Bugzilla 2007-05-01 22:49:39 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.