Incorrect display of MIME Multipart message
I have non critical, yet annoying problems.
My problem is similar to: https://support.mozilla.org/en-US/questions/992656?esab=a&as=aaq
I have a single sender who email's do not display the proper Mime attachment inline. What I have found is that the order of the mime parts seems to be important. In my case, the "HTML" content is listed first in the message, and the "text" content is second. In this case, the "text" is the body part that is displayed.
I have access to the source message. I simply reversed the order of the body parts in the source message, then the HTML version is displayed.
I did installed the addon https://support.mozilla.org/en-US/kb/viewing-all-body-parts I am able to see both parts when I set the correct settings.
My questions seem to be, (why) does Thunderbird care what order the body parts are in? If I choose view "original html", shouldn't thunderbird display the HTML if it exists?
I can post the source message if you think it will help. However as I said, simply re-order the body parts, I get the HTML when it is the 2nd / last body part.
被采纳的解决方案
It is standard practice for the body parts to be Text then HTML.
I think the RFC explains the situation fairly well http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
To quote
As a very simple example, the following multipart message has two parts, both of them plain text, one of them explicitly typed and one of them implicitly typed:
From: Nathaniel Borenstein <[email protected]> To: Ned Freed <[email protected]> Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary"
This is the preamble. It is to be ignored, though it
is a handy place for mail composers to include an
explanatory note to non-MIME compliant readers.
--simple boundary
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text.
It DOES end with a linebreak.
--simple boundary--
This is the epilogue. It is also to be ignored.
The use of a Content-Type of multipart in a body part within another multipart entity is explicitly allowed. In such cases, for obvious reasons, care must be taken to ensure that each nested multipart entity must use a different boundary delimiter. See Appendix C for an example of nested multipart entities.
The use of the multipart Content-Type with only a single body part may be useful in certain contexts, and is explicitly permitted.
定位到答案原位置 👍 2所有回复 (2)
选择的解决方案
It is standard practice for the body parts to be Text then HTML.
I think the RFC explains the situation fairly well http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
To quote
As a very simple example, the following multipart message has two parts, both of them plain text, one of them explicitly typed and one of them implicitly typed:
From: Nathaniel Borenstein <[email protected]> To: Ned Freed <[email protected]> Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary"
This is the preamble. It is to be ignored, though it
is a handy place for mail composers to include an
explanatory note to non-MIME compliant readers.
--simple boundary
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text.
It DOES end with a linebreak.
--simple boundary--
This is the epilogue. It is also to be ignored.
The use of a Content-Type of multipart in a body part within another multipart entity is explicitly allowed. In such cases, for obvious reasons, care must be taken to ensure that each nested multipart entity must use a different boundary delimiter. See Appendix C for an example of nested multipart entities.
The use of the multipart Content-Type with only a single body part may be useful in certain contexts, and is explicitly permitted.
Thank you for the feedback. The most relevant quote from the RFC seems to be:
In general, user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last.
I understand that Thunderbird follows the RFC where other readers appear to make their own choices to which part to display. Thank you for pointing me in the right direction. Now I can go back to the sender and try to get them to "fix" their message generator.