GNOME Bugzilla – Bug 202741
dealing with broken use of multipart
Last modified: 2013-09-10 14:02:43 UTC
Some mailers seem to use multipart/related when they should use multipart/mixed. We need to keep track of attachments that are referred to by the main part of the multipart/related, and then display the remaining attachments as attachments.
I've been getting broken emails from Kevin. (Quite a few as I think back to it now.) Below is the relevant headers of the email. X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: multipart/related; boundary="=-lnmySJtMBOCYR3GVHRqT" I'd mark this as fairly important since it makes reading your email from these people impossible. I'd normally call this a 1.0...
Also re-reported by a Lucy beta tester. In his case, it was an HTML mail that contained links like <a href="foo.doc">foo.doc</a> at the end, referring to the attachments by filename. A good solution to this might be hard, so we may need a bad one. :-/
I'm going to mark this feature since (1) it is fairly important (2) it might require a big time investment so it should be considered for scheduling purposes.
don't forget multipart/alternative (such as this duplicate below).
*** bug 217678 has been marked as a duplicate of this bug. ***
Just got a message in which something which should have been multipart/related was encoded as multipart/mixed instead. Evo picked up the embedded image correctly, but also displayed it as an attachment. (Which is correct according to the MIME structure, but ugly since it's not what the sender meant.)
Can we have some examples attached here please? BTW on that last case, if you do have embedded images, can you save them?
Well. We dont know if anything's been referenced until after we've finished and closed off the html stream. But hten we need to create a new one from scratch to make any changes ... Basically this means related/mixed needs to be handled the same way. Perhaps we need to pre-parse the html simply to get data like this out of it.
Created attachment 41007 [details] broken message
These seem to get generated when Outlook is configured to use RTF, but something (either another part of Outlook or the Exchange server) is set to translate RTF to HTML. I compared this message with an HTML message with embedded images (correct use of multipart/related), and found that it assigns Content-IDs to the attachments in that case, but not in the broken case.
talked with larry - gtkhtml *will* process its data before the stream is closed. so we can write all data, possibly flush, then check which objects were requested, then write more data, etc. so this should well enough, particularly for this case.
Should be fixed now. It has a bit of a hack used to flush the html stream (gtk_main_iteration()), but it seems to work, and will only cause performance issues with digests of related messages and/or broken messages. if gtkhtml_stream had a flush, it could use that instead.
Created attachment 41183 [details] multipart/related with unreferenced jpeg not displayed
I got a multipart/related message (sent by Outlook Express) with a text/plain and a image/jpeg part. Since the text/plain part doesn't reference the jpeg (how could it?), the image should show up as an attachment.
this bug was only fixed in the development branch, not 1.0.x