Thunderbird sends attached .eps files with "Content-Transfer-Encoding: quoted-printable"



Message Compose Window
13 years ago
8 years ago


(Reporter: Marco Amrein, Assigned: Scott MacGregor)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



13 years ago
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

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

Comment 1

13 years ago
Created attachment 181031 [details]
An EPS file to reproduce the Bug.

Comment 2

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


Comment 3

13 years ago
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:
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.
Last Resolved: 12 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.