GNOME Bugzilla – Bug 217678
Message parser not detecting attached file on multipart/alternative message
Last modified: 2002-01-31 02:19:25 UTC
Description of Problem: I received a multipart/alternative message (you know: the ugly text/HTML) with an attached jpeg file. Evolution does not display the attachment at all. The message parser seems to have not clue that the jpeg file is attached. The message format appears to be a multipart/related or which the first part is the multipart/alternative text and the second part is the attached jpeg. The encoded attachment text shows up if you select 'View -> Message Display -> Show email source', but is never visible otherwise. I've only had the problem on the multipart alternative messages. I was able to save the attachment with mutt, then forward it back to myself (reattaching the file) and evolution would be able to see the file. Steps to reproduce the problem: I've enclosed a link to an example message (from my Mom :) under 'Additional Information'. How often does this happen? I've received two emails of this format (both mailed from Outlook 8.5) both suffering from the problem. Additional Information: A sample message exhibiting the problem can be found at http://lifesavers.ca/~rcp/evobug.msg
each part inside an multipart/alternative is an "alternate" way of displaying the message. This, if you have a text/html part and an image/jpeg part in the multipart/alternative, you only show 1 of the 2 parts. now, if it was a multipart/mixed, then we'd display whatever parts we could and show the others as attachments. so technically this is not a bug with Evolution but rather with the client that sent the original message.
*** This bug has been marked as a duplicate of 202741 ***
The MIME structure is correct: multipart/related multipart/alternative text/plain text/html image/jpeg Evo displays the text/html variant of the multipart/alternative, but for some reason does not pick up the image/jpeg referenced by cid. Maybe it doesn't think the cid is valid? (It's unusual, but looks rfc-compliant to me.)
Looks like the [] syntax has never been tested. The decoder was converting [foo] into [ foo ], I guess for readability when it was first written 2 years ago. I've fixed it up (in head version). Nice pic btw.