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