Closed Bug 291749 Opened 19 years ago Closed 19 years ago

Mail attachment of ".eps"(application/postscript) is corrupted(Mozilla-trunk only. "7bit" even when 8-bit exists, Attachemnts are broken when 0x00 exists in data)

Categories

(MailNews Core :: Attachments, defect)

x86
Windows 2000
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 243199

People

(Reporter: World, Assigned: sspitzer)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050424
(latest-trunk 2005042405 build, Win-2K)

Even when ".eps"(application/postscript) file contains 8bit data or lower than
0x1F,  Mozilla Mail&News generates "Content-Transfer-Encoding: 7bit".
Data in the mail part becomes same as contents in original file, except
LF(0x0A)/CR(0x0D)/Null(0x00).
 - LF and CR is removed(same as CR+LF).
 - When Null(0x00) is contained, no further data is placed in draft of mail.

This is Mozilla only problem.
Thunderbird latest nightly(and 1.0.2 release build also) generates,
 - When 7bit chars only (within 0x20 to 0x7E and CR/LF)
   "Content-Transfer-Encoding: 7bit", and data is as is.
 - When 8bit data is included (within 0x20 to 0x7E and CR/LF, and 0x82, 0xA0)
   "Content-Transfer-Encoding: 8bit", and data is as is.
 - When lower than 0x1F is 8bit data only (all of 0x00 to 0xFF contained)
   "Content-Transfer-Encoding: Base64" and data is properly encoded.

This problem doesn't occur if file extention is changed to
".pdf"(apllication/pdf) on both Mozilla mailnew and Thunderbird.
 - Always content-Transfer-Encoding: Base64, and data is properly encoded,
   including CR and LF.

Tested data is not a real EPS data, but this may occur on real EPS data, and
this  maybe causes send error or imcomplete attachment data.
(This is result of intentional test for problem analysis which was reported to
Japanese BBS, mail send error when EPS attachment.)
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
 Drafts-Tb-4-22.txt   : Mail data created by Thundebird
Summary: Mail attachment of ".eps"(application/postscript) is currupted (Mozilla mai&news only) → Mail attachment of ".eps"(application/postscript) is corrupted (Mozilla mai&news only)
Correction on problem description.

Thunderbird also can have problem.
If ".eps" contains 0x00, Thunderbird encoded it with Base64(bynary mode).
But if 0x00 is not included, all 0x01 to 0x1F, exclusing 0x0A(LF) and 0x0D(CR),
were placed as-is, with Content-Transfer-Encoding 7bit or 8bit.
This maybe causes sending error if EPS contains binary data.

I think considering application/postscript as binary is best way, like
PDF(application/pdf).
I also think "always binary" will resolve problems due to changing "CR/LF/CR+LF"
when psotscript file.
Summary: Mail attachment of ".eps"(application/postscript) is corrupted (Mozilla mai&news only) → Mail attachment of ".eps"(application/postscript) is corrupted
Problem in comment #2(Thunderbird case, current design I think) is
independent/different from this bug's problem(probably regression on Mozilla),
although the "always binary" can resolve both problem at once.
Dupe of bug 290804?
(In reply to comment #4)
> Dupe of bug 290804?
No.
Problem of comment #0(this bug's problem) is completely different problem.
 (1) '7bit' is always set in Content-Transfer-Encoding.
     Even when 0x80 to 0xFF are included in data, "7bit" was set.
 (2) 0x01 to 0x1F(exclusing 0x0A and0x0D) are written as-is.
 (3) If data contains 0x00, attachment data is cut at 0x00.
     Further, all other attachemnt data are lost(not written in draft)
     if they are attached after the attachemnt who contains 0x00.
This is Mozilla trunk only problem(I haven't tested on 1.7.x yet), and behaviour
is completely different from Thunderbird.
I think this is a regression.

But issues in comment #1/comment #2 contains problem of bug 290804. 

First issue in comment #1/comnet #2 is;
 - 0x01 to 0x1F(excluding 0x0A and 0x0D) are written in Draft.
This can not occur when Quoted-Printable is forced.
But in my test, 0x01 to 0x1F was written even when "Content-Transfer-Encoding:
7bit or 8bit".

Second issue in comment #1/comment #2 is problem such as bug 290804 -
lost/modified LF or CR.
(Quoted-Printable was not generated in my test. I think it depends on user's
preference setting.)
(In reply to comment #5)
> (In reply to comment #4)
> > Dupe of bug 290804?
> No.
> Problem of comment #0(this bug's problem) is completely different problem.
>  (1) '7bit' is always set in Content-Transfer-Encoding.
>      Even when 0x80 to 0xFF are included in data, "7bit" was set.

But isn't the real problem that Content-Transfer-Encoding is *not* Base64?
As far as I can tell, that's the only way to ensure precise byte-level copying.
(In reply to comment #6)
> > Problem of comment #0(this bug's problem) is completely different problem.
> >  (1) '7bit' is always set in Content-Transfer-Encoding.
> >      Even when 0x80 to 0xFF are included in data, "7bit" was set.
> 
> But isn't the real problem that Content-Transfer-Encoding is *not* Base64?

Thunderbird DID set "8bit" in this case.
This indicates something wrong in Mozilla trunk.
This bug(comment #0) is :
 Mozilla trunk have to generate at least same data as Thunderbird generated.
See test results in attachment 181733 [details].

> As far as I can tell, that's the only way to ensure precise byte-level copying.
I think so too.
Therefore, I say that "Considering application/postscript as binary" is required.
See Bug 195613.
"PDF file is ASCII" was corrected, then developers said "PDF file is binary" in
2003, but developers said "PostScript file is ASCII" in 2003...
Additonal information.
My test result was when following option was "Unchecked".
   Preference/Mail&Newsgroups/Composition
   - For message that contain 8-bit characters,
     use 'quoted printable" MIME encoding.
Test result is same even when this option is "Checked" ;
 eps-8bit.eps & eps-x01-xFF.eps were attached as-is with "7bit".
This case(quoted-pintale when 8-bit chars) is not tested on Thunderbird yet,
because no UI for this option(except "config editor").
Modifying summary for clarify the bug.
Summary: Mail attachment of ".eps"(application/postscript) is corrupted → Mail attachment of ".eps"(application/postscript) is corrupted(Mozilla-trunk only. "7bit" even when 8-bit exists, Attachemnts are broken when 0x00 exists in data)
I've opened separated Bug 291899 for comment #2 / comment #3 issue, to clarify
problems.
Mike, could you comment to it?
Depends on: 291899
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/
Tested again with Seamonkey/nightly/latest-trunk 2005092606 build(Win-2K).
Problem was not re-created.
Result was same as Thunderbird case written in comment #2.
Regression in Mozilla Mail&News looks to be cleared by change to Seamonkey...

Closing as WORKSFORME.
Thanks for notification by "auto-resolve".
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
This was DUP of Bug 243199.
But Bug 243199 has produced Bug 317009... Sigh...

Re-open to close as DUP of Bug 243199.  
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Creation of 0x00 data part is WORKSFORME, but corruption part when 0x00 data on viewing(viewing draft mail in this bug) is Bug 243199.

*** This bug has been marked as a duplicate of 243199 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: