User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 Build Identifier: 3.0 When I receive an Office 07 attachment and look at the message source (ctrl-u) the content-type appears as follows: Content-type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name=scf2010.docx Content-transfer-encoding: base64 Content-disposition: attachment; filename=scf2010.docx TB doesn't know how to open the file. If I edit the source and remove the CRLF between "content-type:" and the next line it works. Below is the example: Content-type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name=scf2010.docx Content-transfer-encoding: base64 Content-disposition: attachment; filename=scf2010.docx Reproducible: Always Steps to Reproduce: 1. Place a CRLF after the Content-type: header for the attachment. Actual Results: When double clicking on the attachment TB doesn't recognize it as an Office doc and asks what app I want to use to open it. Expected Results: When double clicking on the attachment it should open the doc in Office. Will be happy to provide additional info including entire message source at request. I would also be happy to test any possible solutions. Current work around is to right click on attachment and save it then open it.

Would be nice to have a testcase (an example email, save the email in .eml format, come back to this webpage and click add an attachment.).

Other steps to reproduce: 1. Send an e-mail with Thunderbird with and .xlsx file as an attachment 2 [review]. Open e-mail with Thunderbird. Actual results: The file type isn't recognized and Thunderbird adds a ".txt" extension to the file. Additional Information: Sending the file from Gmail to Thunderbird is Ok, the content type is on one line and Thunderbird can open it like any other files. The problem is when Thunderbird sends a file with a "long" content-type (like Office 2007), it wraps the text below since it goes beyond 73 or 80 characters long. Here is an example of the problem with an Excel file From Gmail : Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Test.xlsx" Content-Disposition: attachment; filename="Test.xlsx" Content-Transfer-Encoding: base64 From TBird : Content-type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name=Test.xlsx Content-transfer-encoding: base64 Content-disposition: attachment; filename=Test.xlsx My guess is that there are 2 problems here : - Thunderbird wraps long content-type when sending emails if the length is too long (73 or 80 characters) - Thunderbird isn't able to read the content-type if the value is under the tag.

This is a example showing that a file sent from Gmail to Thunderbird doesn't produce the bug since the "Content-Type" and it's value are on the same line.

This is a example showing that a file sent from Thunderbird to Thunderbird produces the bug because Thunderbird places the value of "Content-Type" under the tags for the attached xlsx file.

(In reply to comment #0) > Actual Results: > When double clicking on the attachment TB doesn't recognize it as an Office doc > and asks what app I want to use to open it. What happens after it? After select MS Word(or MS Excel) as application to open at the dialog and view the attachment, what will happen upon next double click of the attachment? As filename=...docx is written, entry for .docx is creatd in Tools/Options/Atachments. So I think next double click invokes MS Word(or MS Excel). By the way, I checked with application/<string_of_2048_bytes> for ".TXT2". (<string_of_2048_bytes> = 2048 bytes alphabet only text with no space) Tb generated next header by "Send Later". > Content-Type:[CRLF] > application/<string_of_2048_bytes>;[CRLF] > name="...TXT2"[CRLF] After dialog for open application(I choosed notepad) upon first double click, this attachment was opened with notepad by double click. This means that action on "Unknown mime-type" works well. If above header will be sent to SMTP server, it may be RFC violation. If above heaer will be sent with splitting into shorter lines, it'll be corruption of mail header. But this is not problem. Culprit is who generated such stupid/wrong/long mime-type(==me) :-)

(In reply to comment #6) > (In reply to comment #0) > > Actual Results: > > When double clicking on the attachment TB doesn't recognize it as an Office doc > > and asks what app I want to use to open it. > > What happens after it? > After select MS Word(or MS Excel) as application to open at the dialog and view > the attachment, what will happen upon next double click of the attachment? > As filename=...docx is written, entry for .docx is creatd in > Tools/Options/Atachments. So I think next double click invokes MS Word(or MS > Excel). TB asks with what program to open "xyz.docx.txt". Here the ".txt" is added BY TB because TB cannot read the MIME type. Selecting a program will not add an entry in Tools/Options/Atachments. Doing so with the OK version from Gmail will add the entry, but the problem will still be there when you use the bad version (even after the entry was created). > > By the way, I checked with application/<string_of_2048_bytes> for ".TXT2". > (<string_of_2048_bytes> = 2048 bytes alphabet only text with no space) > Tb generated next header by "Send Later". > > Content-Type:[CRLF] > > application/<string_of_2048_bytes>;[CRLF] > > name="...TXT2"[CRLF] > After dialog for open application(I choosed notepad) upon first double click, > this attachment was opened with notepad by double click. > This means that action on "Unknown mime-type" works well. I think that in this case it is in fact an "unknown mime-type", but in the problem, I think that TB isn't even able to READ the mime-type. Meaning that in your example TB has some sort of MIME value (your 2048 byte string), but in this bug, TB has a null value for the mime-type, thus meaning it cannot add an entry to the Tools/Options/Atachments. We did further testing with TB 2.6 (in which the problem isn't there, hint: you may want to check was was done before ;-), it seems that there is something going on with a space or not after the CRLF. I can't remember exactly what was in the file, but it was something like : in TB 2.6 : Content-type:[CRLF]application/vnd.openxmlformats-officedocument.wordprocessingml.document; in TB 3 : Content-type:[CRLF][SPACE]application/vnd.openxmlformats-officedocument.wordprocessingml.document; I don't know if it does anything, but I thought of bringing this up.

I can not understand most of what you are talking about. If you get an actual fix or work around OTHER THAN save the file and open it outside of Thunderbird I hope to hear about it as you seem to be discussing EXACTLY the problem I have! MK

(In reply to comment #8) > I can not understand most of what you are talking about. > If you get an actual fix or work around OTHER THAN save the file and open it outside of Thunderbird > I hope to hear about it as you seem to be discussing EXACTLY the problem I have! We never need your understanding. We never need your hearing. Problem itself is apparent. Tb can't be torelant with Content-Type:[CRLF][SP]major-mime-type/minor-mime-type;[CRLF]..., even though Tb generates such header by himeself when major-mime-type/minor-mime-type is long. It's merely a new RFC violation by Tb on "unfolding should be done before interpretation or parsing of a mail header", if space between "Content-Type:" and positional mime-type paramter is FWS(Folding White Space). My purpose of asking about "phenomenon after this bug's problem occurs" to sebastien.gagne@gmail.com is to evaluate impact of this bug. If result is same as my test result with faked application/<string_of_2048_bytes> & ".TXT2", impact of this bug is low. But, if result with real mime-type like lo---ng application/vnd.openxmlformats-officedocument...(for .docx or .emlx, which was needless to say produced by MS) is one like comment #7, we shouldn't evaluate "impact is low".

Well for me it is exactly like comment #7, .doc or .xls is OK but anything .docx, .xlsx or whatever will not open until saved outside of TB. The only exception was in sending to myself I could open the version saved in the sent folder, but not the one that went out and came back in. I can not open anything someone else sends to me if it is Office 2007 version And TB tried to tell me upgrading Word, higher than Office 2003, would be the fix, even though the tester did not have Word but used Wordpad. Others with the same problem tell me Office 2007 does not help, it is all a TB problem.

You should see the comments at Bug 552773

Thunderbird 3.1 appears to not have this problem, yea!

Closing as WORKSFORME per comment #13. Re-open if it's wrong, please.

Probably fixed by bug 543813. Mark as duplicate?

bug 543813 looks only for imterpretation of Content-Type: header(i.e. relevant to unfolding only). This bug has "folding of Content-Type: header just after Content-Type: by Tb" part too, and it was also WORKSFRME. I don't think this bug is absolutely duplicate of that bug.