text attachments have corrupted line endings due to 7bit encoding



11 years ago
9 years ago


(Reporter: Laurent Birtz, Unassigned)


Firefox Tracking Flags

(Not tracked)




11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060615 Firefox/
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060615 Firefox/

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:

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;



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

11 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

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

Comment 3

11 years ago
I am using version 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

11 years ago
resolving as a dup - again, this is fixed in 2.0.
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 269390

Comment 5

11 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

11 years ago
maybe you're right - I'd have to go look.
Resolution: DUPLICATE → ---

Comment 7

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


10 years ago
Assignee: mscott → nobody

Comment 8

9 years ago
do you still see this now that bug 269390  is fixed? 
Or are this and open Bug 161806 still valid

Comment 9

9 years ago
Closing Incomplete for lack of answers.

Feel free to reopen if you can provide more information.
Last Resolved: 11 years ago9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.