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.

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.

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.

Putting on [PDT+] radar.

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.

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.

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.

clearing resolution

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 <qatest21@netscape.com>; Tue, 26 Oct 1999 12:55:15 -0700 Message-ID: <3816071C.3030704@netscape.com> Date: Tue, 26 Oct 1999 12:55:08 -0700 From: QA Test 21 <qatest21@netscape.com> User-Agent: Mozilla 5.0 [en-US] (Linux; I) X-Accept-Language: en MIME-Version: 1.0 To: peter mock test account2 <qatest21@netscape.com> 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: <jefft@netscape.com> 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 <qatest21@netscape.com>; Tue, 26 Oct 1999 13:14:16 -0700 Sender: jefft@netscape.com (Jeff Tsai) Message-ID: <38160B97.7DD9830B@netscape.com> Date: Tue, 26 Oct 1999 13:14:15 -0700 From: Jeff Tsai <jefft@netscape.com> X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: qatest21@netscape.com 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. **********************************************

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

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

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