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)

x86
Linux
defect
Not set
normal

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.
what versions of TB have you tried? I think someone submitted a patch to encode attachments that didn't have "correct" line endings...
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.
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.
resolving as a dup - again, this is fixed in 2.0.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Very well, thanks. It was my understanding that the proposed patch only fixed the issue for files having mixed line endings.
maybe you're right - I'd have to go look.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(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.
Assignee: mscott → nobody
do you still see this now that bug 269390  is fixed? 
Or are this and open Bug 161806 still valid
Closing Incomplete for lack of answers.

Feel free to reopen if you can provide more information.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.