Description of problem: multipart mime message are not handled correctly: when an attachment is present in such a message, then the attachment is not shown/accessible Version-Release number of selected component (if applicable): thunderbird.x86_64 5.0-1.fc15 How reproducible: always Steps to Reproduce: 1. see description 2. 3. Actual results: attachment is not shown/accessible Expected results: attachment is shown/accessible Additional info: I see this is at least one message with the problem: ...headers Content-Type: multipart/related; boundary="_c64d9c91-d488-4df1-8edf-345d847ea685_" ...headers MIME-Version: 1.0 ...headers --_c64d9c91-d488-4df1-8edf-345d847ea685_ Content-Type: multipart/alternative; boundary="_ee4201c5-1c20-4014-b7d8-e2ba347edffa_" --_ee4201c5-1c20-4014-b7d8-e2ba347edffa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ... --_ee4201c5-1c20-4014-b7d8-e2ba347edffa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ... --_ee4201c5-1c20-4014-b7d8-e2ba347edffa_-- --_c64d9c91-d488-4df1-8edf-345d847ea685_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Vries-27540-1.pdf" ... --_c64d9c91-d488-4df1-8edf-345d847ea685_ Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <image001.jpg> Content-Disposition: attachment; filename="image001.jpg" ... --_c64d9c91-d488-4df1-8edf-345d847ea685_ Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <image002.gif> Content-Disposition: attachment; filename="image002.gif" ... --_c64d9c91-d488-4df1-8edf-345d847ea685_ Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <image003.gif> Content-Disposition: attachment; filename="image003.gif" ... --_c64d9c91-d488-4df1-8edf-345d847ea685_ Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <image004.gif> Content-Disposition: attachment; filename="image004.gif" ... --_c64d9c91-d488-4df1-8edf-345d847ea685_ Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <image005.gif> Content-Disposition: attachment; filename="image005.gif" ... --_c64d9c91-d488-4df1-8edf-345d847ea685_--
this is quite a serious regression see https://bugzilla.mozilla.org/show_bug.cgi?id=674473
downgrading to thunderbird 3.1.10-1.fc15 makes the attachment accessible again major regression
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. I haven't reproduced it so far here with the current Thunderbird. So, we need more information to be able to reproduce the issue here. 1) Are you able to reproduce this when running Thunderbird in the safe mode (i.e., run it with parameter -safe-mode on the command line) 2) Are you able to reproduce the problem with the upstream binary from http://www.mozillamessaging.com/? 3) Are you able to reproduce the problem with a fresh profile? Could you please attach one example email which shows this issue, please? Thank you for your cooperation and helping to make Fedora more awesome! We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Sorry, you don't have to bother with any more testing. This is truly NOTABUG. Multipart/related MIME scheme (http://en.wikipedia.org/wiki/MIME#Related) is not meant to show attachments. It is used for things like HTML pages with attached images, etc. The typical MIME type which does show attachments is multipart/mixed. Closing this bug here as a CLOSED/NOTABUG and making a comment in the same sense in the upstream bug.
I do not agree!! Please read RFC2387 (linked from your wikipedia article, http://tools.ietf.org/html/rfc2387), section 4. Especially about content disposition. Ok, it says that in the case of Multipart/Related the content disposition shall be ignored, but at the same time it says that it's allowed. Clearly not a very well worded RFC. Since the mail I'm having problems with is most probably sent by M$ tooling, I think we have a classic case of M$ interpreting the RFC the way it likes, e.g. in a 'non-compliant' way. Ignoring this is stupid, sorry for the strong words. M$ tooling somehow is still dominant and until they've fixed it (never), our tooling needs to handle their quirks, whether we like it or not. Besides, thunderbird 3 handles the emails correctly so it _is_ a regression.
I suggest that for multipart/related messages: - anything that is _not_ used in the message is shown as an attachment, - anything that is marked with a content disposition of attachment in the message is also shown as an attachment
(In reply to comment #6) > I suggest that for multipart/related messages: > - anything that is _not_ used in the message is shown as an attachment, > - anything that is marked with a content disposition of attachment in the > message is also shown as an attachment Whether you agree or not, please keep this discussion in the upstream bugzilla. It has certainly nothing to do with Fedora packaging, which is what matters in this bugzilla. Thank you