User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Thunderbird 1.0.2 on Windows sends my .eps with "Content-Transfer-Encoding: quoted-printable" which usually renders them useless for the recipient due to CR/LF conversions. Thunderbird should be configured to encode them by default as base64. Reproducible: Always Steps to Reproduce: 1.Get hold of an .eps file (I will attach one) that consists 98% of ascii-chars. 2.Send it with Thunderbird 1.0.2 on Windows as an Attachment. 3.Try to save the Attachment with another Thunderbird 1.0.2 on Windows. Actual Results: Thunderbird uses: Content-Transfer-Encoding: quoted-printable The saved eps file is corrupted due to some CR/LF conversion and is not byte identical to the original file anymore. Applications refuse to work with the corrupted EPS file. Expected Results: Thunderbird should use Content-Transfer-Encoding: base64

Altho it may not seem obvious, this is probably a dupe of bug 176258.

I think bug 176258 should be treated separately, until more evidence proves that 176258's increase of exacty 1 byte can be tracked to the same roots as this issue. When I looked at the binary differences of this eps files, I found out, that Thunderbird is doing a LF->CR+LF conversion for every single line (increasing the size of the eps by 100's of bytes), which is quite understandable and natural, when using quoted-printable encoding for sending such pseudo-ascii content. I would file a bug against thunderbird if it would not do this conversion for true text/* type attachments. But for application/postscript quoted-printable encoding (and the therefore caused very MUA/MTA/MDA dependent handling of EOL characters) is just inappropriate.) I don't know if the suggested fix would re (In reply to comment #2) > Altho it may not seem obvious, this is probably a dupe of bug 176258. > >

Bug 291899 and Bug 291749 are Content-Transfer-Encoding:7bit(or 8bit, depends on data) case when 0x00 is included in ".eps" file on Japanese MS Windows. - Bug 291899 : When Tb 1.0.2 - Bug 291749 : When Mozilla Suite trunk nightly I think similar problem will occur on Tb 1.1, will be much worse than Tb 1.0.x. See Bug 195613. Developers said "PDF is binary, PostScript is ASCII" in 2003. Current implementation seems to be based on ".ps"(application/postscript, PostScript Level 1), instead of ".eps or .ai"(also application/postscript, PostScript Level 2 or higher). I believe that PostScript should also be considered to be binary like PDF. I also think all of this bug and Bug 291899 and Bug 176258 will be resolved by sending "application/postscript" data with "Content-Transfer-Encoding: Base64". (Receiving of application/postscript of Quoted-Printable is different problem.)

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.