Is the email shareable?

Created attachment 255162 [details]
Offending email

This sample message triggers the same warning.

And also fails to display the inline image. Thunderbird has a similar issue (this message is taken from https://bugzil.la/883932 )

Thunderbird does at least seem to show the image as an attachment, We don't show it at all.

Thanks. I can reproduce it with your message too.

The problem is how they reference the image. They use
   src="d0176599-66b6-4266-b625-1b33c4b206ee.png"
while the correct way of identifying attached images is through their Content-ID header (the image has that header, interestingly), thus something like this:
   src="cid:121dbd5e-15af-4ff5-9355-42e54bcba13f"

Evolution (or maybe webkit) turns the first reference into a full URI, which looks like:
   mail://<account-uid>/path/to/mail/d0176599-66b6-4266-b625-1b33c4b206ee.png
which is not part of the part list, thus the request for it returns NULL. Email message is referenced as
   mail://<account-uid>/path/to/mail/652245
where the last number in the path is message ID.

Using correct cid notation turns the request for the image to:
   mail://<account-uid>/path/to/mail/652245?part_id=cid%3A121dbd5e-
   15af-4ff5-9355-42e54bcba13f&mode=3
which works as expected, the image is shown. I also made a typo in the cid, then I've got this runtime warning instead:

>evolution-mail-CRITICAL **: handle_mail_request: assertion `part != NULL' failed

('part_list' changed to 'part' - it failed later).

From that I'd say, the two runtime warnings are misleading, they only claim when a broken message is parsed. Thus I would remove them, and add debug prints showing what was requested and whether anything was found instead. I do not want to support broken mail generator (also see [1]).

The other part, why the image was not shown as an attachment, is bug in evolution. I see it was properly recognized as attachment, but it was left hidden for some reason (probably because of the "inline" notation inside multipart/related part). I'll investigate this further.

[1] http://tools.ietf.org/html/rfc2392

I committed some debugging functions into evolution for 3.11.1+ (commit 6d96953) and 3.10.1+ (commit 59fbba3) which apart of debugging itself avoids the runtime warnings from this bug report. It doesn't show the hidden attachment from the multipart/related part.

Created attachment 256077 [details] [review]
evo patch

for evolution;

Let's try this way. The first thing is that the multipart/related parser didn't expect the 'display part' being multipart/alternative, thus I added there this check and a traverse for a text/html part (for the CID usage checking).

As the next change, in case the CID part is not referenced in the text/html part, and it's an image, wrap it as a real attachment.

One problem is that the parser doesn't know whether the picked text/html part will be displayed at all, though I believe it's a pretty good guess, because you either get those multipart/related images as attachments or shown in the HTML body, when it's rendered.

Created commit 6a65912 in evo master (3.11.1+)
Created commit b1005b6 in evo gnome-3-10 (3.10.1+)