81352 - Unable to read binhex attachments sent from Eudora on Windows

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect, P2)

Description

[Scott MacGregor]

1) Send yourself an attachment from Eudora (be sure to configure eudroa to
binhex encode outgoing attachments.

2) Try to read the attachment on windows. We never discover that we need to
decode the binhex.

Looks like 4.x had an escalation on this after we branched off 6.0. This fix was
never ported over to the mozilla codebase.

The problem is that Eudora does some NASTY stuff. The claim the attachment is of
content type: text/plain and a file name that doesn't correspond to that:
"myfile.zip" or "myfile.doc".

The only way to figure out what's going on is to realize the text/plain content
type and sniff the first line of the message. If it contains:
"This part needs to be decoded by BinHex4.0" then we should decode the
attachment and then use the content type you'd get from the extension of the
file-name. 

This is so non-RFC compliant and hokey it's disgusting. 

Fortunately it doesn't look like Eudora's smart enough to even localzie the
string saying the attachment needs decoded using bin hex 4.0 so we should be
able to rely on a string comparison.

Comment 1

[marlon bishop]

Thanks Scott.  btw, i just tested with Mac Outlook Express 5.02 and it's 
apparently doing some of this "nasty" BinHex stuff too.

Sending from OE5,  NS6 spews the entire attachment into the message starting 
with:

"This part needs to be decoded by BinHex4.0"

Comment 2

[Scott MacGregor]

can you send me a message from OE 5.02 as well so I can compare them?

Comment 3

[marlon bishop]

Scott, nevermind that about OE502 i was wrong.  I've been testing alot of stuff, 
just checked the file i was using as an attachment - had an "text zip" mime type 
itself before i sent it. a "text" zip?  I tried sending something else from OE5 
again with a different zip file and it opened no problem when received on Win NS6

so the main problem seems to be only on Eudora. sorry for confusion

Comment 4

[Scott MacGregor]

I am unable to make 4.7 work with attachments sent from Eudora using this format. 

When I save the attachment to disk and then open it, winzip says it's corrupt.
It still has the binhex encoding applied to it. 

Comment 5

[marlon bishop]

scott, i have just tried this several different times on my PC, and 4.7 is able 
to deal with it for me. this IS sending from MAC Eudora. Win NS4.7 opens a dialog 
which is titled, "save decoded attachment as:"  and then you are prompted to fill 
in the file name.  THe file it saves, can be double clicked on and opened in 
WinZip with no error messages.  Are you doing a process that's different than 
this?

Comment 6

[Scott MacGregor]

In the message pane I am right clicking on the attachment icon and getting a
context menu. I'm selecting save link as. I enter a location. Then launch winzip
on the file. Winzip says the file is corrupt. It appears to still be
binhex'ed....(this is using 4.7)

Comment 7

[marlon bishop]

ok the exact situation you described does not happen to me. i've tried several 
different tests. i can consistently open the attachments with 4.7.  are you going 
from WIN eudora or mac?  maybe that the difference

Comment 8

[Scott MacGregor]

I actually don't ahve a eudora product on my machine. =)

I'm just using the email you sent me. 4.7 doesn't decode it for me when I save
it to disk. 

Comment 9

[marlon bishop]

that was actually a faulty attachment to start with Scott.  remember, "text zip" 
mime type i said before. i  don't know how i made that.  try a fresh one, it will 
work

Comment 10

[Scott MacGregor]

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

Comment 11

[Scott MacGregor]

in addition to sniffing for binhex, we need to sniff for uuencoded content.
Putting on the .9.2 radar for evaluation.

Comment 12

[scottputterman]

adding PDT+

Comment 13

[Scott MacGregor]

Attachment: fixes the problem with uuencoded attachments

Comment 14

[Scott MacGregor]

Okay this patches fixes half of this bug. It causes our uudecode support to get
triggered when you are forwarded a message which contains a uuencoded
attachment. Our libmime code wasn't showing the .xls file as an attachment in
the message pane because we used to not iterate over the parts of an inlined
message to see if the inlined message had attachments. My hokey fix is to ensure
that if any part of a message (including forwarded parts) has an external body
(i.e. an attachment) then we show it. I can now open Cindy's test email that has
a uuencoded .xls attachment and it launches in Excel just fine. 

I suppose I should have kept these two bugs separate after all but I thought the
fixes were going to be similar. 

Next up: writing a binhex decoder to decode binhex'ed attachments per the test
emails Marlon has been sending me. 

Comment 15

[selmer (gone)]

No current activity in this bug.  Are we going to take the patch we have and
leave the binhex for later?  Maybe it's time to put that in another bug.  Please
update the status whiteboard with your eta.

Comment 16

[Scott MacGregor]

there seems to be some confusion about this bug. Let me clarify, I incorrectly
duped a bug of Cindy Roberts as a dup of this bug. I posted the patch for her
problem here and in another bug (83457). 83457 has been fixed. So this patch is
checked in. 

This bug is tracking a problem we have showing binhex attachments sent from eudora. 

Comment 17

[Scott MacGregor]

I'm close to finishing the bin hex decoder. It seems to be working on Windows
but I have some more work to finish it up and get it running on other platforms.
Should be done Friday night or sometime over the weekend. 

Comment 18

[Scott MacGregor]

Attachment: Netwerking changes to implement and register a bin hex decoder

Comment 19

[Scott MacGregor]

This patch is the first part of the fix. It implements a bin hex decoder for mac
and linux. I can now open bin hex attachments on mac and linux correctly. 

There's still more work to be done though. I need to hook into the mail save
attachment code to run through this decoder when saving the attachment directly
from mail. This work is blocked waiting for Jean-Francois to land 84065. 

Marking that dependency now. 

Comment 20

[Scott MacGregor]

Attachment: 2nd part of the fix. Add decoder hooks into saving mail attachments

Comment 21

[Scott MacGregor]

ok, this 2nd patch is also part of the fix. It actually hooks up the binhex
decoder when we are saving binhex attachments directly from messenger on non mac
platforms. Many thanks to Jean-Francois whose similar work for apple double made
it trivial to insert this part. 

So the fix requires both the patch on 6/22 and the patch on 6/26.

Comment 22

[Jean-Francois Ducarroz]

Both patches look good. R=ducarroz

Comment 23

[(not reading, please use [e-mail] instead)]

sr=sspitzer

Comment 24

[scottputterman]

moving to 0.9.3 with nsbranch.  Testing it on the trunk first would be great and
then we can land it on the branch if all goes well.

Comment 25

[Scott MacGregor]

This has been checked into the tip. Leaving open for checkin into the branch. 

To test:
1) Using Eudora on the Mac send yourself several types of binary attachments. Be
sure to select BinHEX as the outgoing attachment.

2) View the messages on both Windows AND Linux. Try opening the attachment
directly by double clicking the attachment. Make sure it runs in excel (if it's
an excel attachment) or some other appropriate handler. 

3)You also need to test saving the attachment directly from mail via the
attachment context menu or the File / Save Attachment menu. Save it to disk and
then try to open the attachment using the right application. Verify that the
integrity of the attachment is correct. 

Comment 26

[Scott MacGregor]

adding the vtrunk keyword so QA can try verify this soon on the trunk so we can
pre-flight it for landing on the branch.

Comment 27

[[e-mail] (gone - use [e-mail] instead)]

Using -trunk- builds: 

Windows 2K : 2001-06-28-04
RedHat 7.1 : 2001-06-28-14

I did the following on an OS 9.1 system using Eudora 5.1 for Macintosh:

Using the BinHEX setting under "Sending Attachments":

File Type     Open      Save As
-------------------------------
.xls           Y           Y
.doc           Y           Y
.zip           Y           Y

I did the verification of opening *only* on Windows 2000, as my Linux box's
GEDIT couldn't open .DOC (nor could I find an app to open .XLS).  But what I did
with Linux, was save the attachments (these were directly sent using BinHEX from
Mac) and then I sent the attachments back to my Windows 2000 machine and saved
and opened them there, making sure of no corruption.

For Windows 2000, I ran the full gamut of that matrix listed above.

Verified (again this is trunk only).

Comment 28

[esther]

Using build 2001-07-04 on linux, a binhex attachment sent by Mac Eudora 5.1
crashes when double-clicking or trying to open using the menus.  This same
attachment in 4.7 will bring up the save dialog.
The file is a Gnome Calendar file, that was saved using 4.7 on a linux system,
sent by attachment to myself.  I then saved this file to my mac desktop and 
resent to myself as a binhex so I could open it on my linux system.  
ncident ID 32515931
Stack Signature GetReadableFragment() 29c5f808

GetReadableFragment()
nsACString::do_AssignFromReadable()
nsACString::AssignFromReadable()
nsBinHexDecoder::SetContentType()
nsBinHexDecoder::ProcessNextState()
nsBinHexDecoder::ProcessNextChunk()
nsBinHexDecoder::OnDataAvailable()
nsDocumentOpenInfo::OnDataAvailable()
nsMimeBaseEmitter::Complete()
nsStreamConverter::OnStopRequest()
nsImapCacheStreamListener::OnStopRequest()
Process()
OnDataAvailable()
XPTC_InvokeByIndex()
EventHandler()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xe52a (0x4034452a)
libglib-1.2.so.0 + 0xfbe6 (0x40345be6)
libglib-1.2.so.0 + 0x101a1 (0x403461a1)
libglib-1.2.so.0 + 0x10341 (0x40346341)
libgtk-1.2.so.0 + 0x8c209 (0x4026d209)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x181eb (0x4043d1eb) 

Comment 29

[Scott MacGregor]

Attachment: Fix for esther's crash

Comment 30

[Scott MacGregor]

I just attached a small change which fixes the crash esther sees on linux when
we don't recognize the content type of the decoded file. 

Comment 31

[(not reading, please use [e-mail] instead)]

rs=sspitzer on the last patch.

Comment 32

[Scott MacGregor]

I fixed Esther's crash condition. We are no longer considering this for the
branch so I'm just going to mark it fixed now. 

Comment 33

[esther]

using build 2001-09-21 branch on linux this is fixed. Verified