Bug 1368506

Summary: Evolution not show images in messages such as attached here
Product: [Fedora] Fedora Reporter: Mikhail <mikhail.v.gavrilov>
Component: evolutionAssignee: Milan Crha <mcrha>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: lucilanga, mbarnes, mcrha, tpopela
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-24 12:33:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
example message
none
screenshot
none
But picture displayed well through Web interface.
none
original headers none

Description Mikhail 2016-08-19 15:18:08 UTC
Created attachment 1192173 [details]
example message

Description of problem:
Evolution not show images in messages such as attached here

Version-Release number of selected component (if applicable):
$ rpm -qa | grep evolution | sort
evolution-3.20.5-1.fc24.x86_64
evolution-data-server-3.20.5-2.fc24.x86_64
evolution-data-server-debuginfo-3.20.5-2.fc24.x86_64
evolution-debuginfo-3.20.5-1.fc24.x86_64
evolution-ews-3.20.5-1.fc24.x86_64
evolution-ews-debuginfo-3.20.5-1.fc24.x86_64
evolution-help-3.20.5-1.fc24.noarch

How reproducible:
Import attached message

Comment 1 Milan Crha 2016-08-22 09:25:06 UTC
Thanks for a bug report. It's correct, because the mail client which created the message created it incorrectly. It claims that the image is base64 encoded, but it's not, it's stored without any encoding (which is particularly wrong). I do not see whether this happened on the sending side, or on the server from which you download it. It has quite few headers, for example none Received header, thus maybe it was created in a web interface?

Comment 2 Mikhail 2016-08-22 20:22:46 UTC
Created attachment 1193070 [details]
screenshot

Comment 3 Mikhail 2016-08-22 20:31:29 UTC
This is outgoing message. Of course I not remember which mail client I used at that date, but exactly can say that it was another computer.

Comment 4 Milan Crha 2016-08-23 04:53:44 UTC
(In reply to Mikhail from comment #3)
> This is outgoing message. Of course I not remember which mail client I used
> at that date, but exactly can say that it was another computer.

The message headers do not tell much about the origin, maybe it was Gmail Web interface. I'll try to reproduce this later.

Comment 5 Milan Crha 2016-08-23 17:37:03 UTC
I tried to reproduce this, but no luck. I edited an HTML message in the Evolution 3.20.5 and in the Gmail web interface and the part with the inline image was always properly encoded as base64, thus the image was shown properly. I tend to close this as insufficient_data, until the steps to reproduce will be found. It can be some older version of the evolution incorrectly saved the draft image, it's only that the current stable Evolution (3.20.5) works properly.

Comment 6 Mikhail 2016-08-23 18:57:18 UTC
Created attachment 1193409 [details]
But picture displayed well through Web interface.

Comment 7 Mikhail 2016-08-23 18:59:23 UTC
Created attachment 1193410 [details]
original headers

Comment 8 Milan Crha 2016-08-24 12:33:19 UTC
The Gmail web interface is smarter than the evolution, then (and doesn't follow corresponding RFC). The attachment is incorrectly saved in the message, or an error happened when the Gmail interface transformed the message into the MIME content (like for the IMAP transfer, or the image with the "headers" above, where is shown that the image part is claimed to be base64-encoded, but it isn't). Whoever created the MIME message did it wrong. I do not blame any software, it could be also the evolution, but I cannot reproduce it, thus neither fix it.