449022 - Forward As Attachment results in envelope being corrupted

Status: RESOLVED INCOMPLETE

(Thunderbird :: Message Compose Window, defect)

Description

[Andrew Brady]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Thunderbird version 2.0.0.16 (20080707)

Tested under Linux (version 2.0.0.16 (20080707)) and under Windows/XP (version 2.0.0.14 (20080421)) and I feel I must be missing something really stupid.

My underlying mail server is Courier imap and using Postfix for SMTP. Theoretically is could also be one of these at fault.

When an email with an attachment is received and that email is forwarded as an attachment, the resulting email that is delivered has an attachment that can
be opened but is slightly corrupted so cannot be opened as a complete email
that is comparable to the original email. The end result is that the original attachment cannot be opened from the attached email.

See my steps to reproduce.

The reason for the problem is that a CR char is added to the top of the attached <subject>.eml.

Strangely, the copy that is stored in the Sent folder when forwarding does not have the CR so the attachment opens ok in the Senders browser.

The workaround for me is not to send emails as attachments.

An existing email can be fixed by editing out the extra CR in the raw email on on the imap mail server directly but this is not something I can advise my
users.

An example snippet with the three CR in a row from an email is below:

  --------------000801010301030708080508
  Content-Type: message/rfc822;
   name="test.eml"
  Content-Transfer-Encoding: 7bit
  Content-Disposition: inline;
   filename="test.eml"


  From [e-mail]  Mon Aug  4 12:01:19 2008
  Return-Path: <[e-mail]>
  X-Original-To: [e-mail]
  Delivered-To: [e-mail]
  ...etc

I will attach four emails:

  1_sent.eml - OK   - Original email I sent to myself with testdoc.pdf attached.
  2_rcvd.eml - OK   - Original email I receieved.
  3_sent.eml - OK   - Forwarded email stored in my Sent.
  4_rcvd.eml - FAIL - Forwarded email I received.

The differences between 3 and 4 are that the MTA adds additional headers
which is ok but there is an extra CR in 4 causing the problem and another
tailing CR which is removed that doesn't make any difference.

% diff -c 3_sent.eml  4_rcvd.eml
*** 3_sent.eml  2008-08-04 14:01:14.110258000 +0100
--- 4_rcvd.eml  2008-08-04 14:01:14.160258000 +0100
***************
*** 1,3 ****
--- 1,10 ----
+ From [e-mail]  Mon Aug  4 12:55:51 2008
+ Return-Path: <[e-mail]>
+ X-Original-To: [e-mail]
+ Delivered-To: [e-mail]
+ Received: from [136.156.126.139] (bragi [136.156.126.139])
+       by hamail.ecmwf.int (Postfix) with ESMTP id 7F551FA
+       for <[e-mail]>; Mon,  4 Aug 2008 12:55:51 +0000 (GMT)
  Message-ID: <[e-mail]>
  Date: Mon, 04 Aug 2008 13:55:51 +0100
  From: Andrew Brady <[e-mail]>
***************
*** 26,31 ****
--- 33,39 ----
  Content-Disposition: inline;
   filename="test.eml"

+
  From [e-mail]  Mon Aug  4 12:55:05 2008
  Return-Path: <[e-mail]>
  X-Original-To: [e-mail]
***************
*** 146,149 ****
  --------------080901030502000003050107--

  --------------010702090105030302020002--
-
--- 154,156 ----

Cheers,

Andy

Reproducible: Always

Steps to Reproduce:
1. Send an email to yourself with a pdf attached.
2. Forward the received email *as an attachment* to yourself again.
3. The email you receive will have an attachment <subject>.eml.
4. Click on the attached <subject>.eml.
5. The attachment is one big lump of text and the pdf cannot be read.
Actual Results:  
Attached email is corrupted and the original attached document cannot
be opened.

Expected Results:  
The attached email should have been opened and presented itself as an
email with an attachment that itself could be opened.

Comment 1

[Andrew Brady]

Attachment: Orginal email sent with testdoc.pdf attached.

Comment 2

[Andrew Brady]

Attachment: Original email received.

Comment 3

[Andrew Brady]

Attachment: Forwarded as attachment the original email - Copy in Sent

Comment 4

[Andrew Brady]

Attachment: The email I received which is corrupted so the original attachement cannot be viewed.

Comment 5

[WADA:World Anti-bad-Duping Agency]

I can't see stand alone CR(0x0D) in your mail files. All lines are terminated with single LF(0x0A) in your mail file. So I assume problem when excess stand alone LFs at top of mail data in message/rfc822 part.

(1) Following is your mail data of Comment #4. (0x0A is written as [LF])
>      --------------010702090105030302020002[LF]
>      Content-Type: message/rfc822; name="test.eml"[LF]
>      Content-Transfer-Encoding: 7bit[LF]
>      Content-Disposition: inline; filename="test.eml"[LF]
>      [LF] <== splitter of header potion and data portion of this part
>   A  [LF] (as you say, this excess [LF] is not found in mail of Comment #3)
> D |  From [e-mail]  Mon Aug  4 12:55:05 2008[LF]
> A |  Return-Path: <[e-mail]>[LF]
> T |  X-Original-To: [e-mail][LF]
> A |  Delivered-To: [e-mail][LF]
>   |  (snip)
(2) Because message/rfc822 part, the data is also a mail.
> [LF] <== splitter of mail header potion and mail payload portion of this mail
> From [e-mail]  Mon Aug  4 12:55:05 2008[LF]
> Return-Path: <[e-mail]>[LF]
> (snip)
This mail has no mail header. i.e. no Content-Type: header.

Above phenomenon of excess new-line character(s) is sometimes reported to bugzilla.mozilla.org. In some cases, filter/scanner etc. at server inserted it.

Tb has problems in incorrect mail header handling. AFAIR, problem exists in both (a) no Content-Type: header case(your case) and (b) no mime-type parameter in Content-Type: header case.
This is DUP of a bug, but I can't recall bug number.

In additon to above, top line of your received mail is always as follows.
(then top line of mail data in message/rfc822 part too)
> From [e-mail]  Mon Aug  4 12:55:51 2008
It's not legal mail header. It's format is "mail separator of Unix Mbox file".
It may produce following problem(This is also an already reported problem).
 - If the mail is copied to local mail folder from IMAP folder,
   the "From ..." line is escaped by ">From ..." because Tb uses Unix Mbox.
 - When this local copy is copied back to a IMAP folder,
   Courier IMAP rejects it because it's incorrect mail header.

Is your set up of Courier IMAP server correct?

Comment 6

[Wayne Mery (:wsmwk)]

Andrew, can you relpy to comment 5?
Does this bug belong in attachments or mime component?

Comment 7

[Wayne Mery (:wsmwk)]

does this still reproduce?

Comment 8

[Thomas D. (:thomas8)]

no reply from reporter - just wasting our time

otherwise, problems covered per WADA's comment 5 (existing bugs)