User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110615151330 Steps to reproduce: I received emails with attachment. Actual results: Attachment in multipart/related email are not displayed if MIME boundary is set to ----=_Part_0_25629950.1311751966940 The emails received are multipart/related and contain 2 parts. According to what I had read the boundary is valid. Find below a copy paste of email text source: [... removed ...] MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_0_25629950.1311751966940" ------=_Part_0_25629950.1311751966940 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit [... removed ...] ------=_Part_0_25629950.1311751966940 Content-Type: application/octet-stream; [... removed ...] ------=_Part_0_25629950.1311751966940-- Expected results: an attachment should had been listed.

This bug forced me to downgrade Thunderbird.

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. Suggesting closing of this bug as INVALID

I'll repeat what I said on the RH BZ, see https://bugzilla.redhat.com/show_bug.cgi?id=728602. 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

Per discussion in bug 602718, reopening this RFE to cover this specific case. There are other duplicates, but this one here contains already some important references to the RFC sections, thus it's preferred over opening a new bug. While it is a regression over TB 3.x behavior, it cannot be expected to behave this way given that the message in itself is not accordingly formatted. While it's easy to dismiss this as a standard-compliance issue, it prevents affected users from accessing the MIME part entirely. The solution in bug 602718 would provide for a hidden preference for a menu item allowing to ignore the actual context of a MIME part and effectively provide any MIME part as attachment. The proposal here should be incremental to that fix and show clearly inaccessible MIME parts in the attachment pane. It should be restricted to: - MIME parts in multipart/related context without a Content ID - MIME parts in multipart/related without a referring "cid:" URI - MIME parts in multipart/related which cannot be displayed inline For a test case, see bug 674704 attachment 548920 [details].

Would it be reasonable to add an option along the lines of "Show hidden attachments" that lists as a "proper" attachment anything that we'd normally ignore? This lets us show the standards-compliant representation of a message by default, but would make it easy for people to access hidden attachments in malformed messages without changing how the body is displayed (which is what bug 602718 does). This would also be useful for people who want to save all the inline images in a properly-formed multipart/related message.

That's what I had in mind in bug 602718 comment #22 for option (v), adding some toggle similar to View > Display Attachments Inline for the "All Parts" option without changing the actual display (i.e., only updating the attachment pane). I think Jonathan went the way modifying the View > Message Body As options because it was easier to implement and to access the "hidden" attachment.

(In reply to Jim Porter (:squib) from comment #7) > Would it be reasonable to add an option along the lines of "Show hidden > attachments" that lists as a "proper" attachment anything that we'd normally hidden? the _intent_ of the message is _not_ to hide the attachments so TB should not call it hidden. the attachments must always be shown automatically because that is what the user expects: if there is an attachment, I see it in the attachment pane. Do you really expect them to toggle this menu item all the time? If it is a toggle per message then think again, if it is a global toggle them any user that is actually able to discover the toggle _and_ understand what is going on (increasingly unlikely) will keep the toggle on all of the time. so, show the attachments all of the time, it's what the user expects. no hiding. > ignore? This lets us show the standards-compliant representation of a > message by default, but would make it easy for people to access hidden why are you guys so hung up on standards compliant representation. also showing the attachments (either just all of them or only the unused ones) doesn't really affect the representation now does it? The body is not affected at all.

(In reply to Jonathan Kamens from comment #117, bug 351224) > (In reply to Ferry Huberts from comment #103) > > 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 > > Yes, this is the behavior that I would like to see as well, but > unfortunately is hard to implement, and in fact the "correct" implementation > would involve ripping out the internals of the Thunderbird MIME parser and > replacing them with an object-based architecture rather than a stream-based > architecture. I just don't have the time to do that right now, although > perhaps someone else will. I don't know the code at all, but something like below should be fairly easy to implement: - when you encounter a mime part, put its filename, beginbyte in the stream, endbyte in the stream, id, etc in a list. - when a mime part is used, then mark it as used in the list. - at then end of the stream, prune all used mime parts, but not those marked with a content disposition of attachment - any mime parts left in the list are unused and must be shown as attachments - do a 'callback' providing the list of unused mime parts so that they can be shown. you could also do callbacks on every mime part to do different things. > > I should be clear that I don't think that's the _only_ way the behavior you > propose could be implemented. I think it's probably feasible to keep the > current architecture and just modify the multipart/related parser to behave > as you proposed. But it's not straightforward, and as the existence of this > bug proves, the code is so difficult to maintain that any changes to it > would tend to have unanticipated and potentially negative side effects. > > FWIW, I think this is a serious enough issue that the patch I wrote for this > bug should be applied to an earlier release than TB8, albeit perhaps not > TB5, but I just don't have the energy to argue strongly for that.

(In reply to rsx11m from comment #8) > That's what I had in mind in bug 602718 comment #22 for option (v), adding > some toggle similar to View > Display Attachments Inline for the "All Parts" > option without changing the actual display (i.e., only updating the > attachment pane). Looking over that bug, it seems that most people are in agreement that this would be a good way to handle things, especially since it addresses other use cases as well (e.g. being able to easily save many images from a *well-formed* multipart/related object). I'm not sure what we should do for other strange messages, like multipart/alternative parts that contain a subpart we can't render (e.g. application/pdf). However, we should be able to do that in a followup bug and just piggyback on the "show hidden attachments" pref. > I think Jonathan went the way modifying the View > Message Body As options > because it was easier to implement and to access the "hidden" attachment. I believe the difficulty he's talking about is in bug 351224 comment 35: > "Multipart/alternative means pick one part to display and don't display the > others, except that if one of the parts is multipart/related and it's not the > part we picked to display and it has images in them that would be treated as > inline images if it WERE the part we picked to display, then instead of > displaying them as inline images, display them as attachments. I think we could probably simplify this quite a bit if we assume the existence of a "show hidden attachments" pref: "Multipart/alternative means pick one part to display and don't display the others, except if 'show hidden attachments' is enabled, then show every subpart* from every part in the attachment pane." * I'm not sure if the root subpart of a multipart/related should count as an attachment here or not.

(In reply to Ferry Huberts from comment #10) > I don't know the code at all, but something like below should be fairly easy > to implement: Generally speaking, one should refrain from commenting on what "should be fairly easy to implement" in code that one does not know at all. Unless, of course, one is volunteering to do the implementing. I am getting just a little bit frustrated by people who don't seem willing to believe me when I say this is hard to fix. Maybe I am wrong. Maybe it is actually easy to fix, despite the fact that I tried and gave up after hours of trying to get it to work properly. I am happy to accept correction from someone who can do better. I am not invested in my opinion of the code and would be happy to be proven wrong. I am not, however, so happy to be contradicted by people who admit to not knowing they're talking about.

(In reply to Jim Porter (:squib) from comment #11) > I believe the difficulty he's talking about is in bug 351224 comment 35: > > > "Multipart/alternative means pick one part to display and don't display the > > others, except that if one of the parts is multipart/related and it's not the > > part we picked to display and it has images in them that would be treated as > > inline images if it WERE the part we picked to display, then instead of > > displaying them as inline images, display them as attachments. No, that's not what I'm referring to. And note that you are taking that quote out of context. I wrote that as a description of an absurdly convoluted behavior which I believe the application should *not* have. That was in response to people who were saying that when the message body is viewed as plaintext, all the attachments should show up in the attachments pane. That's not actually the correct behavior of the application in any circumstances; that's just the workaround that people were using to get access to attachments. I think it's important to realize that there are actually two different use cases being discussed: 1. Getting access to "hidden" attachments, i.e., attachments that cannot be seen because some other mail software has formatted the MIME incorrectly. In other words, sticking an attachment into a multipart/related body part without any reference to it in the HTML body of the multipart/related. 2. Getting access to attachments which would not normally be shown as attachments, and indeed aren't shown as attachments in most mail clients, most notably inline images, but also perhaps embedded audio. We've already fixed use case 2 in the patch I submitted that will be in Thunderbird 8. This is an extremely unusual use case and I think the View | Message Body As | All Body Parts is more than adequate for the small number of users who care about it. It's use case 1 which we haven't addressed and which is the topic of this bug. I'd like us to be careful not to muddle that use case with use case 2. The correct fix for use case 1 is, as I and others have proposed, to figure out which attachments aren't linked to from the displayed body of the message, and to display those attachments in the attachments pane. The reason why this is so hard to do is because the streaming MIME parsing model makes this kind of logic incredibly difficult to get right, and the code is twisted and complex and poorly commented (just as one example, there's a commend at the top of the multipart/related file describing three completely different proposed architectures for how to handle multipart/related body parts, with no indication of which one the code actually implements). It's also over 1,200 lines of code. If someone else has time to read through all the existing code, grok it, and figure out exactly how to tweak it to produce the desired behavior, I'm totally supportive of that. But I don't have the time, and if I did have the time, I'd instead spend it ripping out the MIME parser and replacing it with something maintainable.

(In reply to Jonathan Kamens from comment #13) > No, that's not what I'm referring to. And note that you are taking that > quote out of context. I wrote that as a description of an absurdly > convoluted behavior which I believe the application should *not* have. I know. Sorry if I didn't make it clear that's what you were talking about. > We've already fixed use case 2 in the patch I submitted that will be in > Thunderbird 8. This is an extremely unusual use case and I think the View | > Message Body As | All Body Parts is more than adequate for the small number > of users who care about it. I'd hesitate to call this "extremely unusual", since we don't have any data on that, but I agree that it's probably ok for now. > The correct fix for use case 1 is, as I and others have proposed, to figure > out which attachments aren't linked to from the displayed body of the > message, and to display those attachments in the attachments pane. Technically, any behavior is "correct" when you're dealing with malformed messages. If it were up to me, I'd have Thunderbird automatically send angry emails to people who send malformed messages. :) Again, I'd really like to have hard numbers for this, but I think there are other cases where a person might want to get at MIME parts that are currently hidden. For instance, multipart/alternative parts that we don't support (event invitations, pdfs, etc). I seem to recall there being issues with event invitations where the invitation is the last part in a multipart/alternative, but the text/plain and text/html parts are empty. Clearly this is malformed, but I don't think we should be showing unsupported multipart/alternative parts by default; the whole point of multipart/alternative is that you can pick any part you like and render it, and the user will have the message he expects (modulo some formatting or application integration). What I'd like to see is an option that people can set and forget about it to see all the attachments from all the myriad malformed messages out there. I think that trying to handle every possible case automatically is a Sisyphean task; I'm continually surprised by all the ways people manage to malform their messages. The "all body parts" option gets us pretty close to an option like this, but since it modifies how we render the body, people are forced to choose between properly-rendered bodies and complete attachment lists. > If someone else has time to read through all the existing code, grok it, and > figure out exactly how to tweak it to produce the desired behavior, I'm > totally supportive of that. I'm participating in this bug since I work on libmime pretty regularly (well, sort of regularly, anyway), and I've been thinking about ways to implement this. If I come up with a decent way, I'll do it myself. > if I did have the time, I'd instead spend it ripping out the MIME parser and > replacing it with something maintainable. jcranmer is discussing doing just this (and I've tentatively said I'd help) on mozilla.dev.apps.thunderbird. That'll take quite a while though. All that said, I'm open to ideas to handle things a bit better automatically, but I do think we should strive to be standards-compliant by default. It's unfortunate that shoddy tools force us to discuss ways to ignore standards (if not outright violating them) in order to handle their output.

(In reply to Ferry Huberts from comment #9, with respect to bug 682226 that I filed) I second Ferry - please do not add another option. I am sure my users would not find it. And I would not have found it myself because I did not know that I should be looking for it. Usually people forget about adding attachments (if they dont use TB ;-) so I would not look for an option in my TB if an attachment is missing. Rather take the risk of showing too many attachments in the list than too little. Its better to get something twice than missing it totally. Regarding standards conformity: It is likely that certain large software companies interpret standards in strange ways - bad enough. But there are also many tools like phpmailer, used by webmasters and many other people for sending newsletters or the like. Many of these people might not be very familiar with all MIME options, and therefore we probably should expect a considerable number of not fully compliant messages out there... So, this is another voice for being as tolerant as possible. But (just an idea), there could be a warning from TB in the area above the message, saying sth like "This message appears to be not fully standard-compliant. Therefore, possibly not all attachments can be shown and/or some might be shown twice. Please contact the sender."

I plan on starting a discussion about this and other related MIME issues on mozilla.dev.apps.thunderbird in the coming days, so be on the lookout.

To all requester of enhancement of this bug even after enhancement by 602718: What is bad for you in viewing mail sent from Outlook(multipart/related mail, text/html and non-displayable parts in multipart/related), if View/Message Body As/All Body Parts is used as main/usual choice of View/Message Body As? If simple text/html mail or text/plain mail(no multipart), no problem. If text/html+embed_images and some non-displayable parts under multipart/related, problems with View/Message Body As/All Body Parts are : (i) <img src="cid:..."> is not rendered, although mail body(text/html) is rendered as if View/Message Body As/Original HTML. (ii) Any part is shown as if attachment at attachment pane, and any part shown at attachment pane can consistntly be detached/deleted. So, even mail body part(text/html part) can be detached/deleted because the mail body part is also shown as if attachment at attachment pane, so mail can easily be corrupted by user. If multipart/alternative mail of { text/plain + multipart/related(text/html+embed_images+pdf+wav+...) } : (iii) both text/plain part and text/html part is rendered. It may be annoying in daily use. If digital signed mail : (iv) part for digital sign can be deleted, and mail is easily corrupted by user. Is (i) very big issue for you? As for detech/delete, (ii) is very consistent with request from some users such as "bug 351224 comment #0", "need to detach/delete embed images of html mail". By (ii), user can detach/delete any part under multipart/xxxx. Is (ii) very big issue for you? (iii) may be annoying. I think View/Message Body As/All Body Parts is currently not so suitable for daily use, but I also think it can be used as main/daily setting if "button for ad-hoc View/Message Body As"(applied to current mail only) will be implemented. This is already opened request, and was mainly for "Global View/Message Body As/Plain Text" and "button for ad-hoc HTML rendering". It's for protection from spam/scam. If "quirks for non-displayed part in multipart/related"(show as if attachment) will revive in "View/Message Body As/Orignal(or Simple) HTML and/or Plain Text", next issues should be resolved. (a) What part is real attachment and what part is not real attachment. Which part can be detached/deleted an which part can not be detached/deleted. (b) How difference between "real attachment" and "not real attachment" can be notified to user via UI? Please note that biggest problem in old "quirks for non-displayed part in multipart/related" was inconsistency between detach/delete.

(In reply to Jim Porter (:squib) from comment #16) > I plan on starting a discussion about this and other related MIME issues on > mozilla.dev.apps.thunderbird in the coming days, so be on the lookout. Jim, You can't get a discussion, unless folks know where it is taking place. Noted in url field.

(In reply to Philippp from comment #15) > (In reply to Ferry Huberts from comment #9, with respect to bug 682226 that > I filed) > > I second Ferry - please do not add another option. I am sure my users would > not find it. Another "thumbs up" for Ferry. As to standard-compliance, imagine telling a Manager of a large international corporate company that he should be glad to have a standard-compliant email-client. Imagine advising him that he has two possibilites: a) live with the fact that you can't see the important attachments from your valuable, money-making business contacts, or b) every time you read an email, go to the options menu and flick a switch to make sure you really see every attachment there is. Now, try to imagine his reactions. I'm sure it wouldn't take long until the word 'Outlook' would come up. As to importance of this bug, imagine being the manager.

I have an email with a similar issue but it does not mention multipart/related; It has: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC6E26.EB593658" [... removed ...] ------_=_NextPart_001_01CC6E26.EB593658 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [... removed ...] ------_=_NextPart_001_01CC6E26.EB593658 Content-Type: application/octet-stream; name="foo.pdf" Content-Transfer-Encoding: base64 Content-Description: foo.pdf Content-Disposition: attachment; filename="foo.pdf" [... removed ...] ------_=_NextPart_001_01CC6E26.EB593658--

(In reply to Ian Neal from comment #23) > I have an email with a similar issue but it does not mention multipart/related; >(snip) > Content-Type: application/octet-stream; name="foo.pdf" This bug is only for a multipart/related relevant issue. Your case looks same as next bugs or a variant of next bugs; regression or side/bad effect by quirks for application/octet-stream. > 517796 thunderbird does not let me view application/octet-stream attachments > 559014 provide open-with dialog for application/octet-stream > 665869 PDF file with mime-type application/octet-stream is opened inline in SeaMonkey 2.x

(In reply to Ernst Maier from comment #22) > As to standard-compliance, imagine telling a Manager of a large > international corporate company that he should be glad to have a > standard-compliant email-client. Imagine advising him that he has two > possibilites: a) live with the fact that you can't see the important > attachments from your valuable, money-making business contacts, or b) every > time you read an email, go to the options menu and flick a switch to make > sure you really see every attachment there is. > > Now, try to imagine his reactions. I'm sure it wouldn't take long until the > word 'Outlook' would come up. > > As to importance of this bug, imagine being the manager. I completely subscribe to this view. Working for the IT of a >10.000 employee organisation using Thunderbird (at the moment 2.x & 3.x) as the default mail client, I dare to say that Thunderbird won't be an option any more if the client guys have to tell the management that they won't see attachments of mails sent with Oulook any longer.

3rd Ferry _ \`\ |= | /- ;.---. _ __.' (____) ` (_____) _' ._ .' (____) ` (___) --`'------'

Absolutely agree with Ferry and Ernst. Upgraded to TB5 month ago. Saw this bug, downgraded. Now upgraded to 6.0.1. Same bug is still on, multiple bugreports here, and this is a MAJOR regression over TB3, so it's hard to accept that this is a hard-to-fix thing, which should go through multiple major versions, when it was working perfectly once... Now go downgrade again...

You guys at Mozilla should read this AND TAKE A HINT: http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/ba-p/440 Quote: Torvalds concludes, “Way too many projects seem to think that the code is more important than the user, and they break things left and right, and they don't apologize for it, because they feel that they are ‘fixing’ the code and doing the right thing.”

and to pre-empt any smart answers: Quote: So, there you have it. That's some of the ways Torvalds does it. And, if you think you know better, ask yourself: Have I created a world-class operating system that runs most supercomputers, stock-exchanges, and websites like Google? If your answer's no, I'd re-read his answers and take a long hard think about how you've been managing your own projects.

(In reply to Ferry Huberts from comment #34) > You guys at Mozilla should read this AND TAKE A HINT: > http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on- > Software-Development-Management/ba-p/440 And you should read THIS and take a hint: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html I'm fairly certain I've apologized several times for introducing this regression, but just in case you haven't seen it, here, I'll do it again: I'm sorry. I fixed one problem and introduced another. I knew, sort of, about the other problem, but I certainly did not realize the scope of it or how widespread the impact would be, or I wouldn't have done it. I've spent as much time as I have available to mitigate the damage. I'd spend more time on it if I could, but I can't. I'm sorry I broke the functionality you need. I'm sorry I don't have more time to spend on fixing it. Do you feel better now? Did that help in any way to get the problem fixed? Or are you merely under the mistaken impression that a bugzilla ticket is a helpful or appropriate forum for you to vent your frustration? Several of the "guys at mozilla" and several other guys including me have made it clear, repeatedly, that we agree that the current behavior is wrong and needs to be fixed, and we've been discussing how to do that. If you want to help fix it, please, by all means, chip in. Otherwise, please climb down from your your high horse and stop acting like your entitled to have other people do what YOU want, on the schedule YOU want, to fix free software to behave the way YOU want.

(In reply to Jonathan Kamens from comment #36) > (In reply to Ferry Huberts from comment #34) > > You guys at Mozilla should read this AND TAKE A HINT: > > http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on- > > Software-Development-Management/ba-p/440 > > And you should read THIS and take a hint: > https://bugzilla.mozilla.org/page.cgi?id=etiquette.html > > I'm fairly certain I've apologized several times for introducing this > regression, but just in case you haven't seen it, here, I'll do it again: > I'm sorry. I fixed one problem and introduced another. I knew, sort of, > about the other problem, but I certainly did not realize the scope of it or > how widespread the impact would be, or I wouldn't have done it. I've spent > as much time as I have available to mitigate the damage. I'd spend more time > on it if I could, but I can't. I'm sorry I broke the functionality you need. > I'm sorry I don't have more time to spend on fixing it. My comments were never meant to hurt any person, they were directed at the project. Please accept my apologies, I never meant to hurt you. Also, I seem to have missed your apologies. It's just that from the moment I filed my bug I was met with (as I experienced it) can only be called apathy and an attitude of 'It's not a real problem'. I'm still not getting the feel that the project acknowledges this as a major regression, but you obviously do. > > Do you feel better now? Did that help in any way to get the problem fixed? > Or are you merely under the mistaken impression that a bugzilla ticket is a > helpful or appropriate forum for you to vent your frustration? > I seem to not have been very constructive, true. sorry 'bout that. this was my frustration. I love TB. I hate seeing all these discussion that seem to be dabbling in all kinds of explorations on how to fix it rather than just fixing it. And telling a user that he can't have a solution until TB8, and even then the solution might not even be a true solution is a bit clumsy: - at the time of filing the bug I was on TB5 - I'm used to long release cycles. yes I know you switched to short cycles. My mind has not yet adjusted. - I can't have a 'fix' until TB8 - conclusion in my mind: oh wait, that would mean at least not until end of <insert a long time after today here>? WTF? It was al very 'not a real problem', 'will give no timeframe for real fix' and 'certainly will not backport any fixes' > Several of the "guys at mozilla" and several other guys including me have > made it clear, repeatedly, that we agree that the current behavior is wrong > and needs to be fixed, and we've been discussing how to do that. > > If you want to help fix it, please, by all means, chip in. Otherwise, please > climb down from your your high horse and stop acting like your entitled to > have other people do what YOU want, on the schedule YOU want, to fix free > software to behave the way YOU want. I'd love to chip in, but like you I have no little or no time because of day$ jobs :-( this pains me. I'll shut up and let you guys do the things you do best without being bothered. But please think about your users :-)

i can tell the feelings in here are a little tense... so im going to be constructive. =) i run a small software development company. When we introduce an unexpected bug that is larger than the one we fixed. WE REVERT. there are 5 people in this world that care that they cant detach an attachment someone sent them instead of just saving it and 10000000 that care that they cant see an attachment that someone sent them.. SOLUTION,,, tell the 5 detachers that they can wait until TB8 for a fix. after all, this "fix" really was an enhancement. and REVERT THE REST. i know you have the base in a cvs.. i have every project no matter how small in one... REVERT REVERT REVERT. stop "discussing" while people's clients are broken AND REVERT. get the masses to cool down... step back from the problem, reassess while you arent under pressure and develop your long term solution.. (using your existing code that you introduced this problem with) release it to a beta cycle before pushing it into production. for the love of user experience.. i reverted from TB6 to TB3 and i am missing NOTHING i use. unfortunately none of the 50+ clients i have still in the field running TB6 have the functionality they need to get through a days work... i might be wrong,, but i think that is the reason people are on here being non-constructive. they are **** because you (though unintentional) cause them A LOT of work. the solution is simply to revert. it has been said before. it will be said again. are any of you guys taking this suggestion seriously? if this happened in my company.. i would have jokingly wrote -2 on your eval for breaking stuff... laughed about it , then pushed an update with the functionality removed before the end of the day.

1. It is not productive to make unsupported guesses about how many people are affected by one piece of missing functionality vs. the other. I'm sure your "5 vs. 10000000" was a joke. I am also sure that you are right that more people care about viewing attachments than deleting them. However, there are a substantial # of people who care about the latter, and pretending that they're irrelevant or don't exist or serious thought has to be given before screwing them over is not helpful. 2. Other changes have been introduced into the code base since the changes which caused this problem. Reverting at this point is neither as easy nor as risk-free as you seem to think it is. 3. Backporting a revert would require more substantial changes than the "Show All Body Parts" functionality I implemented to work around this issue. If something is going to be backported, then it might as well be that workaround. And while we're at it, if the problem is really this severe, we might as well reconsider the (in my opinion inexplicable) choices to hide that workaround and refuse to document it in the KnowledgeBase. 4. Instead of being yet another person who hasn't contributing anything to the code base but thinks they have the right to tell the people who do how to do things, perhaps you could download the source code and contribute a patch. No, I do not mean to say or imply that feedback of the sort you provided is never useful. In this case, however, surely you realize that everyone involved is fully aware of the option of reverting the new changes, and therefore surely you realize that although your tone is more polite than the previous commenter, your comments are no more helpful than his.

(In reply to DennisCG from comment #38) DennisCG's comment. Yes, probably not productive to make unsupported guesses about how many people are affected (10 million? Or rather more?). But probably also not productive to assume that only very few are affected, or, to assume that -- even if -- only few are affected, the bug is of minor importance. I have been watching this bug draw about as much attention as a dead fly, for many months, now. This, in my opinion, is what is heating up the discussion here, so much. I'm making another unsupported guess now: many people are just not willing to spend a lot of energy into this, and revert. But not to an older MT version. They revert to another email client. I certainly do know of the difficulties involved with reverting to previous release states. Rest assured about that. But no matter how many people are involved, or are not involved, please read my previous comment. It is the utmost seriousness which makes this bug an absolutely outstanding one. Maybe only those users count, which are using MT for recreational purposes. Of course, these can easily smile about attachments not being displayed. Hey, after all, we have time and can copy and paste our attachments into twitter, right? And if we cannot see them at all, hey, most likely they haven't been important anyway, they were just some useless cellphone pics, right? ... And probably (another unsupported guess), such users make up the majority of MT users. Unfortunately, my bosses aren't part of this majority, and have meanwhile decided to pay a little and invest into commercial software instead. It's hard to convince even smart people to wait patiently, when even after many months not the slightest progress is visible. 3500 less MT users. No unsupported guess, supported reality instead. Sigh. But then again, who cares, 3500 is just a little fraction of (unsupportedly guessed) 10 million. And there are 10 million (unsupportedly guessed) minus 3500 (real) others, which can spread the word 'MT is a great email client', so we probably won't need the 3500. Thank you, Mr. Kamens, for your work. It has been a nice time, and I have always appreciated the efforts you and your colleagues have spent into making MT run. I'm sure you will eventually save this ship from sinking, and I'm grateful about that. All the best Ernst P.S. After an hour of thinking... I'm sorry about submitting a pretty destructive comment. I know I would hate somebody sending in a comment like this one myself, and I would definitely flame back. But my sole and only intention is to waken people up, and draw attention to the extreme severity of this bug. Therefore, I'm submitting this reply anyway. Please forgive me for that.

(In reply to Ernst Maier from comment #40) > But > probably also not productive to assume that only very few are affected, or, > to assume that -- even if -- only few are affected, the bug is of minor > importance. No one is making that assumption. > I have been watching this bug draw about as much attention as a > dead fly, for many months, now. This topic has actually been discussed in several different bugs. They have actually been getting a great deal of activity. And one of the folks at mozilla.org even started a discussion thread in one of the newsgroups about how to solve the problem represented by this bug. In short, if you think this issue is getting "as much attention as a dead fly," then you are not paying good enough attention. I, for one, just spent *another* hour poring over the source code trying to figure out yet again if there is a way to fix this issue that doesn't involve drastic, complex changes to the guts of Thunderbird's MIME parser. I once again could not find one. The fact that the bug has not been fixed does not imply that there is no interest in fixing it or that there is no understanding of the severity of the bug. It implies, rather, that it is Really, Really Hard to fix properly. Simply put, the entire architecture of Thunderbird's MIME parser is working against you if you try to fix it. Within the current architecture, you have to choose: you can either parse MIME properly, or you can display attachments in multipart/related. You can't do both. And if you don't parse MIME properly, then you can't delete attachments from multipart/related messages. > Maybe only those users count, which are using MT for recreational purposes. > Of course, these can easily smile about attachments not being displayed. > Hey, after all, we have time and can copy and paste our attachments into > twitter, right? And if we cannot see them at all, hey, most likely they > haven't been important anyway, they were just some useless cellphone pics, > right? ... And probably (another unsupported guess), such users make up the > majority of MT users. No one who works on Thunderbird is thinking this way. Please don't put insulting, patronizing thoughts into people's heads. > Unfortunately, my bosses aren't part of this majority, and have meanwhile > decided to pay a little and invest into commercial software instead. It's > hard to convince even smart people to wait patiently, when even after many > months not the slightest progress is visible. Or they could simply have people use Thunderbird 3 until the issue is fixed, no? Yes, that's sucky. No, I don't like it. But all the wailing about this bug seems to ignore the very simple fact that if you install Thunderbird 3 and then turn off automatic updates, you can be happy and content with Thunderbird until we lazy, good-for-nothing volunteers get around to fixing your favorite bug.

(In reply to Jonathan Kamens from comment #41) > I, for one, just spent *another* hour poring over the source code trying to > figure out yet again if there is a way to fix this issue that doesn't > involve drastic, complex changes to the guts of Thunderbird's MIME parser. I > once again could not find one. > > The fact that the bug has not been fixed does not imply that there is no > interest in fixing it or that there is no understanding of the severity of > the bug. It implies, rather, that it is Really, Really Hard to fix properly. > Simply put, the entire architecture of Thunderbird's MIME parser is working > against you if you try to fix it. > Then, after all that effort, there is but a single sad conclusion left: the mime parser does not reflect reality and needs to be replaced. > > Unfortunately, my bosses aren't part of this majority, and have meanwhile > > decided to pay a little and invest into commercial software instead. It's > > hard to convince even smart people to wait patiently, when even after many > > months not the slightest progress is visible. > > Or they could simply have people use Thunderbird 3 until the issue is fixed, > no? That answer is way too easy. The earliest fix would be TB8, which is -at least- half a year out. > > Yes, that's sucky. No, I don't like it. But all the wailing about this bug > seems to ignore the very simple fact that if you install Thunderbird 3 and > then turn off automatic updates, you can be happy and content with > Thunderbird until we lazy, good-for-nothing volunteers get around to fixing > your favorite bug. Then let's ask something different: why aren't _paid_ developers from Mozilla working on this every hour they have? Why are volunteers trying to fix this? (I am only suggesting that these paid developers can work more hours on fixing this)

(In reply to Ferry Huberts from comment #42) > > Or they could simply have people use Thunderbird 3 until the issue is fixed, > > no? > > That answer is way too easy. The earliest fix would be TB8, which is -at > least- half a year out. I don't understand what you mean. First of all, there are still people using Windows XP and Outlook 2003, and Thunderbird 3 is perfectly functional and usable, so I really don't see why anyone couldn't continue to use it for the next six months or even the next year. As a data point, 21% of the active users of my "Send Later 3" add-on are still on TB 3. Second, TB 8 is scheduled to go beta TODAY, which means that according to the new rapid release schedule it should go to production six weeks from now, not "-at least- half a year out." > Then let's ask something different: why aren't _paid_ developers from > Mozilla working on this every hour they have? Why are volunteers trying to > fix this? Presumably because they are working on other things that affect more people more than this bug. It is rather myopic to assume that just because this bug is very important to you, or indeed even very important to a lot of people, there's nothing more important that needs to be done. Like any other software development project, the amount of resources, paid and volunteer, available to work on TB is limited, and work has to be prioritized. Since you presumably do not have visibility into everything that needs to be done, you are in no position to judge whether this is high enough priority that people should be working on it. By way of comparison, this ticket has 6 votes; there are 523 open Thunderbird or MailNews Core bugs in bugzilla with more than 6 votes. I can't find a way to query the # of CC's on multiple bugs in the database, but if I did I suspect I'd find similar results. (And, by the way, people *are* working on it, just not as quickly as some here would like.)

(In reply to Ferry Huberts from comment #42) > Then, after all that effort, there is but a single sad conclusion left: the > mime parser does not reflect reality and needs to be replaced. So you're willing to rewrite a 10,000 line module to reflect modern coding standards, including aggressive testing to make sure we don't regress functionality? A module that relies on a dozen or so at times poorly-written RFCs that needs to take into account the sheer mass of code which fails to actually conform to these (I'm honestly surprised some of the crap I've seen actually made it through all the MTAs)? Great, when can we expect your patch? In all seriousness, I have investigated ways to improve the MIME architecture. From someone who's actually worked on the code before, I would say that a complete replacement would take months if not years. > Then let's ask something different: why aren't _paid_ developers from > Mozilla working on this every hour they have? Why are volunteers trying to > fix this? > (I am only suggesting that these paid developers can work more hours on > fixing this) Because this, believe it or not, isn't the most pressing bug in our database. If you're going to suggest that the votes is a strong measure of importance of bugs, I have a list of 53 bugs which have more than 50 votes. In addition, it would require a lot of work to muck around in the MIME cpde, most of our developers (paid or otherwise) are not well-versed in said code, the risk of regressing other things is rather high, and the utility is rather narrow: a fix does not improve things for most people. As Jonathan said, people are working on it; complaining bitterly about it in comments is only going to slow it down and dissuade others from working on it.

(In reply to Jonathan Kamens from comment #43) > By way of comparison, this ticket has 6 votes; there are 523 open > Thunderbird or MailNews Core bugs in bugzilla with more than 6 votes. I > can't find a way to query the # of CC's on multiple bugs in the database, > but if I did I suspect I'd find similar results. Sorry if I presented this wrongly. What I meant with this bug not getting more attention than a dead fly is exactly this "voting" system. It still has only 6 votes. On another thread I had already voted for this bug (amongst a few other people), but that other thread has been defined as a duplicate of this bug. Unfortunately, by this "duplicate elimination process", not only the posts from the original thread are "being lost", but also the votes are being lost. It seems to me that quite many threads were united into this one, and quite many of these threads have "eaten up" other duplicates, themselves, and so on. So originally, there must have been really many duplicates of this one. Therefore, have a look at the real number of duplicates which have been closed already, and then have a look at how many votes were lost this way. I haven't counted them, but I would assume you would actually find a pretty high, _true_ priority for this bug. Kind regards Ernst P.S. When this, and other minor bugs, have successfully been fixed one day, it might be a nice idea to go over the duplicate removal system and make sure that a), old posts are transferred and b), the corresponding votes are transferred.

a proper response would be short... for example "we are fervently working on this bug and hope to have a patch for it soon."

...and now would be a good time to stop this discussion and give the few people who actually grasp the code a chance to concentrate on it and to eventually come up with a fix. Thanks!

I have this problem as well on TB 7.0.1. I have attached a test case e-mail with inline images as well as an attachment. TB 7.0.1 shows neither the inline images nor the attachment, whereas both Outlook and Gmail show everything.

i've gone back to using the USPS myself. i can send a printed pdf documents certified mail, and i know the other person receives it. they still have the detachment problem though. if they dont want it any more, they just have to throw it in the trash the old fashion way.

Comment on attachment 566869 [details] Test case with inline images and attachment marking obsolete as "Content-Type: images/gif" is not a valid MIME type.

Replacement of test case attached to comment #50(images/gif => image/gif)

Having just reported this as a duplicate, but where the mail was sent in this structure from another email client (PHPMailer) not Outlook, just to add my voice to the pragmatic responders. If everyone but Thunderbird reads messages sent by the most popular email client in the world as intended, then that is clearly a bug in Thunderbird whatever the spec says. Not fixing this is a very good reason for people to stop using Thunderbird. People aren't going to thank you for insisting on sticking to the letter of the spec.

As a matter of interest, and to help report and maybe even fix the original problem in phpmailer, what is the correct structure? is it as follows?... multipart/mixed multipart/related multipart/alternative HTML part text part end alternative inline image(s) for HTML content end related attachment(s) end mixed

The image(s) relate(s) to the HTML part only, thus correctly it would have to be: multipart/mixed multipart/alternative multipart/related HTML part inline image(s) for HTML content end related text part end alternative attachment(s) end mixed

FWIW, unlike v5.1, PhpMailer v5.2 now generates the structure rsx11m said, and Thunderbird does indeed display it correctly.

the library i was using (jboss seam 2) is now patched as well as of 2.2 final. HOWEVER, that does nothing for reading the 20+ gigs of archived messages i have to maintain for record purposes. I'm still watching this bug, but as of now i will continue to run personally on TB3 and my clients have all been switched or advised to switch back to a microsoft product. you guys left me no choice.

indeed, PhpMailer v5.2 creates the correct email-structure as David Earl said (comment 59). My Th 8.0 under Win764bit shows then html-part correct (View/Message Body As/HTML) but shows an plain-text the html-part (View/Message Body As Plain Text). Is there a mistake by msyself? Here ist my testmail attachment 575690 [details] View/Message Body As/Orignal(or Simple) HTML and/or Plain Tex

Since version 8.0, I cannot see my voice mail attachments in messages auto-generated by the PBX (Avaya S8400). These are empty messages with a voice.wav attachment and the following headers: Mime-Version: 1.0 (MessageCore Multimedia Messaging) Content-type: audio/wav; name=voice.wav; codec=7 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="voice.wav" Content-Description: Voice Message (2 secs) I have to click Forward to see the attachment in the new mail to be composed. I have tried using the "Show All Body Parts" Add-on, but I don't see any option "Message Body As" --> "All body parts", as I expected. Why attachments vanished? How can they be re-displayed? The problem with audio/wav attachments was also refered to in Bug 683995, which was labeled as duplicate of this.

"Show All Body Parts" 1.1 is broken. Please try version 1.2. You can get it from https://addons.mozilla.org/firefox/addon/show-all-body-parts/versions/1.2 . Sorry for the trouble.

I'm scratching my head a bit. If all you need is the "Show All Parts" function, toggling mailnews.display.show_all_body_parts_menu to "true" in the Config Editor should be all you need to do (I know that the add-on has further functions).

(In reply to rsx11m from comment #66) > I'm scratching my head a bit. If all you need is the "Show All Parts" > function, toggling mailnews.display.show_all_body_parts_menu to "true" in > the Config Editor should be all you need to do (I know that the add-on has > further functions). Yes, originally all the add-on did was to set that pref to true when you installed it and set it back to false when you uninstalled it. But the AMO editors refused to approve it in that form, because they said that AMO policy is that add-ons that change preferences have to restore them to their "previous value" when they are uninstalled. This struck me as rather silly. Since there is no UI element to access this preference, and since editing preferences via about:config is unsupported, there's no supported way for someone to edit this preference, so I shouldn't have to worry about someone modifying it. Furthermore, if someone has gone to the trouble to install an add-on whose sole purpose is to change a pref setting, there's no reason why they would muck with the value of that setting outside the add-on. Nevertheless, to get the add-on approved, I had to add functionality do "restore the previous value" on uninstall, which meant adding observers to find out if the user changes the preference while the add-on installed. One of those observers was being added and removed in slightly the wrong order, which is how version 1.1 of the add-on ended up being broken. I would just have soon kept the add-on simple and not put in that functionality at all, but I had to put it in to get the add-on approved by the AMO editors.

"Show All Body Parts" 1.2 works fine. It is a very good solution for cases where TB does not "detect" and display attachments properly. However, one expects from TB to "detect" and display attachments properly in all cases. In all types of views, TB should have a way of appropriately (depending on the view) displaying ALL included pieces (body parts): either inline or as attachments. The user, in all types of views, should have access to all parts of a message; (s)he should not be obliged to try to figure out what view to use in order to access all parts of the message nor to concede to use a message view which (s)he would not otherwise select, just to make sure that some pieces of the message don't get by unnoticed (or to avoid changing views all the time to be able to view those messages whose attachments are not visible in other views). I am sure that the TB development team will do their best, as always, and keep TB at the technological edge.

Two recent observations that might be interesting: 1) When I create a message with Apple mail on OSX Lion and attach a PDF or a png image (which Apple mail both shows in the message body directly), then save the message as draft and open the draft in Thunderbird 8.0, thunderbird does not show the attachment. Neither in the message body nor in the attachment area. And this happens no matter whether I choose "show attachments inline" or not. --> There is still something broken. (Granted, silently ignoring data is not the same as data loss, but I bet it has equal effects for the user.) 2) In the webmailer of hosteurope.de, I ran across a configuration item controlling how attachments are created. One can choose between the following three options: a) "fully RFC2231 compatible (thunderbird)" b) "RFC2047/2231 compatible (MS Outlook)" c) "fully RFC2047 compatible (others)" From a user's point of view, this is just ridiculous and not acceptable. How can we expect people to change such a setting each time before writing a message, depending on the software they believe the recipient will be using? Technically speaking: Please do everything to make such workarounds become obsolete. This is my Xmas wish to the Thunderbird geniuses, whose great work I really appreciate :-)

Just my 2 cents: Outlooks *does* clearly violate RFCs here. <http://tools.ietf.org/html/rfc2387> "this document describes a single mechanism for such aggregate or compound objects." "For a Multipart/Related object, proper display *cannot* be achieved by *individually displaying* the constituent body parts." (emphasis by me) That is not to say we shouldn't fix it. While we're at it, we should also display a mail body (!) of type PDF (i.e. no MIME multipart, just PDF instead of the body) as an attachment. That, too, is serious nonsense, but does happen.

(In reply to Ben Bucksch (:BenB) from comment #72) > While we're at it, we should also display a mail body (!) of type PDF (i.e. no MIME > multipart, just PDF instead of the body) as an attachment. We do this as of 9.0. See bug 701261.

... and another one (geeze)

Ok guys, the proper fix was promised to version, let me remember, 7? Now we have 9.0.1, and the bug still persists... I'm getting bored to try and downgrade to 3.1 every single version...What could we expect?

(In reply to Déri Barna from comment #77) > Ok guys, the proper fix was promised to version, let me remember, 7? Now we > have 9.0.1, and the bug still persists... I'm getting bored to try and > downgrade to 3.1 every single version...What could we expect? There is a workaround either setting it from the config or using this addon which does the same: https://addons.mozilla.org/firefox/addon/show-all-body-parts/versions/1.2

anyone here say that wanted a workaround? scrolling back..humm.... nope. looks like everyone wants a FIX. im personally not **** around in the configs or downloading some mess just to view a message every other client in the world will display without problems. I'm running 3.1 myself.. and i will not move forward until this is fix. put out as many versions as you want.. but until you start putting the User's Experience before adhering to some spec, all you've accomplished is 3 different versions of mental masturbation.

(In reply to DennisCG from comment #79) > anyone here say that wanted a workaround? scrolling back..humm.... nope. > looks like everyone wants a FIX. im personally not **** around in the > configs or downloading some mess just to view a message every other client > in the world will display without problems. I'm running 3.1 myself.. and i > will not move forward until this is fix. put out as many versions as you > want.. but until you start putting the User's Experience before adhering to > some spec, all you've accomplished is 3 different versions of mental > masturbation. I do not see how ranting about it will change anything. This is a free software and it's done by people's time. It's not perfect, nor the development speed or features chosen by you. But free software is first free, and this one is open, so you can contribute to it. You can get your hads dirty and fix it, or help others fix it. Also you can find how this comunity works and how the bugfix system prioretizes bugs and find a way to speed things up. I do see the obvious problem of a serious issue not taken up to the speed it deserves, but that doesn't mean you can **** on people's work as you haven't done anything to make Thunderbird what it is now. TL;DR Stick to technical only and be patient or fix it yourself.

(In reply to Jonathan Kamens from comment #41) > It implies, rather, that it is Really, Really Hard to fix properly. > Simply put, the entire architecture of Thunderbird's MIME parser is working > against you if you try to fix it. > Within the current architecture, you have to choose: you can either parse > MIME properly, or you can display attachments in multipart/related. > You can't do both. > And if you don't parse MIME properly, then you can't delete attachments from multipart/related messages. Jonathan, how about next? Is it possible? In message display, parse mime correctly, as current View/Message Body As/Original HTML does. In attachment pane display, ignore correct mime parsing, and apply multipart/mixed to mail body of non multipart mail or any multipart/xxx, as current View/Message Body As/All Body Part does do. Biggest issue in All Body Parts mode is message display of correct multipart/related part when the correct multipart/related consists of correct html + many correct embed images pointed by correct cid: url. To resolve this issue in All Body Parts mode, this kind of feature/enhancement is needed. If such enhancement is possible, enhanced All Body Parts mode can be used as a sord for Tb users to regist to frequent malformed multipart/related mails generated by MS(the creator of RFC for multipart/related!) and mail applications which never respect mail RFC, unless embed correct images in multipart/related is too many. Needless to say, other enhancement like "ad-hoc View/Message Body As choice for a mail" is still needed too for daily use of enhanced All Body Parts mode. It may require mechanism like next; At hidden message window-1, do Message Body As/Original HTML, At hidden message window-2, do Message Body As/All Body Parts, At message pane/header pane/attachment pane, relate him to appropriate part of hidden windows, and show content from appropriate hidden window, and pass requested action(save message, attach/detach etc.) to appropriate hidden window.

Just to add some thoughts to WADA's observations above: There are other tools available rather than digging into the fragile Mime code. Jonathan's post here describes a JS API that might be useful: http://groups.google.com/group/tb-planning/tree/browse_frm/thread/2a4f93d0eb1e048f/d5d07799eeff3bea?rnum=1&_done=%2Fgroup%2Ftb-planning%2Fbrowse_frm%2Fthread%2F2a4f93d0eb1e048f%3F#doc_d5d07799eeff3bea I believe this might allow one to scan a multipart message and determine how many parts were actually there. Ideally we would then need to know how many parts were actually displayed either inline or in the attachment box. I think that could be done by adding some hooks into the Mime parser without much logic flow disruption. Now, if there is a difference in the counts, we then display a button in the attachment pane that when clicked, activates the "view all body parts pref" Just offering this up as a theoretical solution. I can't code it, just "food for thought" The biggest problem with the missing attachment problem, IMO, is that intended content can be hidden from the recipient, and he would never know that it is there in some cases.

(In reply to Yavor Stefanov from comment #80) >> > I do not see how ranting about it will change anything. This is a free > software and it's done by people's time. It's not perfect, nor the > development speed or features chosen by you. > But free software is first free, and this one is open, so you can contribute > to it. You can get your hads dirty and fix it, or help others fix it. > Also you can find how this comunity works and how the bugfix system > prioretizes bugs and find a way to speed things up. > > I do see the obvious problem of a serious issue not taken up to the speed it > deserves, but that doesn't mean you can **** on people's work as you haven't > done anything to make Thunderbird what it is now. > > TL;DR Stick to technical only and be patient or fix it yourself. oh that's where you are very wrong sir... reference the earlier threads. my contribution was knowing when to revert the changes that the one guy made when trying to patch an insignificant bug in version 5 moving to version 6. the guys that are doing such a great job that we feel the need to rant about them did not listen to me. i deal with these issues all the time too. but i never sacrifice user experience fixing a minor bug and let it create a major functionality flaw. my contribution was rejected. but if it was excepted, none of us would be here right now ranting because we cant see what's in our emails would we? everyone says "i dont see how ranting will help." probably repeated 5 times in this thread alone. here is the thing, the powers that be are so focused on what they are doing that they are ignoring major functionality problems. they are illogical. fact not fiction. when someone has a good idea, they dont take it because that would undo some of their precious work. its nothing but pride my friend. these guys wont even admit this is a major problem that effect the mass majority of their client base. its not that i cant or i wont. it is they dont want my help. because the first thing i would do is take this project back to a client that can display EVERY EMAIL by reverting changes until version 5 (when it actually worked). then figure out another way to get that stupid detach logic working if we just had to have it. reverting would have been easy before they released 3 more version on top of this heap. i dont play this quick release game if im breaking stuff. my clients get results with every revision. i dont put out code that half works. this behaviour is unacceptable in the real world and it is the reason the client base for this project is shrinking at an alarming rate. i will keep ranting until someone actually listens or we at least stop getting duplicates of this bug. modding config files or downloading some add-on IS NOT A SOLUTION... ITS A HACK. TRY AGAIN.

(Just to add some thoughts to my comment #81 on All Body Parts mode and above comment #82 by Joe Sabash on enhanced JS API, with skipping comment #83) Enhancement of "cid: url resolution in multipart/mixed too" may be a solution of multipart/related(html+embed images) display issue in All Body Parts mode. "cid: url resolution in multipart/mixed too" is needed to resolve issue like bug 488987 (html+cid:url+embed images is sent as multipart/mixed instead of multipart/related. for different kind of malformed mail from this bug). If this enhancement will be developed, All Body Parts mode + "cid:url resolution in multipart/mixed" mode can be used as a daily-use sord to fight against frequent malformed multipart/related mail. Problem in this case is; if very many images is embed in multipart/related, attachment pane will be filled by the many images, so it's difficult to find incorrectly placed PDF file in multipart/related.

Thumbs up to DennisCG. The more and more "improved" versions are released, the more and more difficult it will be to fix really SERIOUS bugs. I myself am not using TB any more, and neither does anybody in my hosted network of more than 1000 clients. Maybe (maybe! definitely not for sure!) some day I will again, but certainly not before this 'little, unimportant bug' is fixed. Even if TB could fly, cook my breakfast coffee, give me great sex and wash my clothes, I would still NOT go to even spend a single thought about using it again, until this BUG (BUG!!!) (BUG!!!!!!!) is fixed, for keeps. Nor will the more than 1000+ users in my network. Thank you very much for spending a lot of time into developing a free and 'useful' software. I really very much appreciate this. But by all means: Do not spend too much work into it, as long as nobody wants it, because not even the most basic (but HIGH IMPACT) bugs are being thought about, let alone being fixed. I do not like bad language, I have full understanding for people 'wasting' their spare time for a prestige project... but I loose understanding if the prestige project develops into a 'who cares' project. Who cares if there is garbage, litter, rubbish, trash and waste all about, as long as we can improve the looks of the garbage can every day? Hey, it really looks great, now!!! I'm waiting for garbage can version 10.0! Kind regards Ernst

At the risk of making people think that ranting in Bugzilla is useful (it's not), I'm assigning this to myself. I would appreciate it if people didn't post further rants (or thanks, or anything nontechnical) to this bug, since it's just going to spam me, which will probably result in me unassigning myself to prevent my inbox from overflowing. I'm not going to work on this anytime this month as I have other commitments, but I will attempt to make it a priority in February or March.

(Just to add some thoughts to my comment #84 relevant to All Body Parts, with skipping comment #85) "Tolerance of Tb with malformed multipart/related" is similar to "torelance of Tb with wrong charset in Content-Type:"(this is also a kind of malformed mail). "torelance of Tb with wrong charset in Content-Type:" was implemented like next. > Folder Properties/General Information, > Default character encoding : charset user wants > [ x ] Apply default to all messages in the folder (individual message > character encoding setting and auto-detection will be ignored) If enhanced All Body Parts mode will be implemented, following can be a feature for "tolerance of Tb with malformed multipart/related". > Folder Properties/General Information, > [ x ] Show all messages in the folder with enhanced All Body Parts mode. Because malformed multipart/related mail is sent from specific mail system and is usually not sent from general/sophysticated mailer which is used by peoples, I think moving mails from such mail system by message filter is usually sufficient for majority of users who frequently receive malformed multipart/related mail. For user's convenience, "ad-hoc View/Message Body As of a mail" is better implemented at same time, if this kind of "torelance with malformed mail" will be implemented, as "View/Character Encoding" menu is available for "torelance with wrong charset in Content-Type:". Jim Porter, do you think "Show non-displayable/non-referred part in any multipart mail as if attachment always"(one of best solutions of this bug for victims of malformed multipart/related mail) is easier/simpler than enhancement like above? Please note that bug 705431 which needs to be fixed if such solution will be implemented, is still not resolved(looks to exist since 2003), and All Body Parts mode, which bases on sorted out/improved mime relevant code, is already available as an effective workaround of such bug. And, unless many embed images are used in html mail, All Body Parts mode is practically effective in malformed multipart/related case, although some additional enhancements will be needed to use it in solution of this bug.

(In reply to WADA from comment #87) > Jim Porter, do you think "Show non-displayable/non-referred part in any > multipart mail as if attachment always"(one of best solutions of this bug > for victims of malformed multipart/related mail) is easier/simpler than > enhancement like above? Based on my understanding of how libmime works, I don't think we'll need to enhance the "Show All Body Parts" code to fix this. It should be possible to fix by changing some combination of the following parts: 1) the multipart/related handler, 2) the leaf-type handlers, 3) the attachment emitter. > Please note that bug 705431 which needs to be fixed if such solution will be > implemented, is still not resolved(looks to exist since 2003), and All Body > Parts mode, which bases on sorted out/improved mime relevant code, is > already available as an effective workaround of such bug. Bug 705431 is probably lower priority, but yeah, we should fix that too.

(In reply to Jim Porter (:squib) from comment #88) > Based on my understanding of how libmime works, I don't think we'll need to > enhance the "Show All Body Parts" code to fix this. It should be possible to > fix by changing some combination of the following parts: 1) the > multipart/related handler, 2) the leaf-type handlers, 3) the attachment > emitter. Thanks for your answer. I believe "display non-diplayable/non-referred part in multipart/related as if attachment" will be taken as solution of this bug. Questions on detach/delete after it. (a) Same question as bug 351224. Is the non-displayable/non-referred part in multipart/related, which is shown as attachment at attachment pane, detachable/deletable? (b) Non-displayable message body like Content-Type: audio/wav is also shown as if attachment to provide user a way to save the audio/wav data to a file. Is this *attachment* of audio/wav detachable/deletable? (c) If some of *attachment* shown at attachment pane are not detachable/deletable, how can user know it? How can we avoid repeated open of bug report by general users like bug 351224 at B.M.O?

Jim came up with this fix, and I added the size check part. This essentially makes us output mimemalt parts if they have names, which should be rare, much more rare than the issues we have w/o this patch, and less serious, in that instead of not seeing an attachment that you should be able to see, you'll see an attachment that you don't need to see. One drawback is that if you do have a mimemalt part with a name, and you detach/delete it, you do break your message.

I don't think we should treat size == 0 as "no size", since it *is* a valid (but not particularly useful) size. We should instead be able to set the size to -1 in multipart/related contexts*. It also should be straightforward to set dontShowAsAttachment for multipart/alternative subparts. This still isn't perfect, since attachment sizes would be hidden for multipart/related attachments, but we could try to improve upon that at a later date. * I think the way to do it would be to set sizeSoFar to -1 here: <http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimeleaf.cpp#120>, and then the first time we're about to add to sizeSoFar, make sure to set it to 0 first.

(In reply to Jim Porter (:squib) from comment #91) > * I think the way to do it would be to set sizeSoFar to -1 here: > <http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimeleaf. > cpp#120>, and then the first time we're about to add to sizeSoFar, make sure > to set it to 0 first. yeah, I thought of that - it's pretty hacky, but I guess I don't have a choice given the way sizes are calculated.

I didn't quite get the dontShowAsAttachment comment, but this seems to get the size handling right for my test cases (unknown for the mimemalt part message in this bug). I'm not sure we want to set the size to -1 for mimemalt parts that we shouldn't be showing (e.g., when I hack up a mimemalt part to have a filename).

dontShowAsAttachment is a member of MimeObject, and when it's true, GenerateAttachmentData will refuse to add an nsMsgAttachmentData for the object so that it ultimately won't get sent through the MIME emitter. I believe this member gets used in the multipart/related code for hiding subparts (images) that are referenced in the main part (HTML): http://mxr.mozilla.org/comm-central/ident?i=dontShowAsAttachment

Actually, now that I think about it, let's *not* do that. The patch as-is will let .ics "attachments" (really multipart/alternative subparts) show up, since they seem to typically have names; see bug 505024 for an example. Detaching/deleting .ics subparts seems to work fine, so really we'd just need some logic for disallowing detaching/deleting named multipart/alternative subparts that we might choose to render as the body. That's probably rare enough that we can ignore it for now. (Famous last words.)

(In reply to Jim Porter (:squib) from comment #95) > Detaching/deleting .ics subparts seems to work fine, so really we'd just > need some logic for disallowing detaching/deleting named > multipart/alternative subparts that we might choose to render as the body. > That's probably rare enough that we can ignore it for now. (Famous last > words.) Yeah, I agree that it should be rare, and that disallowing the detach in that case is probably the way forward. I propose that we try this patch on the trunk and see if it causes any issues. We could logroll the review, where I review your part and you review my part :-)

Comment on attachment 591337 [details] [diff] [review] fix size count This doesn't actually work for me. parse_begin isn't hit for multipart/related subparts, since output_p is false here: <http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimemult.cpp#518>.

Here's my patch, which I've manually verified works for eliminating the size on multipart/related children. One note: this patch will show named multipart/alternative subparts as attachments (but we already knew that). However, at least for .ics attachments like this, they can't actually be opened, since Thunderbird thinks they have 0 size. I'm guessing this is because we see that the part is an un-displayable multipart/alternative child and so we bail out early. I don't think we could ever open these parts, so we can probably fix this in a followup. One more note: tests would be (very) nice, but I don't have time myself to write them, since the cloud files bug is a higher priority.

Comment on attachment 593326 [details] [diff] [review] Move sizeSoFar initialization earlier I was able to open the unknown size attachment in my test case. Do you have a test case that fails? Will failure to open ics files confuse Lightning? In any case, my test case works with your patch. I would like to see the test case that failed for you with my patch, though, so we can use them both for test cases.

I believe the examples in bug 505024 show off the issue with ICS files as multipart/alternative subparts.

squib, ping for landing...

Checked in: http://hg.mozilla.org/comm-central/rev/2498458f04ca I'm hesitant to land this on 11 or 12, at least not without letting it bake on trunk for a while, since the fix is a bit magical. What does everyone else think? (I will say that we should definitely fix this in ESR 10 when we're confident that this doesn't break anything.)

(In reply to Jim Porter (:squib) from comment #103) > Checked in: http://hg.mozilla.org/comm-central/rev/2498458f04ca > > I'm hesitant to land this on 11 or 12, at least not without letting it bake > on trunk for a while, since the fix is a bit magical. What does everyone > else think? Yes, bake on trunk (and, I would suggest, alpha, for a bit more testing) for a bit, and yes, we will want this for the ESR if it looks good.

Seems to work fine with the testcase in bug 674704 Mozilla/5.0 (Windows NT 5.1; rv:13.0a1) Gecko/20120215 Thunderbird/13.0a1 I guess we should hold off on the verify until some of the other conditions are tested.

bonjour/hello Peut on espérer une correction de cette régression concernant ces pièces jointes invisibles ? si oui dans quel version ? Cela ne fonctionne pas dans Thunderbird 10.02 ET toujours des demandes sur le forum de Geckozone http://www.geckozone.org/forum/viewtopic.php?f=4&t=102850&p=677612#p677612 Merci J2m06 -------------traduction ggogle------------ Can we expect a correction of this regression on these attachments invisible? if so what version? This does not work in Thunderbird 10.02 And always demands the MediaMonkey forum thank you

sorry And always demands the Geckozone forum

To expand on comment #103 and comment #104, the fix for this is currently active in the nightly development (trunk) builds. Thus, if no further action was taken, this would appear with Thunderbird 13.0. However, as stated, if this successfully works in the trunk builds, it will be made available for Thunderbird 11.0 already along with the respective Thunderbird 10.0 Extended Support Release. Thunderbird 11.0 is scheduled for March 13; another regular 10.0.x release would only happen in case of more security issues showing up that warrant a such an intermediate release, where other bugs like this may or may not be included.

Comment on attachment 593326 [details] [diff] [review] Move sizeSoFar initialization earlier [Approval Request Comment] User impact if declined: users will not see attachments in some e-mails Risk to taking this patch (and alternatives if risky): users might see "extra" attachments, though I think that risk is low, since we only show attachments with names.

> we only show attachments with names. Or content-disposition: attachment since #705431

(In reply to Jonathan Protzenko [:protz] from comment #110) > > we only show attachments with names. > > Or content-disposition: attachment since #705431 right, thanks. Oh, I see that's going to be in aurora and beta, so this will have to work with that - I think it should still be OK.

Yes I think it's ok too, since that bug makes us display more attachments, not less :)

Désolé je n'avais pas bien compris :-( ----------------- Sorry I did not understand :-(

This has been nominated for aurora (TB 12.0) and beta (TB 11.0). I'd think that the patch would also be a good candidate for the 10.0 ESR branch, possibly along with the fix in bug 705431, given that these are issues that may be frequently seen in enterprise environments as well.

Comment on attachment 593326 [details] [diff] [review] Move sizeSoFar initialization earlier Yes, I think we should get this into the tree and betas for some testing so it can hopefully go out in TB 11.

Checked into branches for 11 & 12: http://hg.mozilla.org/releases/comm-aurora/rev/c27ce7eb1b03 http://hg.mozilla.org/releases/comm-beta/rev/5579d69dcd4b

I know the timing in the regression range isn't quite right, but I am worried that this change may be at least partially to blame for bug 732585. Can someone check if this bug is present in aurora or beta before we ship them?

(Sorry, I meant check if *that* bug, i.e., bug 732585, is present in aurora or beta.)

(In reply to Jonathan Kamens from comment #117) > I know the timing in the regression range isn't quite right, but I am > worried that this change may be at least partially to blame for bug 732585. > Can someone check if this bug is present in aurora or beta before we ship > them? That issue is also present in Firefox, so I doubt it has anything to do with this bug.

Landed for esr 10.0.3: http://hg.mozilla.org/releases/comm-esr10/rev/e9aace9e645b

(In reply to Jonathan Kamens from comment #118) > (Sorry, I meant check if *that* bug, i.e., bug 732585, is present in aurora > or beta.) Just to confirm, not reproducible in aurora builds (and it would be a surprise if it did, the other bug is a composition bug, this one is on reading MIME messages).

Verified fixed for 11.0 and 10.0.3 ESR using Windows 7. Tested with simple mails having attachments with Content-Disposition: inline (thus not bug 705431) in a multipart/related context, and with attachment 575690 [details]. All attachments in this context are now accessible again as desired.

I've tested it too (11.0 using winXP) and it really shows attachments which were not visible in 10.0.2. But when I want to forward such mail, these inline attachments are not attached to the newly created FW email. Can please someone confirm such behavior? thanks

(In reply to Martin from comment #124) Confirm. My test case on OSX Lion: A message that was created by Apple Mail on Lion and saved as a draft in the drafts folder of my IMAP account. This draft message has 2 PDF attachments which were not displayed with Thunderbird 10.2 or older. In Thunderbird 11 (release) the 2 attachments are now displayed (thanks!!). When pressing the edit button (to edit the draft) or choosing to forward it, the attachments are not displayed any longer. After forwarding the message to myself, in the received message, the attachments are missing (message size / source).

Works for me with the examples tested, such "hidden" PDF files re-attach when forwarding inline. If you have a reproducible test case, can you open a new bug and attach it for further investigation, with any personal information removed?

(In reply to Martin from comment #124) > I've tested it too (11.0 using winXP) and it really shows attachments which were not visible in 10.0.2. It's by fix of this bug. "Incorrect/non-referred/no-displayable part in malformed multipart/related mail" is shown as if attachment at attachment pane again by great patch of this bug. "malformed multipart/related" mail case, isn't it? > But when I want to forward such mail, these inline attachments are not attached to the newly created FW email. What is your definition of your "inline attachments" in your case? Please note that "non-referred/non-displayable part in malformed multipart/related" is never actual ATTACHMENT which is defined by multipart/mixed. It's perhaps revived and new version of Bug 351224 after fix of this bug. (a) Original of Bug 351224. Is "non-referred part in malformed multipart/related" detachable/deletable? (b) Your case. Can "non-referred part in malformed multipart/related" be forwaded as actually attached file to mail by Forward? Please note that this bug is to provide a way to save "non-referred/non-displayable parts in malformed multipart/related mail" to local file by showing the malformed parts in multipart/related as if attachment in attachmet pane.

In the worst case, it should be possible to just drag-and-drop such attachments from the attachment pane of the original message into the attachment pane of the message which you are composing as forwarding that message. As WADA pointed out, keep in mind that this bug started off with already incorrectly formatted messages which are effectively hiding the attachment from the user. Those are accessible now again, and there may be too many different cases to consider how such attachments may be nested inside that multipart/related context. Thus, the fix here should solve the bulk of those issues but certainly may leave specific cases uncovered.

Please file followups (with test cases!) for any remaining issues.

It does not seem to be fixed in TB 17.0.4 . I have a message with a pdf attachment. I can see the attachment in gmail but I do not have trace of it in TB. Let me know if I can provide any information.

Stefano, see Jim's comment right above yours. If you have a specific e-mail where you think the behavior is wrong, please file a new bug report and attach that e-mail (you can use a text editor to remove or xxx out any private information you do not want to post publicly, including the bulk of encoding for the attachment, but make sure that the structure of the message and all headings remain intact).

We are using Replicon WebTimesheet, and it sends it's offline timesheet as an html file attachment. I just recently started using TB (was using outlook), and I just discovered this "invisible attachment" bug. I was running TB version 17 when I first noticed this yesterday. Then I saw that an update was available, I went to version 24. The problem was still there. I tested TB version 11 also, and the problem is still there too. View source confirms the MIME message is formatted such that it seems to match this bug: (I will start from the relevant lines in the header onward to the bottom minus the actual contents) MIME-Version: 1.0 Content-Type: multipart/mixed; charset=utf-8; boundary="div-phqghumeaylnlfdxfirc" Content-Transfer-Encoding: 7bit --div-phqghumeaylnlfdxfirc Content-Type: text/html; name="Expense.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Expense.html" <Expense.html file contents> --div-phqghumeaylnlfdxfirc Content-Type: multipart/alternative; charset=utf-8; boundary="div-vscxggbwkfnqduxwfnfo" Content-Transfer-Encoding: quoted-printable This=20is=20a=20multipart=20MIME=20encoded=20message --div-vscxggbwkfnqduxwfnfo Content-Type: text/plain Content-Transfer-Encoding: base64 <this is the email body in plain text> --div-vscxggbwkfnqduxwfnfo Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <this is the email body in html> --div-vscxggbwkfnqduxwfnfo-- --div-phqghumeaylnlfdxfirc-- I can see the attachment if I view all body parts (after what seems silly, I turn on the config option "mailnews.display.show_all_body_parts_menu").

i pinpointed the bug to a single line Content-Type: multipart/mixed; vs. Content-Type: multipart/alternative; showing the attachment normally: Content-Type: multipart/alternative; shown only with "view all body parts": Content-Type: multipart/mixed; the email is sent from a python code, and the attachment is visible both cases on gmail webclient.

(In reply to Shula Amokshim from comment #133) > i pinpointed the bug to a single line > > Content-Type: multipart/mixed; > vs. > Content-Type: multipart/alternative; This bug is about multipart/related, not mixed or alternative. It was also fixed a while ago, so this isn't the best place to report new issues. Please file a new bug (or add a comment to an existing, unresolved bug) for your issues.