GNOME Bugzilla – Bug 769868
Improve multipart handling
Last modified: 2021-07-05 13:27:49 UTC
Currently, to generate a message body for display to the user, Geary just traverses the multipart tree and concatenates text parts together. This does not pay attention to the multipart structure of the email however, making it hard to know if say a text part is properly an attachment, or if a non-text part has been referenced inline or not and needs to be included as an attachment. Geary should be looking for and properly handling multipart/alternative, multipart/related, multipart/mixed, and multipart/digest, at least. And the UI needs to be able to keep track of which parts have been consumed and which parts should property be ignored, so that it can ensure that alternative parts are not inappropriately displayed and parts that should have been included inline but weren't referenced by other parts are still presented to the user. We also should add unit tests to that ensure that the code does the right thing with previously fixed bugs, and to ensure things don't break in the future. Related reading: * RFC 2046 - MIME Part Two: Media Types, Section 5 https://tools.ietf.org/html/rfc2046#section-5 * RFC 2387 - The MIME Multipart/Related Content-type https://tools.ietf.org/html/rfc2387 * https://msdn.microsoft.com/en-us/library/ms527355(v=exchg.10).aspx * http://stackoverflow.com/questions/3902455/smtp-multipart-alternative-vs-multipart-mixed
Some example structures: Plain text with displayable inline part (Mew/Emacs, Bug 767438): * multipart/mixed * text/plain <-- Not used as the body * image/png (disposition: inline) Plain text and undisplayable inline parts (Apple Mail): * multipart/mixed * text/plain * application/pdf (disposition: inline) <-- Not displayed HTML with unreferenced image (Inbox by Google, Android): * multipart/related (no type!): * multipart/alternative: * text/plain * text/html <-- Did not include an IMG element * image/png (disposition: inline) <-- Hence not displayed Attachments without a disposition (Bug 713830): * multipart/mixed * text/html * image/jpg <-- ??? * application/octet-stream <-- Not displayed Related HTML with inline images (Bug 743676): * multipart/alternative * text/plain * multipart/related (type: text/html) * text/html * image/jpeg (disposition: inline) <-- Not displayed A complex example that works with a number of mailers (from Stack Overflow link above): * multipart/mixed * multipart/alternative * text/plain * multipart/related * text/html * image/foo (disposition: inline) * something/something (disposition: attachment)
An HTML mailout: * multipart/mixed * multipart/related (No type!) * multipart/alternative * text/html <-- Did not include an IMG element * image/png (disposition: inline) <-- Hence not displayed
An MMS from Optus: * multipart/mixed * text/plain (disposition: attachment) <-- Not displayed
Yet more annoying Mailman behaviour: * text/plain <-- Mailman footer simply appended to the end of the part * multipart/mixed * text/html * text/plain (disposition: inline) <-- Mailman footer, not displayed because of the HTML part * multipart/mixed * multipart/alternative * text/plain * text/html * text/plain (disposition: inline) <-- Mailman footer, also not displayed because of the HTML part Ubuntu Security notice sent via Mailman: * multipart/mixed: * multipart/signed (disposition: inline) * text/plain (disposition: inline) * application/pgp-signature <-- Displayed as attachment * text/plain (disposition: inline) <-- Mailman footer, displayed fine
I'm thinking the best way to implement this is to break out the code that handles this out of Geary.RFC822.Message into a separate walker class, so it can be used there and for generating preview text as well (see Bug 714317). Rather than a simple, single recursive procedure, there should be a method that specifically handles each supported multipart container, which implements specific policy about what to do for that part (choose an alternative, convert and merge, ignore, etc). The walker might also want/need to generate a list of attachments, etc, as it goes.
*** Bug 793639 has been marked as a duplicate of this bug. ***
From Bug 793639: /Sending/ a text body with HTML signature: * multipart/mixed (disposition: inline) * text/plain (disposition: inline) * text/html (disposition: inline)
Bump tickets to 0.14 that aren't going to make 0.13.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/geary/-/issues/ Thank you for your understanding and your help.