326303 - forward as attachment when mail.file_attach_binary=true sends unencoded headers with base64 body(message/rfc822 part)

Status: NEW

(MailNews Core :: Composition, defect)

Description

[David Finch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I had enabled mail.file_attach_binary to avoid another serious corruption bug, and encountered this bug instead.

Now, when I forward a message as an attachment, rather than encoding the entire message, it does something funny where it base64 encodes the body of the attachment, but leaves the header of the attached email. The recipient rightfully sees this attachment as corrupt, and is unable to view it.

Reproducible: Always

Steps to Reproduce:
1. Enable mail.file_attach_binary
2. Forward an email as attachment. Alternatively, you can compose a new message and attach the message to be forwarded, with the same results.
3. Try to read the attachment on the other end, or read it from your sent items.

Actual Results:  
Thunderbird and probably all other email clients show a blank attachment. "View source" verifies that the header of the attached message was not encoded.

Expected Results:  
The recipient should be able to read the attachment. The header and body of the attachment should have been encoded as a single unit, as is the case when attaching a file.

I had enabled mail.file_attach_binary because that appears to be the recommended workaround for a known (unpatched) bug where Thunderbird corrupts certain binary attachments, such as the occasional pdf file, because it sometimes misdetects them as plaintext. I'm using Thunderbird 1.5 (roughly. Specifically 20060118 from nightly/latest-mozilla1.8.0/).

Comment 1

[Mike Cowperthwaite]

Well, *that's* unfortunate.  Reproduced with TB 1.5 & 1.6a1-0203, 
Seamonkey 1.0, Mozilla 1.7.12, Win2K.

Comment 2

[Mike Cowperthwaite]

*** Bug 353311 has been marked as a duplicate of this bug. ***

Comment 4

[allyn fratkin]

I am seeing this exact problem in Tb 2.0.0.5 but I have mail.file_attach_binary set to false!  Is there any workaround for this?

Comment 5

[WADA:World Anti-bad-Duping Agency]

Adding message/rfc822 in summary for ease of search.

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
> I have mail.file_attach_binary set to false!  Is there any workaround for this?

As I wrote in Bug 291899 Comment #10, attachment data with mixed CR/LF is already improved(sent in Base64 instead of text) by Bug 269390. Then frequency of broken attachment (because binary data is sent as text instead of Base64) already becomes very low.
So mail.file_attach_binary is better to be kept as default(false).
And mail.file_attach_binary=true is to be used only for temporary bypass of broken attachment such as Bug 291899 Comment #11 case, in order to avoid this bug.

Comment 7

[allyn fratkin]

figured out that i'm seeing this problem because i am using cross-platform mailboxes.  mailbox is saved on linux with LF line endings.  thunderbird on windows expects CRLF so it decides message much be binary because of bare LF line endings.  so it uses base64 transfer encoding for the message/rfc822 part.  the problem is, it only encodes the body and leaves the headers unencoded (including the headers content-transfer-encoding: text/plain).

is there a way to force content-transfer-encoding to 7bit or 8bit for all message/rfc822 parts?  presumably a message in rfc822 format is already 7bit, right?

Comment 8

[Dan Wing]

I am also experiencing this bug, but only after I upgraded to Thunderbird 2.0.0.6 from 1.5.  I also have mail.file_attach_binary set to false (its default).

This is reproducible by setting up an ATOM-based RSS feed in Thunderbird and then Forward the blog's message to someone.  An example of a blog that causes this behavior is http://www.isen.com/blog/atom.xml.  I have several other ATOM-based RSS feeds that exhibit the same Thunderbird bug when you forward them.  Near as I can tell, none of my RSS-based RSS feeds exhibit this bug when you forward them.

I subscribed to these same blogs with Thunderbird 1.5, which did not exhibit this bug.

Comment 9

[WJCarpenter]

This is a bit of a "me, too" report for TB 2.0.0.9.  

As others have reported, TB is encoding the body of the attached message and not encoding the headers.  But it puts the "content-transfer-encoding: base64" into the MIME part headers and does not put it into the headers of the attached message.

I can also confirm that this behavior is triggered by something to do with line endings.  If I make sure every line has a CRLF, TB does not do the buggy behavior.

Comment 10

[WADA:World Anti-bad-Duping Agency]

(copy of bug 580017 comment #19)
> In case of "message/rfc822", base64 encoding is forbidden in RFC 2045.

http://tools.ietf.org/html/rfc2045#section-6.4
> 6.4. Interpretation and Use
>(snip)
>    Certain Content-Transfer-Encoding values may only be used on certain
>    media types.  In particular, it is EXPRESSLY FORBIDDEN to use any
>    encodings other than "7bit", "8bit", or "binary" with any composite
>    media type, i.e. one that recursively includes other Content-Type
>    fields.  Currently the only composite media types are "multipart" and
>    "message".  All encodings that are desired for bodies of type
>    multipart or message must be done at the innermost level, by encoding
>    the actual body that needs to be encoded.
>(snip)
>    NOTE ON ENCODING RESTRICTIONS:  Though the prohibition against using
>    content-transfer-encodings on composite body data may seem overly
>    restrictive, it is necessary to prevent nested encodings, in which
>    data are passed through an encoding algorithm multiple times, and
>    must be decoded multiple times in order to be properly viewed.
>    Nested encodings add considerable complexity to user agents:  Aside
>    from the obvious efficiency problems with such multiple encodings,
>    they can obscure the basic structure of a message.  In particular,
>    they can imply that several decoding operations are necessary simply
> 
>    to find out what types of bodies a message contains.  Banning nested
>    encodings may complicate the job of certain mail gateways, but this
>    seems less of a problem than the effect of nested encodings on user
>    agents.

Tb's behavior of "trying to send message/rfc822 part in Base64" is apparent mail RFC violation.

If it was also "EXPLICITLY FORBIDDEN" by explicit rule of RFC like syntax rule  in addition to EXPRESSLY FORBIDDEN in this section, I could say "Tb's RFC violation!" earlier...