User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 The file is of an unknown type containing 16 K of ascii and than some binary. Mozilla incorrectly asumes that it is an ascii file and quoted printable encoding seems to fail. Reproducible: Always Steps to Reproduce: 1. compose a new mail 2. attach the file http://home.hccnet.nl/l.dogterom/test.file 3. send it to yourself 4. save the attachement 5. compare the attached file with the original. Actual Results: Files differ. Expected Results: Mozilla should not change my attachements Tested with Mozilla 1.3 and Mozilla 1.4 for Linux (Redhat 7.2) and Mozilla 1.3b for Irix

I believe you are stating that the filename is changed from test.file (what you send) to test.html (what you receive)? If so, then this is likely a duplicate of bug 163254. Please review bug 163254 and change the status back to unconfirmed if I am wrong! *** This bug has been marked as a duplicate of 163254 ***

Bug 215005 is not a duplicate of 163254. Bug 163254 deals with filename changes. The current bug deals with the content of an attachement.

Thanks for the clarification. A quick question: is corruption happening when the email is sent, or when it is received and the attachment saved? Could perhaps test this using another mail client to 'receive' the letter sent by Mozilla. (I will try this myself tonight at home, but don't have such tools at work).

I am quite sure that the message is corrupting while sending. Reading with netscape 4.79 gives the same problem. I think we are looking at two bugs here. 1) Mozilla detects that the file is in ascii while it is not. On a Windows system carridge return characters are added, corrupting this file even more. 2) The quoted printable encoding cannot handle this binary file properly Meanwile we have found two other bugs that might have the same cause. BUG 142517 BUG 185230 These cases where corrupted PDF files They were probably also wrongly diagnosed as ascii files

Ok. Tonight (If I get home in time) I'll check with my pine mail client -- I can view the headers, and see if the MIME type for the attachment is explicitly set to text/plain.

Ok. I did the following: 1) Right clicked on the link http://home.hccnet.nl/l.dogterom/test.file to upload the file to my desktop. File size on my WIndows 98 desktop is 16640 bytes and is saved with the filename test.file 2) Attached the file using Mozilla 1.4 mail and sent it to nyself (to an account on a UNIX box) 3) Viewed the mailbox file (to which the letter was mailed) on a UNIX (Sun Solaris) system. Attachment is of MIME content-type: text/plain, has name 'test.file", and is sent as Content-Transfer-Encoding: quoted-printable 4) Used Pine (v 4.21) to save the attachment. The saved attachment is named "test.file" and is of size 16640 bytes. 5) did a byte-by byte comparison of hte two files (original -- transferred up to the UNIX box using binary mode), and the one after sending it by mail) -- there was no difference. This seems to imply that the Mozilla mail client is detaching the attachment incorrectly = and that, somehow, NS 4.79 does the same incorrect thing.

Dear ian.graham, Thank you for the experiments you did concerning the mozilla/mail bug. We are however utterly confused by the results you got. The last remark seems to indicate that you can reproduce the error we have reported, but you never say so explicitly. So my question is: did you actually reproduce the error? After reading your remarks, we did the following experiments: a) send linux/mozilla; receive linux/mozilla -> 1 byte changed b) send linux/mozilla; receive linux/netscape -> 1 byte changed c) send linux/mozilla; receive linux/pine -> 1 byte changed d) send windows/mozilla; receive linux/mozilla -> 1 byte changed e) send windows/mozilla; receive windows/mozilla -> 578 bytes added f) send windows/mozilla; receive windows/outlook -> 578 bytes added g) send linux/netscape; receive linux/netscape -> 33 bytes changed h) send linux/netscape; receive linux/mozilla -> 33 bytes changed Conclusions: 1) mozilla changes one byte when attaching this file 2) netscape 4.79 changes 33 bytes when attaching this file (in auto-detect mode) 3) detaching this file on a windows platform goes very wrong (but this is defendable: the file should not have been identified as ASCII (text/plain) by mozilla when attaching)

I can confirm this bug at least on Mozilla/Win -> Mozilla/Win. Mozilla extends 0x0d and 0x0a line endings to 0x0d0a. I guess that's one half of the problem bug 168098 is about.

In response to comment #7 -- no, I was unable to reproduce the bug, as I was unable (with the mail account I was testing with) to 'save' the attachment with anyting other than Pine on UNIX. However, I made a mistake -- I too saw a 1-byte change between the original message, and the one sent from Windows and saved (by pine) onto UNIX. I assumed thiw was just an EOF marker difference. So it looks as if the bug in part is that the attachment -- when attached -- is marked as of type text/plain. Detaching on a given OS will then modify the file depending on the nature of line endings on that system. A good test might be to create three simple attachments (test-CR.file, test-LF.file, test-CRLF.file), each containing two lines: the first ending with a line ending (either CR, LF, or a CRLF pair), and the second ending with no line ending. I would do that, but don't have the tools at work to do so. Does that make sense?

I have seen this or a similar bug which affects pdf files. I can confirm that: - the file is changed in size and content, although not to what extent I have compared files saved via pine and via mozilla - the file can be saved from pine without error I use this technique to be able to read the pdf file when it is corrupted by Mozilla Mail - the error _seems_ to happen on files over a certain size and does not occur on smaller sections of the file. I tried to extract a small piece of the file to reproduce without success - the error has been occuring through several releases (1.2/1.3/1.4) - the error is present in this version of mozilla Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 - I don't know if it occurs on Windows platform - I don't have a test file since all the files I have that werer corrupted contain sensitive information. I suspect that creating a large pdf file with mixed graphics and text over 2MB in size will trigger the bug - but have not had time to try this. cheers Mark

Thanks Mark for your comments. I think you are very lucky that you can restore corrupted attachments by reading then with "pine". Here it does not work. It looks like changes in record terminators (=line endings) is the symptom of the problem. IMHO the basic cause of the problem is that the files are incorrectly identified as ASCII (=not binary). Mozilla should send all attachments as binary except when it is SURE the attachment is ASCII. My suggestion on how to identify ASCII files is the following: - The whole file should be checked. Not just the first 16 kB. Mixed ASCII/binary files do occur (I have seen them in .pdf and PostScript, but also in data from the "Envisat" satellite) - Mozilla should know what the default record terminator (from now: DRT) is in the underlying operating system. In my short life I have seen CR, LF, CRLF, binary zero. If a file contains any of these characters not being used as DRT, the file is definitely NOT ASCII. For example a CR character anywhere in a file on a UNIX system makes it a binary file. Agree?

I have had a further look at this and dragged out the details of a "successful" attachment and an "unsuccessful" attachment that are otherwise almost identical. Two parts of these emails are below and I can provide more of them is required. - Both use MS Internet Mail Service as X-Mailer - Both have essentially the same structure - Both use "application/octet-stream" - Both are saved correctly by Pine - One is saved correctly by Mozilla - One is Content-Transfer-Encoding: base64 (saves correctly) - One is Content-Transfer-Encoding: quoted-printable (fails to save correctly) Other than this both appear to be identical. I don't know whether this is the problem other people see with this bug, but this is the reason I searched bugzilla about corrupt attachments. I believe the Pine behaviour to be correct in this case and mozilla behaviour to be incorrect. cheers Mark Attachment that is Corrupted on Save: <snip> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2D248.CCE197D0" <snip> ------_=_NextPart_000_01C2D248.CCE197D0 Content-Type: application/octet-stream; name="Prophecy Networks Ltd. (EMEA.GL.ESP.07.01.02)02.07.03.pdf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Prophecy Networks Ltd. (EMEA.GL.ESP.07.01.02)02.07.03.pdf" %PDF-1.4=0D%=E2=E3=CF=D3 1256 0 obj=0D<< =0D/Linearized 1 =0D/O 1260 =0D/H [ 1816 578 ] =0D/L = 583753 =0D/E 88079 =0D/N 26 =0D/T 558513 =0D>> =0Dendobj=0D = xref=0D1256 37 =0D0000000016 = <snip> Attachment that is NOT Corrupted on Save: <snip> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C34419.69021080" <snip> ------_=_NextPart_000_01C34419.69021080 Content-Type: application/octet-stream; name="priceretailjul.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="priceretailjul.pdf" JVBERi0xLjMNJeLjz9MNCjE3NzQgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDE3NzcgDS9I IFsgMTk4OCAyMjAyIF0gDS9MIDEyOTY4NjIgDS9FIDE1MDc0NiANL04gMjQgDS9UIDEyNjEyNjIg <snip>

I think I just encountered this bug myself last night, sending Adobe Illustrator files as attachments using Mozilla 1.2.1. When the recipient said the files were corrupt, I tried saving the attachments from my copy of the message in the sent folder, and Illustrator said they were corrupt on my end, too. The original files that I dragged to the attachment pane were (and are) fine. The mime coding mozilla used was Content-Type: application/postscript; name="03 Summer LBDA back.ai" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="03 Summer LBDA back.ai" and Content-Type: application/postscript; name="03 Summer LBDA front.ai" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="03 Summer LBDA front.ai" I then attached the same two files to a message in Netscape 4.73, which sent them using base64 encoding. Saving the copy of the attachments from the sent message folder in Netscape 4.73, they opened without problem in Illustrator. The files in question were between 100k and 150k. I can provide them if it would be helpful. -brad levy blevy@compuserve.com

david, is this similar to the attachment corruption bug you are working on?

Dear Seth Spitzer, Are you discussing bug 168098? I have installed mozilla 2003082122, and my testfile still gets corrupted. So I do not think the problem has been solved.

Yes, Seth was talking about bug 168098. The patches mad there and in bug 89285 to, say weaken, the problem in general and fixes it for almost all real world cases. Why your test.file is still encoded as QP and thus gets corrupted is, that we've a ratio of 1/10 when testing if a file is binary or just text. So if there are less than 10% unprintable characters, we're not going to see it and binary. If you're rising the ratio by deleting the duplicate "Hello Marc," blocks, the test file will encode as base64. Please see bug 216817 for further work on this ratio thing problem and others.

Looks like a problem I've found when saving PDF attachments with Mozilla 1.7 Mail, under Linux. About 25% of the PDF files from a particular source - a proprietary newsletter - are corrupted. Usually several kb are deleted somewhere within the file. When I copy the mail file to a Windows partition & save using Mozilla 1.7 under Windows, the attachment is always saved correctly. The bug is reproducible for a given email message. A bug-fix would be VERY nice.

There may have been a fix to this problem with bug 269390. Since the test file in comment 0 is being served as text/plain, it is subject to cross-OS EOL transformations and so I can't test with it. There is another bugfix at bug 317009 that fixes another corruption commonly seen with PDFs (per comment 17), but that fix's problem didn't exist until quite some time after this bug was opened.

I don't know if it is useful, but I have attached my case. I can confirm the bug under Thunderbird 1.5 for windows, from 8 files (dxf drawings) sended only one gets unreadable by Autocad for Windows, and the md5 is different after saving it (I have not tested the md5 from the others, but Autocad opened them). Thank you developers.

This bug is still there with Thunderbird 2.0.0.0. As I work with DXF's almost everyday, this bug is a serious issue for me. I can send DXF's, but I can't forward them from an already created message. The attachment is corrupted. I'm offering up a $50 bug bounty for the fix of this bug. Fix it, get the fix into the released version, and I send the bug fixer or the Mozilla foundation $50. Anyone else want to offer up money on this one? -Jeff Albro

As an interim workaround, you could just use the config editor to set mail.file_attach_binary to true, so all your attachments are sent as binary, base64 encoded.

Good idea David, but it didn't completely fix the problem. I sent a DXF to myself, and it both arrived in my inbox and was copied to my sent folder with the dxf inline after message, and attached with a "text icon" associated with it. However, the DXF attachment did load in both cases. I re-forwarded the sent-folder version back to myself, and again, the DXF was inline after the message, and the file was attached with a "text icon" but the file did work. So, for me, the file doesn't seem to get corrupted, but it does appear inline improperly, and shows an improper "text icon" for the attachment. I've still had other users complain of corrupted DXF files mailed sent from this version of Thunderbird. -Jeff

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

This bug still exists in 2.0.0.4. Can somebody please fix it? -Jeff

do you know if there are similar reports in support forums?

WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091215 Shredder/3.0.1pre please comment whether you agree or disagree