This is just a tracking bug for nsbeta2 purposes. When we send a message with an attachment, we use the nsIMIMEService in the networking module to give us the content type for the extension of the attachment. This content type is bundled up in the ougoing message. When you later receive and try to open the attachment. The client application uses that content type to figure out how to open it. Unfortunately the current mime service encapsulates just a list of hard coded content types and file extensions. Anything not in this list, we end up giving it an unknown content type when it is sent. This prevents proper opening of the attachment by the client receiving the mail. This problem will be fixed by Bug #43556. When the mime service is actually implemented on top of the exthandler code I wrote this past week then it will be dynamic and contain mime type information we get from both the user, the operating system and our hard coded strings.

shame on me....how did I not nominate this for nsbeta2! the good news is the parent bug is nsbeta2. No real work has to be done for this bug. It should just work once 43556 is implemented but i want a separate bug to track this issue.

Putting on [nsbeta2+] radar for beta2 fix.

adding estimated completion date.

as important as I think this is, given our new criteria of "would you pull the beta off the wire for this", I don't think I would. According to the new criteria established at the leads meeting today and from our mailnews beta2 triage meeting this afternoon, marking nsbeta2-.

+ per mail triage.

Scott - I'm going to mark this a duplicate of 43556 because of your comments earlier in the bug. If you disagree and this bug needs work to be done, please remove the duplication status. *** This bug has been marked as a duplicate of 43556 ***

verified duplicate