16393 - [DOGFOOD] Problem saving an attachement sent from one platform to another

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[Scott MacGregor]

I made a patch on my windows machine and sent it to myself as an attachement. I
then downloaded the message on my linux box and saved the attachement to a file.

There's a problem with line endings when saving the attachement on a platform
different than the platform the attachement was sent from. When I opened up the
file in emacs on my linux machine, it was filld with ^M characters at the end of
every line. I was unable to then apply this patch on my linux machine.

I do this same technique all the time on 4.x without a problem.

I'm nominating this bug for dogfood status. We need to properly receive and save
attachements that were sent from platforms other than the receiver's platform. I
know I do this a lot.

Comment 1

[Scott MacGregor]

I tried one experiment. I saved the message to disk from 4.7 on my Linux box.
And the ^M characters were still there. So the problem probably lies on the
sending end. Either in the code that bundles up the attachment or maybe in my
smtp code when I send the file.

Comment 2

[jefft]

I guess this bug should be depended on what kind of file the user is attaching.
In general we shouldn't try to munge the content of an attachment. However, if
we do know that the file being attached is definitely a text file (e.g. .txt
file on windows [on the other hand, an extension can fool you], or on a mac that
the resouce fork indicate that the file is a text file) then we could try to be
smart to convert the text file into a platform specific text file.

Comment 3

[leger]

Putting on [PDT+] radar.

Comment 4

[jefft]

I don't think this is a valid bug. If the attachment has the proper file
extensions (aka, .txt) then the line ending is converted correctly. If the file
extension is something other than .txt then the attachment is encoded into
base64 encoding which we won't try to convert to proper platform line endings.
Sorry, mscott. Marking it as invalid.

Comment 5

[Scott MacGregor]

I guess I tend to disagree. =) This functionality works on 4.7 today and I use
it all the time. I'm not sure why it is invalid to say 5.0 won't perform the
same way.

I should be able to make a diff as a text file and send it from windows and
receive it on linux.

That isn't the case today. The line endings are not correct when I download the
attachement on my linux box. I think it's a problem with how the attachement is
sent because I can download and save the attachment using 4.7 on the same
message and the problem is still there.

If the message is sent from 4.7 it always works. If the message is sent from
5.0, it always fails when I try to receive the msg on either 5.0 or 4.7.

I'd like to re-open this and hopefully we can talk through it some more.

Comment 6

[pmock]

Would it matter if the helper application was working?  I notice on 4.7 Win32
build that it list a helper application for "Plain Text" set to be handled by
Navigator.

Comment 7

[pmock]

clearing resolution

Comment 8

[jefft]

Okay, this definitely a send problem. Somehow, the process of sending a message
need to detect whether the attachment is a text file or not (check the file
content to see if its a pure ascii file) and then set the correct content type
when snarfing the attachment. Reassign to rhp for further investigation.

Return-Path: <>
Received: from [208.12.40.151] ([208.12.40.151]) by
          dredd.mcom.com (Netscape Messaging Server 4.1 Aug  9 1999
          18:28:31) with SMTP id FK87C300.JIF for <[e-mail]>;
          Tue, 26 Oct 1999 12:55:15 -0700
Message-ID: <[e-mail]>
Date: Tue, 26 Oct 1999 12:55:08 -0700
From: QA Test 21 <[e-mail]>
User-Agent: Mozilla 5.0 [en-US] (Linux; I)
X-Accept-Language: en
MIME-Version: 1.0
To: peter mock test account2 <[e-mail]>
Subject: test
Content-Type: multipart/mixed;
 boundary="------------050203020200070508080403"

This is a multi-part message in MIME format.
--------------050203020200070508080403
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

teste
--------------050203020200070508080403
Content-Type: application/octet-stream;
 name="unixtext_file"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="unixtext_file"

SW5kZXg6IG5zTWVzc2VuZ2VyLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3Zzcm9v
dC9tb3ppbGxhL21haWxuZXdzL2Jhc2Uvc3JjL25zTWVzc2VuZ2VyLmNwcCx2CnJldHJpZXZp

versus

Return-Path: <[e-mail]>
Received: from netscape.com ([208.12.40.99]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FK887S00.4SG for <[e-mail]>; Tue, 26 Oct 1999
          13:14:16 -0700
Sender: [e-mail] (Jeff Tsai)
Message-ID: <[e-mail]>
Date: Tue, 26 Oct 1999 13:14:15 -0700
From: Jeff Tsai <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-22 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: test unixtext_file
Content-Type: multipart/mixed;
 boundary="------------765728FC37368C204025CA47"

This is a multi-part message in MIME format.
--------------765728FC37368C204025CA47
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
test unixtext_file</html>

--------------765728FC37368C204025CA47
Content-Type: text/plain; charset=us-ascii;
 name="README"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="README"

==============================================================================
                          Netscape 4.7 (X11)
==============================================================================
                **********************************************
                IMPORTANT!  Before going any further, please
                read and accept the terms in the file LICENSE.
                **********************************************

Comment 9

[rhp (gone)]

I have this fixed in my tree. Will checkin later today.

- rhp

Comment 10

[rhp (gone)]

Just checked in this problem...it was a send side problem where we weren't
detecting unknown files..now we are.

- rhp

Comment 11

[pmock]

Verified as fixed on pop and imap.  I was using a .cpp file as my test file. The
builds that I used were:
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-11-10-17-M11/bac
kup/install.exe
ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-11-11-11-M11/netscap
e5-mac-M11.sea.bin
ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/1999-11-10-17-
M11/netscape-i686-pc-linux-gnu.tar.gz

Comment 12

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/5f490c058e55
[fenix] For https://github.com/mozilla-mobile/fenix/issues/16393: Don't show divider above general category when not signed in