153557 - Large text attachements are wrapped

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Alexander Skwar]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.0rc2) Gecko/00200205
BuildID:    200200205

Large text attachments with no linefeed are wrapped after a certain number of
characters.

Reproducible: Always
Steps to Reproduce:
1. Compose a new mail
2. Attach a text file which doesn't contain any line wraps (like the attachment
to this bug)
3. Send mail

Actual Results:  In the received mail, the text from the attachment has \n's
added after a certain number of characters.

Expected Results:  Mozilla should leave attachements alone and not add any
superflous line wraps.

A friend of mine told me, that this problem does not only happen with the latest
releases, but also with older releases on various platforms.

Comment 1

[Alexander Skwar]

Attachment: Textfile without line wraps

After attaching this text file to a mail and sending it, the textfile has line
wraps added.

Comment 2

[Alexander Skwar]

Any ideas about why this is happening?

Comment 3

[Christian Frommeyer]

WFM
with Mozilla 1.1 on Linux I had no Problems sending and receving the file.
there are no line-wraps in the file

Comment 4

[Alexander Skwar]

Still doesn't WFM with 20030106 on XP.

I've sent me a mail with the file http://message-center.info/stuff/textdatei
attached.  When I received it in Lotus Notes, I could see that there were quite
a lot of line breaks.  And trying to save the file from Mozilla resulted in a
32kb file being created.

Comment 5

[Frank Wein [:mcsmurf]]

Reporter: Do you still see this problem with a current Mozilla build?

Comment 6

[Alexander Skwar]

Yes, still broken with Thunderbird 0.5 on Linux. But I suppose it'll also break
on Windows.

Comment 7

[Alexander Skwar]

Attachment: Another text file without line breaks

This file has exactly 1.000.000 (1 Million) times the letter 'a', if unpacked
with bunzip2/bzip2. Thus, the file is also exactly 1000000 bytes big.

If I attach the file and then save the attachment (after having received it),
it is bigger and has line breaks. I sent the bunzip2'd version of this
attachment here in the bug report.

Comment 8

[Micha³ Piaskowski]

Works for me with Mozilla 2004110705 on Windows XP

Does anybody still have this problem with recent version of Mozilla?

Comment 9

[Alexander Skwar]

Still broken with

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041104
Thunderbird/0.9 Mnenhy/0.6.0.104

Comment 10

[Alexander Skwar]

Attachment: Another attachment showing the behaviour

Also broken with Thunderbird 0.9 on Windows and with
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-11-08-06-trunk/mozilla-win32-installer.exe
(also on Windows).

For a test, save the attachment, unzip it and attach it to a message, send the
message, save the attachment from the sent message - and compare the md5sum!
The original attachment has:

[23:29:11 alexander@server:~/tmp] $ md5sum ultra-lange-zeile.txt
38f5db85871161d260b7f71bddb80282  ultra-lange-zeile.txt

Any md5sum that differs from this is broken.

Comment 11

[Gervase Markham [:gerv]]

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/

Comment 12

[Alexander Skwar]

Attachment: Wrapped file "1000000_mal_a.txt" (attachment #145771 : Another text file without line breaks)

The bug is still present in Thundebird 1.0.6. To confirm, I sent myself the
file 
"1000000_mal_a.txt" from attachment #145771 [details] : "Another text file without line
breaks". The attached file in this bug is the result as I find it in my sent
folder. The original file had 1 line with 1,000,000 "a" on the line. The
received file (or rather the stored file - but received == stored) has 97
lines.

Thus, the file has been broken.

Comment 13

[Alexander Skwar]

To get some attention, I'll ask for blocking. It would be nice, if somebody
could confirm this bug. 

Comment 14

[Scott MacGregor]

please don't abuse the flags.

Comment 15

[Alexander Skwar]

(In reply to comment #14)
> please don't abuse the flags.

Despite what I wrote in comment #13, I honestly think that this IS a blocker.

Also, could you please confirm this bug? The testcase is really easy:

- Download attachment #145771 [details]
- bunzip2 the file - it will create a file of 1,000,000 bytes, containing as
many "a"
- Write a mail to somebody (like yourself) and attach the file
- Compare the received attachment and the original attachment

Comment 16

[Micha³ Piaskowski]

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
Gecko/20050927.

I also reproduced this bug in Thunderbird version 1.0.7 (20050927)

Comment 17

[Mike Cowperthwaite]

Using the file from attachment 165200 [details], I was able to reprduce this as well.
The line breaks are introduced after every 10239'th character -- in otherwords, 
each line is maximally 10K (10x1024) including the \n that gets included.

The easy way to get around this is to set the preference
  mail.file_attach_binary
to True; then all attachments are sent as BASE64.  Therefore, this bug is *not* 
critical; the workaround is simple.

Another potential workaround at bug 237118 comment 3 fails for this file because 
the text is so long -- unfortunate, since sending q-p would be much more 
efficient for this particular file.

There really is no good reason to be sending such files in the clear; it is only 
"plain text" by the fact that is contains printable ASCII, it is in no way 
usefully readable by a human; I wouldn't send such a file without zipping it up.

This attachment cannot be sent byte-for-byte as it exists, simply due to line-
length limitations by SMTP.  The only reasonable fix to send it "plain" is to 
convert it into some form of Content-Transfer-Encoding, such as quoted-printable 
or BASE64 (or, even better, built-in GZIP compression).

See also bug 193599, bug 235319, bug 12865.

Comment 18

[Alexander Skwar]

(In reply to comment #17)

> each line is maximally 10K (10x1024) including the \n that gets included.

Ah, so THAT is where it breaks. Good spotting!

> The easy way to get around this is to set the preference
>   mail.file_attach_binary
> to True; then all attachments are sent as BASE64.  Therefore, this bug is *not* 
> critical; the workaround is simple.

Well, you're right - as long as you know about this pref, which I did not :)
Thanks for the hint!

> There really is no good reason to be sending such files in the clear;

There is. That bug started WAY BACK then, because a friend told me, that they
couldn't use Mozilla, because they *regularly* send large text/plain attachments
with no line breaks. Those text files are then interpreted by some program.

Granted, the files don't conain lines of 1,000,000 letters/line :)

> it is only 
> "plain text" by the fact that is contains printable ASCII, it is in no way 
> usefully readable by a human;

That's right.

> I wouldn't send such a file without zipping it up.

Fine. I would send them this way, as it makes it easier for the recipient - and
if I'm sending stuff to customers, I want it to be easier for them; maybe they
even REQUIRE it that way. If the system is properly setup, he can simply double
click it and have the attachment be opened in the correct application. If we're
talking about files of only, let's say, 25k, bandwidth really is no issue here. 

> This attachment cannot be sent byte-for-byte as it exists, simply due to line-
> length limitations by SMTP.  The only reasonable fix to send it "plain" is to 
> convert it into some form of Content-Transfer-Encoding, such as quoted-printable 
> or BASE64 

That's right. The current behaviour actually makes the mail unsendable, it
seems. At least I don't receive the mail, when I send the 

FTR: Evolution base64 encodes that attachment, mutt and kmail use qp.

> See also bug 193599, bug 235319, bug 12865.

Will do.

Comment 19

[Mike Cowperthwaite]

TB 1.6a1-1022: this bug is now fixed on the trunk, thanks to the patch for 
bug 269390.  The long attachment is converted to base64 automatically.