After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 651197 - message/rfc822 attachment encoded in base64 parsed correctly
message/rfc822 attachment encoded in base64 parsed correctly
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.2.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2011-05-26 22:40 UTC by Michael Farrell
Modified: 2018-11-27 15:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
base64 encoded version of the email (2.42 KB, message/rfc822)
2011-05-26 22:41 UTC, Michael Farrell
Details
8bit ascii encoded version of the email (2.09 KB, message/rfc822)
2011-05-26 22:41 UTC, Michael Farrell
Details
screenshot showing bad result on base64 email (7.84 KB, image/png)
2011-05-26 22:42 UTC, Michael Farrell
Details
screenshot showing good result on 8bit email (9.87 KB, image/png)
2011-05-26 22:42 UTC, Michael Farrell
Details
showing the partial decode of the base64 (31.10 KB, image/png)
2011-05-26 23:22 UTC, Michael Farrell
Details

Description Michael Farrell 2011-05-26 22:40:40 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).
Comment 1 Michael Farrell 2011-05-26 22:41:26 UTC
Created attachment 188711 [details]
base64 encoded version of the email
Comment 2 Michael Farrell 2011-05-26 22:41:48 UTC
Created attachment 188712 [details]
8bit ascii encoded version of the email
Comment 3 Michael Farrell 2011-05-26 22:42:33 UTC
Created attachment 188713 [details]
screenshot showing bad result on base64 email
Comment 4 Michael Farrell 2011-05-26 22:42:56 UTC
Created attachment 188714 [details]
screenshot showing good result on 8bit email
Comment 5 Michael Farrell 2011-05-26 23:22:54 UTC
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.
Comment 6 Milan Crha 2011-08-17 14:38:13 UTC
Thanks for a bug report. I can reproduce it too with current git master, which is just after 3.1.5 release.
Comment 7 Milan Crha 2018-09-18 12:52:51 UTC
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
Comment 8 Jeffrey Stedfast 2018-11-26 14:36:14 UTC
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
Comment 9 Jeffrey Stedfast 2018-11-26 15:42:31 UTC
Seems Thunderbird also has issues: https://bugzilla.mozilla.org/show_bug.cgi?id=333880
Comment 10 Milan Crha 2018-11-27 15:29:12 UTC
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