GNOME Bugzilla – Bug 651197
message/rfc822 attachment encoded in base64 parsed correctly
Last modified: 2018-11-27 15:29:12 UTC
If you have a message with an attachment of a message/rfc822 encoded email, and the email is encoded in base64, the message does not display correctly in Evolution. Attached are two emails: - outer-regular.eml: This email has the inner (attached) email encoded as 8bit ASCII. - outer-base64.eml: This email has the inner (attached) email encoded as base64. Corresponding to each is a screenshot showing the result of each email in Evolution when trying to import them, but the same happens if the message is received via regular means (POP, IMAP...). The regular (8bit) encoded attached email renders completely correctly. The base64-encoded attached email renders incorrectly, seeming to stop parsing at the From header. Looking at the message source the problem is much worse -- Evolution shows a partial decode of the base64 block (with the headers still in tact showing it as base64-encoded), and always stopping after it hits the From header. This appears to happen regardless of where the header is. These messages were hand-crafted, but it should be noted that Django's email system generates messages like this, and encodes attached messages in base64 all the time. I didn't include Django's emails though because they contain confidential information, so I've generated two similar emails by hand with the same headers that Django would put in for the attachment. Evolution also appears to munge the "Save as mbox" function for messages received like this. But using netcat to interact with my POP3 server shows the message just fine. Looking around there seems to be one other reference to the problem, however the author simply worked around the problem instead of reporting the bug. http://ruby-msg.googlecode.com/svn/trunk/FIXES These messages appear to work fine in Apple's Mail.app, but they also seem to have problems in Icedove/Thunderbird (but exhibit slightly different responses).
Created attachment 188711 [details] base64 encoded version of the email
Created attachment 188712 [details] 8bit ascii encoded version of the email
Created attachment 188713 [details] screenshot showing bad result on base64 email
Created attachment 188714 [details] screenshot showing good result on 8bit email
Created attachment 188717 [details] showing the partial decode of the base64 This shows the email being partially decoded by Evolution. This also prevents the message from being forwarded properly.
Thanks for a bug report. I can reproduce it too with current git master, which is just after 3.1.5 release.
This is still reproducible (git master, to be 3.31.1 after few weeks). I opened [1] for gmime, which is also affected and it uses quite similar code, only in its own "copy". I did try to fix this, but I'm quite lost in the CamelMimeParser code, thus I'm afraid I'd more break than fix. [1] https://gitlab.gnome.org/GNOME/gmime/issues/1
FWIW, GMail has problems with these as well, based on my experience with their IMAP responses for these types of messages. GMail (and potentially other IMAP servers) will send body-part-basic expressions instead of body-part-msg expressions when they encounter message/rfc822 MIME parts that are illegally encoded using base64 (or quoted-printable?). According to rfc3501, IMAP servers are REQUIRED to send body-part-msg expressions for message/rfc822 parts, however, it is understandable why GMail (and other IMAP servers?) do what they do in this particular case because they clearly handle this error in the same fashion that I opted to handle it in GMime - which is to treat encoded message/rfc822 body parts as opaque leaf-node (aka 'basic') body parts. For an example of GMail's IMAP response, see https://github.com/jstedfast/MailKit/issues/32#issuecomment-39682556
Seems Thunderbird also has issues: https://bugzilla.mozilla.org/show_bug.cgi?id=333880
I fixed it inspired by changes in GMime: https://gitlab.gnome.org/GNOME/gmime/issues/1#note_373164 I commit it to the development version only, in case it would have some side effects I'd not notice during my tests. Created commit [1] in eds master (3.31.3+) [1] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/52deccba5