Open Bug 753215 Opened 12 years ago Updated 2 years ago

Attachment of malformed messages not included when forwarded inline (multipart/related vs. multipart/mixed)

Categories

(Thunderbird :: Message Compose Window, defect)

12 Branch
x86_64
Windows 7
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: ashurr_83, Unassigned)

Details

(Keywords: testcase, Whiteboard: dupme)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

when I forward an email that contains attachment file with the table in that email it didn't forward the attachment  


Actual results:

it didn't forward the attachment only it forward the email with the table that was in email but no attachment 


Expected results:

when you forward it should forward all email content including the attachment.
Works for me (on 12.0.1 and 15.0a1). Can you attach the email in question? Feel free to anonymize any private data, so long as you can still reproduce the issue with the sanitized version.
this the picture of my email that I want to forward with attachment but it doesn't forward the attachment it just forward the table that showing in the email
Comment on attachment 622280 [details]
this the email that I want to forward

when you forward this email doesn't forward the attachment it just forward the content of the message only the table as shown in the pic
That message is improperly-formed. MS Outlook has a bad habit of creating non-compliant messages (specifically, using multipart/related when they should be using multipart/mixed). The workaround is to forward the message as an attachment: Message -> Forward As -> Attachment.
thanks for your help but there is no way around to work on it and fix it or change multipart/mixed to multipart/related or other way around
*Why* does the workaround not work for you?
I am trying here to make Thunderbird more professional and compatible with other mail system so i am trying to make it more convince to my staff that it can do the job with out forwarding it as attachment
Summary: attachment in forward → Attachment of malformed messages not included when forwarded inline (multipart/related vs. multipart/mixed)
Keywords: testcase
Whiteboard: dupme
Component: General → Untriaged
Component: Untriaged → Message Compose Window

I was confronted with this problem this week. I found this entry and blamed Outlook. Then I tried to find why M$ would not solve this. Well, it appears there are two guidelines (please find excerpts below) and guess what: it's ThunderBird that seems to be non compliant.

I actually experimented with the incoming mail from Outlook and changed related to mixed. The attachment was now kept in the forwarded mail.

Please reconsider to make this change in Thunderbird.

https://www.rfc-editor.org/rfc/rfc2049.txt
RFC 2049 MIME Conformance November 1996

Multipart:
-- Recognize the mixed subtype. Display all relevant information on the message level and the body part header level and then display or offer to display each of the body parts individually.
-- Recognize the "alternative" subtype, and avoid showing the user redundant parts of multipart/alternative mail.
-- Recognize the "multipart/digest" subtype, specifically using "message/rfc822" rather than "text/plain" as the default media type for body parts inside "multipart/digest" entities.
-- Treat any unrecognized subtypes as if they were "mixed".

https://www.rfc-editor.org/rfc/rfc2387.txt
RFC 2387 Multipart/Related August 1998
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.

User agents that do not recognize Multipart/Related shall, in accordance with [MIME], treat the entire entity as Multipart/Mixed.

(In reply to Fred_Dingelhoff from comment #8)

I was confronted with this problem this week. I found this entry and blamed Outlook. Then I tried to find why M$ would not solve this. Well, it appears there are two guidelines (please find excerpts below) and guess what: it's ThunderBird that seems to be non compliant.

I don't think that's how these should be interpreted. Thunderbird does recognize multipart/related, so neither of the quoted RFC passages apply. Those would only matter if we had no multipart/related handling at all. In fact, RFC2387 is pretty clear that multipart/related isn't a good place to put a regular attachment: "For a Multipart/Related object, proper display cannot be achieved by individually displaying the constituent body parts."

That doesn't mean the Thunderbird team shouldn't fix the bug (that's why it's not WONTFIX), but it's not an RFC violation.

Thank you for your reply. You are right (of course) that Thunderbird does display the message from Outlook and offers the attachment to open (although the size is not available!).

I found a link to https://support.mozilla.org/nl/questions/1176526 where multipart/related is used in Thunderbird and I think I now understand better how it was meant to be used.

Still leaves me with the test where I manually changed the incoming mail from Outlook to use multipart/mixed (simulating what was suggested in RFC 2049). This resulted in a correctly mentioned size and a correctly forwarded mail...

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: