In the attached mail there's supposed to be an inline picture, but the picture is show as an attachment. Outlook Express correctly shows the image at the correct place (inline), Mozilla doesn't. I think CID's URLS are specified in RFC2111 http://blitzen.canberra.edu.au/RFC/rfc/rfc2111.html

changing qa assign

reassigning to ducarroz

JF, is this a mail bug?

I took a quick look at it and the content type of the message is already wrong: it sould be multipart/related and not multipart/mixed. But even after changing the content type, I am still not able to see the image. Need further investigation...

similar/dup: bug 115995

Comment on attachment 20081 [details] Mail with img src using cid Changed MIME Type from text/plain to message/rfc822 for proper rendering when downloading from Bugzilla.

On Linux and Mac this also throws an unknown protocol alert because there is no system handler for cid: like there is on Win32.

weird, on my linux box this particular test case doesn't give me the alert that bryner was seeing. but doing cid: in the url bar does give me the alert. bryner, can you attach your evil message?

bryner, as we talked about, I've stubbed the cid: protocol. once I check this in (after I make the mac changes), you won't see that alert. the next step is to add cid support to mime, so that we can take aBaseUri, like: mailbox:///home/seth/.mozilla/default/jld07o53.slt/Mail/Local%20Folders/bug.txt?number=2133&part=1.2 and create a uri and set the spec to: mailbox:///home/seth/.mozilla/default/jld07o53.slt/Mail/Local%20Folders/bug.txt?number=2133&cid=image001.gif%4001C0591B.7C17FDB0 and have that fetch the part. we already fetch part by number, now we need to add the ability to fetch the part by cid.

Comment on attachment 111688 [details] [diff] [review] patch to fix bryners alerts, and place holder for the real fix obsolete. this patch is really just for the annoying alert bryner was seeing on linux, which is bug #189358. this bug should stay open until we properly implement the cid protocol, which will involve some mime work (gulp!)

did some testing and it's due to the Content-Type. The one that doesn't work has: Content-Type: multipart/mixed; this works: Content-Type: multipart/related; type="multipart/alternative"; not sure what we can do, but Outlook Express does something so that the first one also works

solution in previous comment confirmed to be still valid on winxp 20040208 1.7a head of the test case becomse the following : From: test@test.com To: "'test@test.com'" <test@test.com> Subject: test Date: Tue, 28 Nov 2000 09:10:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_000_01C0595E.0DDAE0E0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

(In reply to comment #13) > this works: > Content-Type: multipart/related; > type="multipart/alternative"; The second parameter -- type="multipart/alternative" -- is actually superfluous; I'm not sure what that's supposed to mean, but omitting it yields the same result as including it. Note that the GIF part also has the header: Content-Disposition: attachment; filename="image001.gif" but if that's changed to 'inline' the image is still not shown within the HTML message. > not sure what we can do, but Outlook Express does something so that the > first one also works Updating the URL with the relevant RFC. The text about this is pretty minimal: 7.2.2. The Multipart/mixed (primary) subtype The primary subtype for multipart, "mixed", is intended for use when the body parts are independent and need to be bundled in a particular order. This may be another instance where Moz needs to "be [more] liberal in what you accept..." See also bug 240743.

I've been suffering with this bug also but it seems to be fixed in the latest nightly builds!

The bug is still present in my testing of 3a1-0226, Win2K, as well as a 2b2 build from last week. The testcase attached to this bug behaves as before.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Filter on "Nobody_NScomTLD_20080620"

Please fix this bug as soon as posible - can't use Thunderbird. All replayed messages are broken (without images) because of this bug. Please change Importance to CRITICAL.

Please change an importance to CRITICAL. Can't use Thunderbird with The Bat! users at total. Thunderbird is really nonfunctional application because of this issue. Why everybody are still ignoring this issue for the years when it should be fixed in hours?.. I can't understand developer's community... But a hope die last.

Comment on attachment 494718 [details] A screenshot of the bug Look it!!!

Is it possible to pay developers to fix this issue right now? Can't use Thunderbird else.

(In reply to comment #23) > Please change an importance to CRITICAL. Importance(Priority, Severeity) is defined attributes of a bug at B.M.O. It's never for your feeling. So, this bug can not be Severity=critical at B.M.O. (In reply to comment #24) > A typical message from The Bat! 4 that is broken in Thunderbird 3 It's typical message broken by Bat!. Although cid: can be specified at any place in a mail by RFC which defines cid: url, interpretation of multipart/mixed is already defined, and the definition of multipart/mixed is never altered by RFC for cid: url. And, interpretation/resolution of <img src="cid: url"> in text/html is defined only for mime parts in multipart/related(RFC for MHTML). And, interpretation/resolution of <img src="cid: url"> in text/html is already defined as the RFC for MHTML which defines the multipart/related. Unless such definitions are changed or enhanced, Bat! has to use multipart/related instead of wrong multipart/mixed for { "<img src="cid: url"> in text/html" + "image/xxx with Contentent-ID:"}, even if MS Outlook shows the multipart/mixed mail as if multipart/related mail. See bug 606945, please. That is our curent understanding of the issue.

But what's problem to make support of The Bat! mail? Standards are abstractly. Reality is our purpose. And reality is that there are a lot of The Bat! messages. And we should display correctly all of them in Thunderbird if we want to build good and useful application.

(In reply to comment #29) > And we should display correctly (snip) Correctly based on what? If multipart/mixed, correct display is rendering result by Tb, because the mail is multipart/mixed mail instead of multipart/related mail. For tolerance with misuse of multipart/mixed for multipart/related by Bat! or other mailers, feature of "force wrong interpretation of multipart/mixed as multipart/related according to your want" will be required to keep correct interpretation of both multipart/mixed and multipart/related. It can be option of Tb, add-on, external tool which replaces string of wrong multipart/mixed by multipart/related in Tb's unix mbox file. However, fixing of bug of Bat! should be requested before asking such tolerance of an RFC compliant mailer. Is it wrong? Requesting of bug fix of Bat! is far harder than requesting fix of MS's "'this is spec' for really critical bug"?

Sorry, I can't understand all you wrote. But The Bat! messages display correctly in every mail-application except Thunderbird. That's a Thunderbird issue because the application can't display a big part of incoming mail correctly (but Thunderbird should). And for example, I can't use Thunderbird in my corporation because my incoming messages and outcoming replies are broken at total. Thunderbird is nonfunctional as fact in couple with The Bat! users. We just only should to display correctly all messages from the latest versions of popular mail-clients. That's all! And all other mail-applications already do this.

Reality is a proper standard. The application should work correctly with real messages. Add all The Bat! messages are real.

Please just delete a char '=' from 'cid: ...' and the issue will be fixed.

All web-mail systems display The Bat! mail correctly too. Just Thunderbird don't do this yet...:(

Batman to the rescue! I'm outta here.

(In reply to comment #33) > Please just delete a char '=' from 'cid: ...' and the issue will be fixed. What do you mean? If '=' at last position of a line in mail source you attached, it's continuation mark of quoted-printable. (In reply to comment #34) > All web-mail systems display The Bat! mail correctly too. Just Thunderbird > don't do this yet...:( If you are saying "some web-mails show as you want, as MS Outlook shows, as Bat! watns", I know it. Please read thru bug 606945. Do you read and understand "wrong Content-Type:" in bug summary set by bugzilla@gemal.dk on 2003-11-10 and "wrong Content-Type: multipart/mixed" in bug summary by mcow@well.com on 2005-02-22? (see "History" of this bug) Please note that I never try to reject your request. I want to say: - Fix of bug of Bat! has to be requested first. - Even if problem is caused by bug of other mailers, if it's hard to request fix of bug of other unknown many mailers, many developers accepted request for torelance with bug of other mailers, and implemented features for it. For example, Some mailers put non-ascii binary in Subject: without encoding. => If the binary is same as charset of mail body, interprte the binary as charset of mail body, to make the wrong Subject: header readable for user. Some mailers put wrong charset in Content-Type: => Following per folder setting was implemented, in order that user can read such malformed mail without changing View/Character Encoding upon each mail read. [?] Apply default to all messages in the folder (individual message character encoding setting and auto-detection will be disabled) - Even if problem is caused by bug of Bat!, if very many Tb users suffered from bug of Bat!, and if fixing of bug of Bat! in short term is impossible, requesting of torelance with bug of Bat! of Tb like some web-mailers is reasonable. - However, if such request is based on wrong assumption like "Bat! is correct", I'm sure no one will accept your request. While you repeat "Bat! is correct and correct display is one you want", I believe answer to your request is INVALID or WONTFIX.

Hi, WADA! Thanks for your answer. I understand all you wrote now. 1. I already report this issue to The Bat! team a few times - but there's no any result. 2. Sorry, the suggestion of '=' char is wrong. 3. I can't understand why and how all mail applications and all web mail clients work fine with The Bat! incorrect mail. Thunderbird can't display 100% of The Bat! messages with images. It's really great issue because of this. 4. How to make an extension to resolve this problem without any knowledge about developing of Mozilla products? Regards, Dmitry.

(In reply to comment #37) > 4. How to make an extension to resolve this problem without any knowledge about > developing of Mozilla products? Hire skilled person, pay money sufficiently, force him/her to write code for you or your company, and donate the code to Mozilla Foundation for us :-) To explain about issue to developers(Tb, add-on, ...), I believe at least next is needed. (1) Link to bug fix request to Bat! team, and link to answer from them. (2) Data of number of Tb users who really needs the tolerance with Bat!, data of number of users in such users who can not transfer to other than Tb (3) What kind of solution is convenient for majority of such users; - Ad-hoc view multipart/mixed as multipart/related - Folder properties of "always show multipart/mixed as multiplle/related" - Always interpret multipart/mixed as multipart/related, and if sub part is not used by HTML, show it as real attachment as done on multipart/mixed, instead of "show it as if attachment, as done on multipart/related". - Alter mail source upon download from multipart/mixed to related, if mail from Bat! or if Content-Id: exists in multipart/mixed. If mail server is owned, it can be done at server efficiently. It's almost same as spam filtering at server. It may be simplest or easiest way for add-on. - Others (4) Estimated cost(workload, difficulty, ...) of each solution and gain by the solution, and evaluation of each solution. (5) Data of detailed status of major or popular mailers, major web-mails. These don't request knowledge about developing of Mozilla's code. After it, all is up to developers who are volunteers. This kind of "improvements for user's convenience of limited users" should be requested in separated bug(Severity=Enhancement).

While this is not technically a bug in TB, but result of slightly "malformed" messages sent by other mailers (using multipart/mixed where they should use multipart/related), it is a real-world problem for many users of TB, because such messages are displayed with broken images. RFE: TB could and should be more generous in handling this little flaw. When there are inline references of type <img src="cid:..."> correctly pointing to existing image parts in the same message, there's no reasonable doubt about the sender's intention of showing these images inline. And I don't see any real problems with showing them, either. Nota bene: This is not a request to just bluntly ignore the difference between multipart/mixed and multipart/related. It's a very practical request that *if* the HTML part contains working inline references to other parts of the mail, we should resolve such references as intended/expected and show those parts inline even if the declaration of multipart/mixed vs. multipart/related happens to be inappropriate. For the sake of this bug, imo it's fine to show affected parts both inline (this bug) *and* as file attachment (as we do now, correctly because of multipart/mixed); thus we would still give a hint that there's something odd with that message. I really agree with Mitra's Bug 679325 Comment 6: > There is an old saying in communications development that goes - be > conservative in what you send out, and liberal in what you accept. i.e. TB > should be rigorous in complying to standards in what it sends, but very > liberal in handling other mail agents/server's misbehavior in a way that > makes sense to the NON-TECHIE user.

I certainly agree with what you've said here Thomas, especially the reference to Mitra's Bug 679325 Comment 6. Perhaps 12 years later after the first report of this issue, the TB developers might reconsider their position, and provide the enhancement needed.

We know the design of thunderbird follows the standard definition. However, the common thunderbird users do need some enhancement to face the real imperfect world. For example, the addon " LookOut " helps the thunderbird users to read the Outlook mails normally. I have received the mail from a telecom company with the wrong Content-Type: multipart/mixed problem. Please see the attachments. If there is an enhancement available, it would be very helpful to the thunderbird users. Thanks and Best regards.

(In reply to mwu4 from comment #49) > We know the design of thunderbird follows the standard definition. > However, the common thunderbird users do need some enhancement to face the > real imperfect world. For example, the addon " LookOut " helps the > thunderbird users to read the Outlook mails normally. I have received the > mail from a telecom company with the wrong Content-Type: multipart/mixed > problem. Please see the attachments. If there is an enhancement available, > it would be very helpful to the thunderbird users. > > Thanks and Best regards. Am I wrong if I say that, following the rfc 2111 + 2112 (multipart/related) and the rfc 1521, that the following message structure should be recognised from TB in the right way? +---------------------------------------------------+ | multipart/mixed | | +-----------------------------------------------+ | | | multipart/related | | | | +---------------------------+ +------------+ | | | | | multipart/alternative | | image/* | | | | | | +-----------+ +---------+ | | | | | | | | |text/plain | |text/html| | | (cid:...) | | | | | | +-----------+ +---------+ | | | | | | | +---------------------------+ +------------+ | | | +-----------------------------------------------+ | | | | +-----------------------------------------------+ | | | image/*, application/*, ... | | | | | | | | | | | +-----------------------------------------------+ | +---------------------------------------------------+ The cid part lays in the "related" multipart, the related multipart lays in the mixed multipart. TB shows the cid part as inline only if I take multipart/related instead of multipart/mixed also for the outer part. In my opinion this is a real bug.

An enhancement example. Just an idea. > (1) New prefs for stretching RFC interpretation. Some are reasonable, some are intentional RFC violation. > quirks.for_multipart_HTML.multipart_related = "multipartrelatd" : strict multipart/related mode / "multipart/mixed+related" mode : MS mailer mode > quirks.for_multipart_HTML.multipart_mixed = "multipart/mixed" : strict multipart/mixed mode / "multipart/mixed+related" mode : MS mailer mode > (2) For any subpart under any multipart(including multipart/alternative) in the mail, > if Content-ID is used, mark it by flag => ContentIdIsUsed=false. > (3) When ( ( multipart/mixed && quirks.for_multipart_HTML.multipart_mixed == "multipart/mixed+related" ) || > multipart/related ) > resolve CID URL which used in text/html part(<img src="cid:...">, <iframe src="cid:...">), > as currently done for multipart/related. > If a subpart under any multipart(including multipart/alternative) in the mail is used by CID URL, > set ContentIdIsUsed=true. > (4) When ( quirks.for_multipart_HTML.multipart_mixed == "multipart/mixed+related" || > ( quirks.for_multipart_HTML.multipart_related == "multipart/mixed+related" ) > (4-1) if a subpart under any multipart(except multipart/alternative) has ContentIdIsUsed=false, > show it as actual attachment(i.e. deletable/detachable). > (4-2) if a subpart under any multipart(except multipart/alternative) has ContentIdIsUsed=true, > don't show it as actual attachment(i.e. not-deletable/not-detachable). > (5) Enhance Delete/Detach feature according to change of (4-1)(4-2).

[Issue-1 in the example] When following mail, multipart/alternative text/plain multipart/related text/html, <img src="cid:Used_CID_URL">, no pointer to Non_Used_CID_URL Content-Type;image/jpeg, Content-Id:<Used_CID_URL> Content-Type;image/jpeg, Content-Id:<Non_Used_CID_URL> if mail is shown with View/Message Body As/HTML, Content-Id:<Non_Used_CID_URL> part is currently shown as-if attachment by already implemented quirks for this kind of mail, but if mail is shown with View/Message Body As/Plain Text, Content-Id:<Non_Used_CID_URL> part(and needless to say Content-Id:<Used_CID_URL> part too) is not currently shown as-if attachment. Above enhancement example contains solution of this kind of problem. However, Content-Id:<Used_CID_URL> part is also shown as attachment, so user can delete the Content-Id:<Used_CID_URL> part. So, with any quirks for malformed mail, unwanted bugs will be opened by general users. If Content-Id:<Non_Used_CID_URL> part is not shown as-if attachment with View/Message As/Plain Text, bug for it is opened by user(current status). If Content-Id:<Non_Used_CID_URL> part is shown at attachment pane but is not-deletable, bug is opened for it by user(current status). If mail is shown with View/Message Body As/HTML after Delete operation on Content-Id:<Used_CID_URL> by user with View/Message Body As/Plain Txt, image is broken, and bug will be opened by user.

[Issue-2 in the example] What is scope of CID URL resolution? How about CID URL in mail attached as message/rfc822? multipart/mixed multipart/related <= message body text/html, <img src="cid:Used_CID_URL_A">, no pointer to Non_Used_CID_URL_A, <img src="cid:Non_Used_CID_URL_C"> <= subpart under other multipart Content-Type;image/jpeg, Content-Id:<Used_CID_URL_A> Content-Type;image/jpeg, Content-Id:<Non_Used_CID_URL_A> Content-Type;image/jpeg, Content-Id:<Non_Used_CID_URL_B> <= image file attachment multipart/related <== text/html attachment with embed image text/html, <img src="cid:Used_CID_URL_C">, no pointer to Non_Used_CID_URL_C, <img src="cid:Non_Used_CID_URL_A"> <= subpart under other multipart Content-Type;image/jpeg, Content-Id:<Used_CID_URL_C> Content-Type;image/jpeg, Content-Id:<Non_Used_CID_URL_C> message/rfc822 <== attached mail multipart/related <= message body of attached ail text/html, <img src="cid:Used_CID_URL_A">, <img src="cid:Non_Used_CID_URL_A"> <img src="cid:Non_Used_CID_URL_B">, <img src="cid:Used_CID_URL_C">, <img src="cid:Non_Used_CID_URL_C"> As far as based on normal MIME interpretation, CID URL in message/rfc822 is irrelevant to parent mail. However, if based on CID URL definition only, "CID URL resolution with parant mail" is posisble.

Paste as qutation for readability. Sorry for spam. > a problematic mail structure > multipart/mixed > multipart/related <= message body > text/html, <img src="cid:Used_CID_URL_A">, no pointer to Non_Used_CID_URL_A, > <img src="cid:Non_Used_CID_URL_C"> <= subpart under other multipart > Content-Type;image/jpeg, Content-Id:<Used_CID_URL_A> > Content-Type;image/jpeg, Content-Id:<Non_Used_CID_URL_A> > Content-Type;image/jpeg, Content-Id:<Non_Used_CID_URL_B> <= image file attachment > multipart/related <== text/html attachment with embed image > text/html, <img src="cid:Used_CID_URL_C">, no pointer to Non_Used_CID_URL_C, > <img src="cid:Non_Used_CID_URL_A"> <= subpart under other multipart > Content-Type;image/jpeg, Content-Id:<Used_CID_URL_C> > Content-Type;image/jpeg, Content-Id:<Non_Used_CID_URL_C> > message/rfc822 <== attached mail > > multipart/related <= message body of attached ail > text/html, <img src="cid:Used_CID_URL_A">, <img src="cid:Non_Used_CID_URL_A"> > <img src="cid:Non_Used_CID_URL_B">, > <img src="cid:Used_CID_URL_C">, <img src="cid:Non_Used_CID_URL_C">

FYI. If "show as attachment based on ContentIdIsUsed=true/false flag" is applied to multipart/alternative too, and if ContentIdIsUsed=false is set when mail type is not supported by Tb, request like following will be fulfilled. When mail like next, show application/pdf and audio/wav under multipart/alternative as attachment, because Tb doesn't have capability to display application/pdf and audio/wav part as message body. > a possible multipart/alternative mail > multipart/alternative > text/plain : text version => ContentIdIsUsed=true > text/html : simple HTML version => ContentIdIsUsed=true > multipart/mixed : HTML with image version => ContentIdIsUsed=true > multipart/related > text/html > image/jpeg, Content-Id:<...> > image/jpeg, Content-Id:<...> > application/pdf : PDF mail version => ContentIdIsUsed=false > audio/wav : Voice mail version => ContentIdIsUsed=false

(In reply to Lorenzo Orsatti from comment #50) > +---------------------------------------------------+ > | multipart/mixed | > | +-----------------------------------------------+ | > | | multipart/related | | > | | +---------------------------+ +------------+ | | > | | | multipart/alternative | | image/* | | | > | | | +-----------+ +---------+ | | | | | > | | | |text/plain | |text/html| | | (cid:...) | | | > | | | +-----------+ +---------+ | | | | | > | | +---------------------------+ +------------+ | | > | +-----------------------------------------------+ | > | | > | +-----------------------------------------------+ | > | | image/*, application/*, ... | | > | | | | > | | | | > | +-----------------------------------------------+ | > +---------------------------------------------------+ > The cid part lays in the "related" multipart, the related multipart lays in > the mixed multipart. > TB shows the cid part as inline only if I take multipart/related instead of > multipart/mixed also for the outer part. > In my opinion this is a real bug. Are you talking about which case? (a) CID of image in multipart/related is pointed by <img src="cid:..."> in HTML (b) CID of image in multipart/related is NOT pointed by <img src="cid:..."> in HTML Are you talking about phenomenon with which? (c) View/Message Body As/HTML (d) View/Message Body As/Plain Text It sounds for me you are talking about (a) and (d)... I any case, multipart/alternative is replaced by one of child after MIME header analysis, and multipart/related is replacement of a child like text/plain or text/html in multipart mail. So, if (c) View/Message Body As/HTML, the mail with multipart/alternative is identical to; multipart/mixed{ multipart/related{ text/html + image/CID=xxx } + image file } CID pointed => multipart/mixed{ (text/html, embed image) + image file } CID not pointed => multipart/mixed{ (text/html, broken image) + image file } and if (d) View/Message Body As/Plain Text, the mail is identical to; multipart/mixed{ multipart/related{ text/plain } + image file } => multipart/mixed{ text/plain + image file } because text/plain doesn't have capability to point CID URL. i.e. multipart/related{ text/plain + image with CID } is nonsense and it's simply misuse of multipart/related without understanding what is multipart/related. If (b) and (c), > (b) CID of image in multipart/related is NOT pointed by <img src="cid:..."> in HTML > (c) View/Message Body As/HTML AFAIK, Tb currently shows the "non-used image part with CID" as-if attachment, although it's not deletable. Is it wrong? If (d), > (d) View/Message Body As/Plain Text AFAIK, Tb currently doesn't not show the "non-used image part with CID under multipart/related" as-if attachment, based on definition by RFC. However, it's never "bug of Tb"=="flaw in design/implementation/code of Tb". It's simply misuse of multipart/related by mail sender, if mail sender expects the "image with CID under multipart/related but never pointed or never used" is treated as attachment at mail recipient side. If mail sender wants it shown as attachment, mail sender has to send it as "attachment" in never-ambiguous format and widely-accepted format as "attachment" in mail. My "an enhancement example" contains quirks for this case.

[Issue-3 in enhancement example] If HTML consists of many imagee parts, and if it's sent with following structure, attachment pane is filled by useless image parts for HTML when View/Message Body As/Plain Text i used. > multipart/related > multipart/alternative > text/plain > text/html consist of many many small images as parts of HTML and some images as photo in HTML > <img src="cid:CID_001">, ..., <img src="cid:CID_999"> <= parts of HTML > <img src="cid:CID_Phoot_X"> <= Photo data in HTML > image/jpeg, Content-Id:<CID_001"> > | > image/jpeg, Content-Id:<CID_999> > image/jpeg, Content-Id:<CID_Phoot_X>

(In reply to WADA from comment #56) > (In reply to Lorenzo Orsatti from comment #50) > Are you talking about which case? > (a) CID of image in multipart/related is pointed by <img src="cid:..."> in > HTML > (b) CID of image in multipart/related is NOT pointed by <img src="cid:..."> > in HTML > Are you talking about phenomenon with which? > (c) View/Message Body As/HTML > (d) View/Message Body As/Plain Text > > It sounds for me you are talking about (a) and (d)... Sorry, I didn't specify, but I mean (a) and (c) > I any case, multipart/alternative is replaced by one of child after MIME > header analysis, and multipart/related is replacement of a child like > text/plain or text/html in multipart mail. > So, if (c) View/Message Body As/HTML, the mail with multipart/alternative is > identical to; > multipart/mixed{ multipart/related{ text/html + image/CID=xxx } + image > file } > CID pointed => multipart/mixed{ (text/html, embed image) + image > file } Thank you for the explanation. This kind of substitution was not clear to me. Do you also know if multipart/related has to be substituted in this way for a specific reason (some rfc)?

(In reply to WADA from comment #57) > [Issue-3 in enhancement example] > > If HTML consists of many imagee parts, and if it's sent with following > structure, attachment pane is filled by useless image parts for HTML when > View/Message Body As/Plain Text i used. > > multipart/related > > multipart/alternative > > text/plain > > text/html consist of many many small images as parts of HTML and some images as photo in HTML > > <img src="cid:CID_001">, ..., <img src="cid:CID_999"> <= parts of HTML > > <img src="cid:CID_Phoot_X"> <= Photo data in HTML > > image/jpeg, Content-Id:<CID_001"> > > | > > image/jpeg, Content-Id:<CID_999> > > image/jpeg, Content-Id:<CID_Phoot_X> Are there some use cases at all, where multipart/mixed is required and could not be covered by the use of multipart/related? If you say that the behaviour of not used embedded attachments is the same in multipart/related and multipart/mixed, then we have no reason to use multipart/mixed any longer. Isn't it?

(In reply to Lorenzo Orsatti from comment #58) > This kind of substitution was not clear to me. > Do you also know if multipart/related has to be substituted in this way for > a specific reason (some rfc)? It's my representation of concept/purpose of multipart/related based on definition of multipart/related. "substitution" like term, "how to substitute" like one, are not written in RFC for multipart/related. Because multipart/related is to provide a way for embedding data like image which is referred/used by document like HTML in mail data stream, nothing is different between followings. (a) text/html, <img src="http://www.abc.def/pqr/xyz.jpg"> (b) multipart/related, start=MainHTML image/jpeg, Content-Id:<xyz.jpg> base64 encoded data of jpeg image held at www.abc.def/pqr/xyz.jpg text/html, Content-Id:<MainHTML>, <img src="cid:xyz.jpg"> So, I called it "multipart/related is substituted or replaced by text/html". (In reply to Lorenzo Orsatti from comment #59) > Are there some use cases at all, where multipart/mixed is required and could > not be covered by the use of multipart/related? > If you say that the behaviour of not used embedded attachments is the same > in multipart/related and multipart/mixed, then we have no reason to use > multipart/mixed any longer. Isn't it? I never say "multipart/mixed == multipart/related". Simply MS did so, even though multipart/related(MHTML) was proposed by MS :-) If definition of multipart/mixed is changed or stretched to one like next, > Show childs in order placed under multipart/mixed, > with respecting attachment or inline requested by Content-Disposition, > after CID resolution as done in multipart/related multipart/related will not be required in many cases. However, use case like following will never be covered by the new multipart/mixed. > multipart/related > multipart/alternative > text/plain > (I said "text/plain under multipart/related with image" is nonsense,) > (but this kind of use case should not be neglected. ) > text/html with low resolution image, <img src="ABC-low-reso.jpg"> > text/html with mid resolution image, <img src="ABC-mid-reso.jpg"> > text/html with high resolution image, <img src="ABC-high-reso.jpg"> > application/pdf, PDF version of above HTML mail which uses embed video > audio/wav, Voice mail version of above HTML mail > image/jpeg, Content-Id: <ABC-low-reso.jpg> > image/jpeg, Content-Id: <ABC-mid-reso.jpg> > image/jpeg, Content-Id: <ABC-high-reso.jpg> > motion/mpeg, Content-Id: <QuckTime.movie> > image/jpeg, Content-Id: <Common-parts-but-not-used-by-above-HTML-01.jpg> > | > image/jpeg, Content-Id: <Common-parts-but-not-used-by-above-HTML-99.jpg> If this kind of mail would be sent as multipart/mixed, ... Strict multipart/mixed processing, strict multipart/related processing is mandatory, even if enhancement/change of RFCs will be done.

I am unableto display jpg images inline attachments; specifically, coming from my friends who send me image attachments using iPhoto. What I see in TB is a large empty square box. On the bottom of the message, I see the attachment. The attachments' mime is image/jpg I have plenty of "helper" apps that can view it. I tried to "open" the attachment, and selected Browse. I browsed to /bin/f-spot F-spot came up and said no image. But if I save the image, I can then open it with f-spot.

After a lot of googling and searching, i finally confirmed the bug! 13 years has passed! yes! 13 YEARS! This bug is still not fixed. Wont fix because it's a "malformed mail"... Duh!

> Wont fix because it's a "malformed mail"... Duh! But as I understand it, the philosophy of a browser is to be as tolerant of errors as possible and display whatever it can. Similarly, instead of blaming the sender, if it's easily possible to figure out what the sender wanted to show, why not just show it? That's *much* more useful for users than the blame game, and even worse, not even giving an error as to why the email is not showing properly. Users don't care that the incoming email violated the spec, they just want to see the picture. If one email client will show the malformed message properly and another one won't, guess which one users will gravitate toward?

ok so now mail from Google is caught up on this bug. They start their email with Content-Type: multipart/mixed; boundary=001a11c2bb683cfd67050d9b0e2a --001a11c2bb683cfd67050d9b0e2a Content-Type: multipart/alternative; boundary=001a11c2bb683cfd5c050d9b0e28 So perhaps there is a bug here that needs fixing. Anyone wants the whole email ping me.

Using Thunderbird 38.2.0 Same bug for reviewing an e-mail I just got an half hour ago. The first, and may be the first couple of times, I had a look on this e-mail all was fine. The images were shown as inline images. When I now view this message, it shows me 14 attachments, and the empty boxes with the broken link icon on the positions where I saw an image before. It looks like the link between the <img> tag and the mime-part containing the image got lost. The e-mail contained several mime parts in which one with the HTML message: Content-Type: text/html; charset="utf-8" Content-ID: <5950BAE6010FE44EA89D67E3D69D9A7A@CENSORED.nl> Content-Transfer-Encoding: base64 Decoded it shows on the positions of the images (with different id for every image): <img id="_x0000_i1038" src="cid:" height="457" width="473"> The mime part of the image does not seem to have any link with the img id: Content-Type: image/jpeg; name="ATT00001.jpg" Content-Description: ATT00001.jpg Content-Disposition: attachment; filename="ATT00001.jpg"; size=22550; creation-date="Mon, 07 Sep 2015 14:01:00 GMT"; modification-date="Mon, 07 Sep 2015 14:01:00 GMT" Content-ID: <0775DD556098814296F6DA9FFE432D60@CENSORED.nl> Content-Transfer-Encoding: base64 But as I started, the message was shown correctly before.

I had the same issue: All other clients showed inline image in HTML while Thunderbird was not showing inline image. Instead it showed an regular attachment to download. The problem was that I tried to inline PNG image. When I converted it to JPG everything worked correctly.

Hello. Immediately I apologize for my English. Perhaps this is the reason that I do not fully understand all that is written before me. Do I understand correctly, that if the e-mail Content-Type is set to "multipart/mixed" image in the body of the letter(HTML), with a URL containing cid, must not appear or is it a bug? (Now there is just so in the TB). The problem is not TB, and other e-mail clients that incorrectly formed messages contrary to standards?

Once again. I am terribly sorry, but I do not see any information about the Multipart/related subtype in RFC 1521(Url in header: http://www.faqs.org/rfcs/rfc1521.html). You are sure that it would work and it did not need to use Multipart/mixed subtype? You are sure that the use of the Multipart/related subtype corresponds to the standard? Once again - I could not find any information about the Multipart/related subtype in RFC 1521.

Just to clarify: what pros and cons exist for handling src="cid:…" links in multipart/mixed Content-Types as if they were in multipart/related? At least with some messages I've tested with, swapping multipart/related for multipart/mixed is all that is needed to work around this bug nowadays. From my (elementary) understanding of the snippets of RFCs quoted here, it seems multipart/mixed is all about specifying order of attachments as listed by the mail client. Allowing them to additionally be rendered in the HTML body seems rather innocuous and not even a flagrant violation of spec. It seems such a small tweak would solve this bug … even if it's a workaround for the true bug, which is in MS products and those that mimic them. As noted in comment 63, RFCs aren't strict specs and email software is notoriously bad at strict adherence to its specs (which is actually quite a boon to those of us who combat spam).

Confirming that attachment 96803 [details] and attachment 494717 [details] is using multipart/mixed when it should be multipart/related. I don't see that we will drill open our ancient MIME code to accommodate for this violation of the MIME spec. To factually this is a WONTFIX, but we can keep it on file if we ever replace the MIME module.