21907 - [DOGFOOD] Sent attachments get BIG and messed up

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect, P3)

Description

[Michael Collette]

Running build 1999121320 and sent an E-Mail with a 50k zip file.  I would
normally expect this to expand a bit for the encoding, but not all the way up to
125k.  Messenger 4.7 expands the file up to 75k when sending.

Aside from making
the attachment way big, it came through scrambled.  Sent to my
Messenger 4.7
client and the attachment came through as text rather than an attachment.

Comment 1

[pmock]

changing qa assigned to [e-mail]

Comment 2

[pmock]

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

Comment 3

[pmock]

Rich,

I noticed that zip attachments are improperly encode the messages as
 Content-Type: text/plain;
 Content-Transfer-Encoding: quoted-printable

In general, it should encode it as
 Content-Type: application/x-zip-compressed;
 Content-Transfer-Encoding: base64

When I try to save a zip attachment sent from 5.0, Winzip 6.3 can not uncompress
the file.  It gives the following error messages
 "Error in file #1: Bad zip file offset (Error local header signature not
found): disk1 offset 0.  Please press F1 for help."
 "Error: unexpected end of the file encountered.  Please press F1 for help"

In 5.0, if I save an attach zip file sent from Win32 4.7, I uncompress the zip
file.  It appears to be a issue during sending in 5.0.

I can also reproduce this problem using other types of attachments.
Example:
 - if I try to attach a word document in 5.0 and send it then view the page
source in win32 4.7 communicator, it is encoded as quoted-printable.
 - if I attach a gif file in 5.0 and send it then view the page source in win32,
it is encoded as quoted-printable.

Seamonkey does not have a problem encoding text attachments with or without an
.txt entension.  It identifies the text file and correctly encodes it as:
 Content-Type: text/plain;
 Content-Transfer-Encoding: 7bit

It appears that any attachment that it does not understand gets encoded as
Content-Transfer-Encoding: quoted-printable which causes a problem because when
the save attachment can not be open in the native/original application.

This may be caused (I'm guessing) due to the Helper Application feature not
being implemented yet.  Is it possible to set the default encoding for unknown
file as Content-Transfer-Encoding: base64?

Seamonkey can save base64 encoded attachment just fine.

Norminating for Dogfood.  If seamonkey is making binary file (word or zip)
attachment unusable then it should be a dogfood issue.

Adding Phil Peterson and Jeff Tsai to cc: list.
Note: I was testing using the win32 commercial seamonkey build 1999-12-15-09-m12

Comment 4

[rhp (gone)]

Thanks for the work Peter, but I have this fixed already. Basically, the Necko
MIME type service that tells us what type of file something is, currently is a
hack. We don't recognize ZIP so we did a fallback type. Now, I've fixed this by
changing the way we fallback and now this works.

I want to nominate this for a PDT+ bug since I have a pretty safe fix in hand.

Phil: Help :-)

- rhp

Comment 5

[leger]

PDT+

Comment 6

[rhp (gone)]

Just checked in the fix.

- rhp

Comment 7

[Michael Collette]

For what it's worth, tested this out on NT as of build 1999121712 and it works
perfectly now.  Very cool!

Comment 8

[pmock]

Verified as fixed on win32, macos, and linux using the following builds:
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-12-17-13-M12/sea
monkey32e.exe
ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/1999-12-17-10-
M12/netscape-i686-pc-linux-gnu.tar.gz
ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-12-17-10-M12/NSMacIn
staller-M12.sea.bin

Great work Rich.
Thanks [e-mail] for checking this bug too.