Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Tìm hiểu thêm

Incorrect display of MIME Multipart message

  • 2 trả lời
  • 3 gặp vấn đề này
  • 1 lượt xem
  • Trả lời mới nhất được viết bởi MatthewDva

more options

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.

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.

Giải pháp được chọn

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 <nsb@bellcore.com> 
    To:  Ned Freed <ned@innosoft.com> 
    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.

Đọc câu trả lời này trong ngữ cảnh 👍 2

Tất cả các câu trả lời (2)

more options

Giải pháp được chọn

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 <nsb@bellcore.com> 
    To:  Ned Freed <ned@innosoft.com> 
    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.

more options

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.