Closed
Bug 363989
Opened 18 years ago
Closed 15 years ago
text attachments have corrupted line endings due to 7bit encoding
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: seerdecker, Unassigned)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060615 Firefox/1.5.0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060615 Firefox/1.5.0.4 Thunderbird corrupts text attachments by transferring them using the 7bit encoding without first validating that all line endings of the attachments are exactly '\r\n'. Consider this MIME part: --------------080109020404030701080500 Content-Type: text/plain; name="rn.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rn.txt" hello world --------------080109020404030701080500-- The RFCs require that all line endings in a MIME message be exactly '\r\n'. Thus, the MIME part above is generated by Thunderbird in the two following cases: 1) rn.txt: hello\r\nworld\r\n 2) rn.txt: hello\nworld\n In summary, Thunderbird makes a lossy conversion of text attachments. The correct behavior would be to use an encoding that preserves the newlines inside text attachments. In the TB extension I am doing neither setting the preference 'mail.inline_attachments' to false or setting 'gMsgCompose.msgCompFields.uuEncodeAttachments = true;' in Javascript has any effect on this issue. Since my extension verifies the attachments integrity using hashes, this is quite problematic. If the bug above cannot easily be fixed, I would like to have an option in TB that allows the user/programmer to choose the encoding of attachments. Reproducible: Always Steps to Reproduce: 1. Send a mail with a text attachment containing \r\n. 2. Save the received attachment to disk. 3. Notice that the file has been modified.
Comment 1•18 years ago
|
||
what versions of TB have you tried? I think someone submitted a patch to encode attachments that didn't have "correct" line endings...
Comment 2•18 years ago
|
||
If the line ends of the original file are not consistent -- some lines end with one form of line break, some with another -- then bug 269390 does address the problem, and its patch will be in TB 2.0. If all the lines of the original file end the same way, it is my contention that there is no loss involved. It is seldom important when \n converts to \r\n; when you save the attachment, the line-endings used will be the ones appropriate to your local filesystem. If those endings are not what you want, then it is possible to restore the endings to desired form, programmatically (which is not true of "lossy" transformations). If it's critical for your application that line-ends be bytewise preserved, then you should zip the attachment first and send the zip.
Reporter | ||
Comment 3•18 years ago
|
||
I am using version 1.5.0.8 of Thunderbird. I disagree about the corruption not being important; when I email a file, I expect it to be sent as-is. It is not possible for the receiver to restore the correct line endings programmatically since he has no way of knowing what were the original line endings -- it is a lossy conversion. In my extension I simply change the mime-content of the attachment to "application/octet-stream" to force Thunderbird to respect the line endings. It is a less than satisfactory solution.
Comment 4•18 years ago
|
||
resolving as a dup - again, this is fixed in 2.0.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 5•18 years ago
|
||
Very well, thanks. It was my understanding that the proposed patch only fixed the issue for files having mixed line endings.
Comment 6•18 years ago
|
||
maybe you're right - I'd have to go look.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 7•18 years ago
|
||
(In reply to comment #5) > Very well, thanks. It was my understanding that the proposed patch only fixed > the issue for files having mixed line endings. Yes, my patch does not preserve the (platform dependent) text file format. A more appropriate dup may be Bug 161806.
Updated•16 years ago
|
Assignee: mscott → nobody
Comment 8•16 years ago
|
||
do you still see this now that bug 269390 is fixed? Or are this and open Bug 161806 still valid
Comment 9•15 years ago
|
||
Closing Incomplete for lack of answers. Feel free to reopen if you can provide more information.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 15 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•