Cannot open .eml "this attachment appears to be empty" MAC

[dynamyte]

A friend sent an email (using Gmail) with a couple attachments. When I try to open the attachments I get this error:
"This attachment appears to be empty.
Please check with the person who sent this.
Often company firewalls or antivirus programs will destroy attachments."

But from the message size I can see the file is not empty and when I view the source I also see oodles of message. Sometimes I can save the message and then open it with Mac Mail. sometimes I can't or Mail goes wild with both cores near 100%.

I have looked at the message source. What appears to me to be the header for the attaches messages I can't open are:

--001636c5b8b599ac440497e11cb0--
--001636c5b8b599ac4a0497e11cb2
Content-Type: message/rfc822; name="Fwd: FW: a Little Bathroom humour.eml"
Content-Disposition: attachment;
filename="Fwd: FW: a Little Bathroom humour.eml"
Content-Transfer-Encoding: base64
X-Attachment-Id: 9fdd8e0d15f9e48a_0.1


Content-Type: message/rfc822; name="Fwd: FW: Cat Bath.eml"
Content-Disposition: attachment; filename="Fwd: FW: Cat Bath.eml"
Content-Transfer-Encoding: base64
X-Attachment-Id: 9fdd8e0d15f9e48a_0.2

I tried opening this email in my Charter web email and the message appeared to hang there also.

Any clues?

[f00]

i have this error too and the attachment is obviously not empty. a response with a solution would be appreciated

[oran]

I also have this issue. If I choose to foreward the message, then I can open the attachment from the composition dialogue. I cannot open the attachment from the recieved emails, though. Sometimes the attachments are fine, sometimes not, and sometimes they open fine and then later not. I have not identified any trends, yet.

[mjsbbs]

I am experiencing this same problem. When I use blat to send an email with a .eml attachment, the attached file will not open in Thunderbird.

Here you can see the attachment:


Here you can see the message when I double click on the attachment:


Here you can see what appears when selecting "view source":


- Mike

[mjsbbs]

The bug is still present in Thunderbird 16.0.

Code: Select all

--=_BlatBoundary-J0ahiV6R0uNTlj1ZiCuFP
Content-Type: application/octet-stream;
 name="test.eml"
Content-Transfer-Encoding: BASE64
Content-Disposition: ATTACHMENT;
 filename="test.eml"

[Kidmar]

I've just found the problem.
Looks like Thunderbird can't recognize the "Content-Transfer-Encoding: BASE64" because it's CAPS.
Changing it to "Content-Transfer-Encoding: base64" solved the problem in my email (sent using BLAT).
I think BLAT is wrong, but maybe TB could fix this too.
Does this work with you too?

[ChipProgrammer]

RFC 2110 (http://www.ietf.org/rfc/rfc2110.txt) section 9 Examples shows the following:

--boundary-example-1
Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...

--boundary-example-1--

RFC 2045 (http://www.ietf.org/rfc/rfc2045.txt) specifically writes:

6.1. Content-Transfer-Encoding Syntax

The Content-Transfer-Encoding field's value is a single token
specifying the type of encoding, as enumerated below. Formally:

encoding := "Content-Transfer-Encoding" ":" mechanism

mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token

These values are not case sensitive -- Base64 and BASE64 and bAsE64 are all equivalent.

I think I found the problem in Thunderbird source. I downloaded the source for version 17.0b1, and found a bug in mimei.cpp located in mailnews\mime\src. Line 885 uses EqualsLiteral() when it should be using LowerCaseEqualsLiteral(). It appears that all other references to ENCODING_BASE64 do case insensitive compares, as expected. This was the only reference I could find that does an exact case sensitive compare. The same problem line exists in version 16.0.

I just submitted a bug report at https://bugzilla.mozilla.org/show_bug.cgi?id=805620

[mjsbbs]

Thank you very much, Kidmar and ChipProgrammer. It sounds like you have found exactly what the problem is. Thank you very much for opening up a bug report for this. I have been replying to this bug report but it was closed so I don't think anyone is looking at it:

https://bugzilla.mozilla.org/show_bug.cgi?id=580017

This is important to me because I have a script which forwards customer email replies to the account rep who is managing that property. However, because of the "base64 Thunderbird problem", I can't attach the emails. I verified this to be a Thunderbird problem as the same emails sent by blat open fine in other email programs.

This problem is still present in Thunderbird 17.0







- Mike

[ChipProgrammer]

The latest nightly build for Thunderbird 17.0 still has the problem. I do not hold any hope that Thunderbird developers will make this quick and easy fix anytime soon. I suppose I will have to fix it myself and provide a separate Thunderbird build/release.

[mjsbbs]

Hi ChipProgrammer, it looks like Hiroyuki Ikezoe has fixed the bug! Check out your bug report at bugzilla.

https://bugzilla.mozilla.org/show_bug.cgi?id=805620

- Mike

[ChipProgrammer]

I posted additional replies to https://bugzilla.mozilla.org/show_bug.cgi?id=805620, showing a full email message with five attachments that the Thunderbird developers can use for verification. It appears that Thunderbird is using the attachment filename's extension to decide what should be done, sometimes ignoring the Content-Type header. Unfortunately, if the filename extension indicates "message/rfc822"(via the Windows registry?) independent of the Content-Type header, and if the body of that attachment is not plain text, then Thunderbird claims the attachment is empty; clearly the attachment has a body, 805 bytes worth. Of the five attachments I provided in that bugzilla report, Thunderbird is able to somewhat deal with four attachments. It just can't properly handle the middle attachment.

--
Chip