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.

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

Any ideas about why this is happening?

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

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.

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

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

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.

Works for me with Mozilla 2004110705 on Windows XP Does anybody still have this problem with recent version of Mozilla?

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

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.

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/

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.

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

please don't abuse the flags.

(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

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)

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.

(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.

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.