49.38 KB, application/octet-stream
27.58 KB, application/octet-stream
75.69 KB, message/rfc822
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124) Gecko/20070309 Firefox/126.96.36.199 Build Identifier: 188.8.131.52 (20070221) If you send a Photoshop psd-file with Microsoft Entourage (v.11.2.5) , or with Mail.app (v.2.1.1)(and do not check "Send Windows friendly attachment), the content-type is set to application/applefile. When you receive this attachment with Thunderbird, and try to save it and open with Photoshop (v.CS 2), it is corrupted, and Photoshop can't open it. I'm not sure if this is a VALID content-type, but every other email program can still save the attachment without corrupting it. If you send same attachment with Thunderbird, Webmail, or Mail.app with "Send Windows friendly attachment" checkboxed, attachments work fine with Thunderbird. When sending email, Thunderbird and Webmail set the content-type as Content-Type: application/octet-stream; Mail.app, with "Send Windows friendly attachment" checked, sends Content-Type: image/photoshop; Reproducible: Always Steps to Reproduce: 1. Send attachment with Mac Entourage, or Mail.app 2. Save attachment with Thunderbird 3. Open with Photoshop Actual Results: Photoshop says "Could not complete your request because it is not a valid Photoshop document". Expected Results: Should open up fine.
Does this bug still occurs with Thunderbird 2?
Severity: critical → normal
Yes, Mozilla Thunderbird 184.108.40.206 (20070326) behaves exactly the same.
Version: unspecified → 2.0
I hope it's the only content type that Thunderbird corrupts, otherwise I would view this bug as quite critical.
Created attachment 264737 [details] Original test psd-file This file was created with Photoshop CS2. Create new file, 1x1px 72dpi white background.
I guess this is a duplicate of Bug 398967 -- from my experience the attachments are corrupted as the resource and data forks are glued together into the data fork. Only Thunerbird on Intel Macs is affected, on PPCs everything works as expected.
Created attachment 348361 [details] Testcase (saved Email with appledouble Attachment) Attachment is broken when saved with Thunderbird/2.0 / MacOS X / Intel. This bug is apparently fixed in Shredder/3: Attachment is OK in Shredder/3.0b1pre BuildID 20081115030213, only creation date is wrong (1/1/2000 0:00h). See also (duplicate) Bugs: Bug 394298, Bug 462666 and Bug 398967
Attachment <https://bugzilla.mozilla.org/attachment.cgi?id=264737> is obsolete/improper to show the bug as it has no (more) resource fork. Use the saved E-Mail <https://bugzilla.mozilla.org/attachment.cgi?id=348361> as test case instead.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've seen for some time a problem with Thunderbird/Mac receiving email with attachments from an Entourage client, over several versions of Thunderbird and Entourage. The attachments are not detached correctly and are partially mangled, which is fatal for image files, etc. This does not happen with Thunderbird/Windows on the same message, and the message is also correctly readable with Mac Mail client. The encoded attachment header appears to be slightly different when sent Entourage than from other clients, which must account for the difference, but yet is handled properly by other clients. I have a couple of examples that I'd make available on request.
can confirm. very annoying problem sent from entourage as appledouble files are ok with seamonkey 1.1.x on win64 on macosx default viewer doesnt get set correctly and files break on saving. jpegs work when viewed inline tho. what i think is happening is that somehow the first contenttype from the resource fork is used and no the second with the actual file. Content-type: application/applefile; name="Aufbau_Vergleich.png" Content-transfer-encoding: base64 Content-disposition: attachment; filename="Aufbau_Vergleich.png" Content-type: image/png; name="Aufbau_Vergleich.png"; x-mac-creator="3842494D"; x-mac-type="504E4766" Content-disposition: attachment; filename="Aufbau_Vergleich.png" Content-transfer-encoding: base64
Hardware: PowerPC → All
The described problem is happening here with the most recent thunderbird version (=24.1.0). When sent with Windows the content-header looks like that: --------------020506020303030707040804 Content-Type: application/pdf; name="Wall_Detail.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Wall_Detail.pdf" When sent with OS X (10.9), the content-header looks like that: --------------010304000708090803060605 Content-Type: application/applefile; name="Wall_Detail.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Wall_Detail.pdf" Is there a workaround available? Because this bug, as well as other hints, are quite old, it looks to me that everybody else experiencing this found a solution.
My solution was to stop using Thunderbird with Mac OS. If you can't trust a mail client to save attachments properly..
You need to log in before you can comment on or make changes to this bug.