Closed Bug 479169 Opened 14 years ago Closed 10 years ago

Thunderbird from Macintosh sends "corrupt" attachments as application/applefile


(MailNews Core :: MIME, defect)

Not set


(Not tracked)



(Reporter: st601486, Unassigned)


User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Build Identifier: version (20081209)


This is a little convoluted.  The gist is that, in certain cases, Thunderbird will send out an attachment that is misidentified as mimetype "application/applefile" based, it seems, on incorrect information saved in mimeTypes.rdf

Basically, I think this is really a multipart problems:

1. Thunderbird is incorrectly storing information for mimetypes that it is incapable of properly handling.

2. Thunderbird is incorrectly trying to use mimetimes that it is incapable of properly handling, based on the file extension on the attachment.

3. Finally, Thunderbird isn't handling AppleDouble correctly.  See

Note that this differs from bug 378729 in that this affects messages subsequently SENT from Thunderbird on the Mac.  Thunderbird assigns an incorrect mimetype to its attachments, which renders the message impossible to read, unless you manually translate the base64 that is.

Reproducible: Always

Steps to Reproduce:
1. Send a message from Eudora on Macintosh with an attachment, assume a *.pdf, encoded to include "Macintosh Information".  That is, you must send the first message with the mimetype/applefile metadata included.

2. Receive and open the message in Thunderbird on Macintosh

3. Double click the attached file in the Thunderbird "read" window, select the "default program" to open the file, and check the checkbox "Do this automatically for files like this from now on"  This seems to modify the mimeTypes.rdf file.

4. Compose a new message in Thunderbird, attach a file of the same type as the original attachment from Thunderbird, e.g. *.pdf

Actual Results:  
The message sent from Thunderbird identifies the attached file as application/applefile but is missing the "metadata" that is required by the application/applefile definition.

Expected Results:  
The attachment should be of type application/pdf (or whatever is correct, based on the original file extension used)

Exchange 2007 will refuse the "corrupt" attachments from Thunderbird.  Most clients will choke on the attachments.


This is, roughly, what the original email from Eudora on Macintosh should look like.  Based on some of the bug reports, I suspect that emails originating in Entourage and Apple Mail might also be able to cause the problem in Thunderbird.

Content-Type: multipart/mixed;
MIME-Version: 1.0

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Content-Type: multipart/appledouble;

Content-Type: application/applefile
Content-Transfer-Encoding: base64

<base64 stuff that includes the filename and file type>

Content-Type: application/octet-stream; name="elements.pdf"
Content-Description: %elements.pdf
Content-Disposition: attachment; filename="elements.pdf"; size=24938;
	creation-date="Wed, 18 Feb 2009 19:48:05 GMT";
	modification-date="Sat, 24 Jan 2009 17:04:03 GMT"
Content-ID: <p06240812c5c25cb0de19@[].0.0>
Content-Transfer-Encoding: base64

<a bunch of base64 stuff>


This is what the mimeTypes.rdf looks like after I click on the application/applefile encoded attachment and select to open with the default application, and check the "Do this automatically for files like this from now on." checkbox.

<?xml version="1.0"?>
<RDF:RDF xmlns:NC=""
  <RDF:Description RDF:about="urn:mimetypes">
    <NC:MIME-types RDF:resource="urn:mimetypes:root"/>
  <RDF:Description RDF:about="urn:mimetype:externalApplication:application/applefile"
                   NC:path="" />
  <RDF:Description RDF:about="urn:mimetype:handler:application/applefile"
    <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/applefile"/>
  <RDF:Seq RDF:about="urn:mimetypes:root">
    <RDF:li RDF:resource="urn:mimetype:application/pdf"/>
    <RDF:li RDF:resource="urn:mimetype:application/applefile"/>
  <RDF:Description RDF:about="urn:mimetype:application/applefile"
                   NC:description="Portable Document Format">
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/applefile"/>
Component: General → MIME
Product: Thunderbird → MailNews Core
QA Contact: general → mime
Version: unspecified → 1.8 Branch
Reporter do you still have the issue when using thunderbird 3.0b1 (make sure to backup your profile before using it) ?
(In reply to comment #1)
> Reporter do you still have the issue when using thunderbird 3.0b1 (make sure to
> backup your profile before using it) ?


Yes the problem still exists.  Both the incorrect information being saved in mimeTypes.rdf and the subsequent incorrectly identified (or incorrectly encoded, depending on your point of view) mimetype on subsequent sent attachments that have same file extension.

Thanks for looking into this.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1
Version: 1.8 Branch → Trunk
Summary: Thunderbird from Macintosh sends "corrupt" attachments from Macintosh client → Thunderbird from Macintosh sends "corrupt" attachments as application/applefile
I can confirm this bug. We have Thunderbird-sent emails being rejected (#554 5.6.0 STOREDRV.Deliver; Corrupt message content) by our MTA (Exchange 2007) because of pdf attachements being encoded as mimetype "application/applefile".
Ever confirmed: true
I would search the closed bugs for some hints - I seem to recall we encountered something like this here, and that it was a Mac issue
I've just encountered this on Windows version of Thunderbird 3.1.4, so it's not only Mac platform bug.

This is a severe bug, as it's very easy to make Thunderbird unusable and users need IT support to be able to send attachments to Exchange server again. Can be treated as a DOS - I'll send you an e-mail - you open it and then you'll not be able to send any attachment.

Checking "Do this automatically for files like this from now on" should definitely not affect sending messages.
I think this is a duplicate of, or related to bug 579682.
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.