I think mail attachment of application/postscript(".ai","eps" etc.) need to be Base64(binary instead of ASCII). When lower than 0x20 data exist in ".eps" file, Thunderbird generated : (A) When 0x00 exists Content-Transfer-Encoding: base64 Whole data is encoded with base64 (with binary mode handling) (B) When 0x00 doesn't exists, 0x80 to 0xFF exists Content-Transfer-Encoding: 8bit All data lower than 0x20 is also written as-is, excluding 0x0A(LF) and (0x0D) which are converted to 0x0D0A on MS Win. (with text mode handling) (C) When 0x00 doesn't exists, 0x80 to 0xFF doesn't exists Content-Transfer-Encoding: 7bit excluding 0x0A(LF) and (0x0D) which are converted to 0x0D0A on MS Win. (with text mode handling) Above are verified on Tb 1.0.2 and Tb latest-trunk 4/22 build. When extention is changed to ".pdf", all the data is encoded with Base64. See attachment 181733 [details] (Originaly attached to Bug 291749) This is ZIP file. Contains followings. (Test Data) eps-7bit.eps(and .pdf) : A,a,X,Y and LF/CR/CR+LF only eps-8bit.eps(and .pdf) : A,a,0x82,0xA0 and LF/CR/CR+LF only eps-x01-xFF.eps(and .pdf) : Some alphabets and all of 0x01 to 0xFF (0x00 is excluded from eps-x00-xFF.eps) eps-x00-xFF.eps(and .pdf) : Some alphabets and all of 0x00 to 0xFF (Attach test result - mail data in Drafts folder) Drafts-Moz-4-24.txt : Mail data created by Mozilla <== Bug 291749 Drafts-Tb-4-22.txt : Mail data created by Thundebird <== This bug's issue Although Bug 195613 says "PDF is binary, PostScript is ASCII" in 2003, RFC 2046 ( http://www.faqs.org/rfcs/rfc2046.html ), "4.5.2. PostScript Subtype" says ; > (7) It is possible to include raw binary information inside > PostScript in various forms. This is not recommended > for use in Internet mail, both because it is not > supported by all PostScript interpreters and because it > significantly complicates the use of a MIME Content- > Transfer-Encoding. (Without such binary, PostScript > may typically be viewed as line-oriented data. The > treatment of CRLF sequences becomes extremely > problematic if binary and line-oriented data are mixed > in a single Postscript data stream.) I guess PostScript Level 1(probably ".ps") is ACII only. But I think further PostScript can contain binary data. Since my test result is intentional test for problem analysis(sending error of ".ai" file), such data maybe won't be included in ".eps" or ".ai" file really. But I think putting 0x01 to 0x1F(excluding 0x0A and 0x0D) in attached data is dangerous. "Considering applicarion/postscript as binary" is required, like application/pdf(".pdf"), at least when 0x01 to 0x1F(excluding 0x0A and 0x0D) are included in data. "Always binary mode" like PDF is desirable, because 0x0A(LF) and 0x0D(CR) will also be kept. Please note that Mozilla trunk has problem of Bug 291749. So comfirmation of this bug's problem should be done on Thunderbird.

Bug 290149 is problem of different file size/different check sum from original when EPS(application/postscript) file is attached in quoted-printable by other mailer. (possibly only new-line related issue when EPS is attached with quoted-printable.) Bug 176258 is new-line character loss problem when EPS(application/postscript) file is attached and received by Mozilla(I don't know 7bit/8bit or quoted-printable in this case.) Bug 290804 reported that EPS(application/postscript) file was attached with quoted-printable by Thunderbird. 7bit/obit or quoted-printable of EPS(application/postscript) attachment seems to be determined by non-character data percentage(See patch for Bug 168098.) Why non-character percentage? EPS(PostScript Level 2 or more) is defined as "Binary", although Adobe Illustrator has ASCII/Binary option on file save and many users save EPS in ASCII format...

See attachment 185860 [details] [diff] [review] from bug 297325 -- that patch adds an item to a table which lists application/* types that are handled as text rather than binary, and application/postscript is right there in the list. I'd guess that simply removing that item from the same table would address this RFE, and perhaps fix bug 176258 as well.

Workaround: Force base64 by user_pref("mail.file_attach_binary", true); See nsMsgAttachmentHandler::PickEncoding in nsMsgAttachmentHandler.cpp

Reset "Assigned To:" to deafult, since "not reading bugmail", and cc-ing to David. David, what do you think about this issue?

I'm inclined to agree that base64 is preferable to QP, since QP seems to be so problematic.

Thunderbird 1.5 has still same error. It recognises it as a text file. EPS has many ASCII characters, but has also binary section for bitmaps. But two points are going wrong: - Thunderbird put it in the mail body (when option preview attachment in mailbody is selected) and when you reply it, the whole attachment is now long part in the body and not more seperated attachment. - Postscript EPS marked as: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Which is wrong. Because the fault is since version 1.x, it's very long bug which is never fixed and forgotten. The good type is: Content-Type: application/postscript; name="xxxxxxxxxxxx.eps" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xxxxxxxxxxxxx.eps" Which is made by Gmail online mailsite. I'm working in studio and send many times EPS files to industry. Now my companion has trouble with EPS files because they're in mailbody placed. It's indeed serious and stupid bug. It must be fixed immediately. I really don't believe it.

(In reply to comment #6) > - Postscript EPS marked as: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > The good type is: > Content-Type: application/postscript; Possible cause of "text/plain" is : - File extention of ".ai" or ".eps" is not defined as "application/postscript" in your environment. Search your Windows registry(if MS Win) for ".ps", ".ai" and ".eps", then check "Content Type" definition of them. This bug is problem about "Content-Transfer-Encoding: 8bit (or 7bit)" instead of "Content-Transfer-Encoding: Base64", when "Content-Type: application/postscript;" is set correctly, even if 0x01 to 0x19 is included in the post script file, and even if ".ai" or ".eps" is defined as "application/postscript" correctly by the system. This causes 0x01 to 0x19(and 0xFF too) in mail data stream, if 0x01 to 0x19(and 0xFF too) is included in the post script file, and it can be critical issue for mail server or mail receiver. Your problem looks for me to be different problem, although EPS file and "7bit" are common. (This bug is applicable only when attached as application/postsctipt.)

(In reply to comment #6) > - Thunderbird put it in the mail body (when option preview attachment in > mailbody is selected) and when you reply it, the whole attachment is now > long part in the body and not more seperated attachment. This part is bug 161775. > - Postscript EPS marked as: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit This is a problem, but it's not this bug. See bug 244618.

This is working as expected now (TB 1.5 and later), I think at least in part due to the fix at bug 269390. If the file contains binary, or even the occasional nonuniform line-ending, the attachment is encoded as base64. PS and EPS extensions are automatically recognized as application/postscript.

Re-opening because problem still remains. - A) If the eps/ai file contains mixed new-line char(mixture of CRLF/CR/LF), and B) if last byte of the eps/ai file is not new-line character, Thunderbird latest-trunk attached the eps/ai file(application/postscript) with BASE64 encoding. This is done by fix for bug 269390, as Mike says. - But C) if above A) or B) is not true, ie. single new-line char and last byte is the single new-line char, Thunderbird latest-trunk generated next headers, Content-Type: application/postscript; name="eps-x01-x1F-CRLF-only.eps" Content-Transfer-Encoding: 7bit Content-Disposition: inline; and put 0x01 to 0x1F data in mail data stream for the eps/ai file.

The test data contains following three lines. > This_is_0x01_to_0x1F_Data_CRLF_only[CRLF] > [Binary data of 0x01 to 0x1F excluding LF/CR][CRLF] > This_is_0x01_to_0x1F_Data_CRLF_only[CRLF] 1. Save this file as .eps or .ai file. 2. Delete all mails in Drafts folder, then compact Drafts folder. 2. Compose a mail and attatch the saved .eps or .ai file, and save in Drafts. 3. Shutdown Thunderbird. 4. See Drafts file content.