Build Date & Platform Bug Found: Win32 commercial seamonkey build 1999-10-13-09 installed on P166 Win98 Linux commercial seamonkey build 1999-10-13-08 installed on P200 RedHat 6.0 MacOS commercial seamonkey build 1999-10-13-08 installed on G3/400 OS 8.5.1 ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-10-13-09-M11/ ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/1999-10-13-08-M11/ ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-10-13-08-M11/ Overview Description: Under POP, large file attachment (text, gif, or jpeg) do not download when you retrieve the message. The size column on the message reports that only 1k was downloaded. The header of the message is downloaded but not much more. I will attach some sample files to this bug. Steps to Reproduce: 0) Removed my existing mozilla registry and user profile 1) Double click on icon entitled 'mozilla messenger' (migration is broken today - see bug 16305) 2) Enter a profile name or choose the default and click on the Finish button Messenger should open and the mail wizard appears 3) Follow the mail wizard and fill in the information requested Messenger should open 4) Quit Seamonkey 5) Edit the prefs.js to change the mail type from POP3 to IMAP. Existing problem with dropdown menu 6) From Communicator 4.7 RTM, send a mail message with a large jpeg or gif image (>7) to your test account 7) From seamonkey, open your inbox and click on the Get Msg button 8) Select the message you sent from Communicator 4.7 Notice the message is only partially downloaded. Actual Results: Only a portion of the message is downloaded. It downloads the header and maybe the first line. For a gif attachment, the graphic image would be blank. For a jpeg attachment, it would display a string such as 'Inbox?number=32933&part=1'. Expected Results: Seamonkey should download the entire message instead of only 1k reported under the Messenger size column. Additional Builds and Platforms Tested On: This problem occurs on all platforms. Additional Information: These messages are retrieved fine under Communicator 4.7. This problem does not occur under IMAP. It exhibits a different problem on rendering attached gif/jpeg files - see bug 16334.

Making myself the qa contact.

Suggesting for DOGFOOD...

This sounds like a necko problem to me.

This may be related to bug 16368. For some reason I was receiving earlier protocol termination string ".\r\n" from the underlying input stream. This shouldn't happen. Using 4.7 I don't have the problem. warren if you are interested you can use qatest21 test account (password Ne!sc-pe) to reproduce the problem. There is only one mail message stored in the Inbox which can cause the problem. You can see that the message is partially download to the local Inbox mailfolder. I am continuing figuring out who spits out the ".\r\n" string.

Putting on [PDT+] radar.

00F2C29B 2B 4F 4B 0D 0A 52 65 74 75 72 6E 2D 50 61 74 68 3A 20 3C +OK..Return-Path: < 00F2C2AE 6A 65 66 66 74 40 6E 65 74 73 63 61 70 65 2E 63 6F 6D 3E jefft@netscape.com> 00F2C2C1 0D 0A 52 65 63 65 69 76 65 64 3A 20 66 72 6F 6D 20 6E 65 ..Received: from ne 00F2C2D4 74 73 63 61 70 65 2E 63 6F 6D 20 28 5B 31 39 38 2E 39 33 tscape.com ([198.93 00F2C2E7 2E 39 35 2E 32 35 30 5D 29 20 62 79 20 64 72 65 64 64 2E .95.250]) by dredd. 00F2C2FA 6D 63 6F 6D 2E 63 6F 6D 0D 0A 20 20 20 20 20 20 20 20 20 mcom.com.. 00F2C30D 20 28 4E 65 74 73 63 61 70 65 20 4D 65 73 73 61 67 69 6E (Netscape Messagin 00F2C320 67 20 53 65 72 76 65 72 20 34 2E 31 20 41 75 67 20 20 39 g Server 4.1 Aug 9 00F2C333 20 31 39 39 39 20 31 38 3A 32 38 3A 33 31 29 20 77 69 74 1999 18:28:31) wit 00F2C346 68 20 45 53 4D 54 50 0D 0A 20 20 20 20 20 20 20 20 20 20 h ESMTP.. 00F2C359 69 64 20 46 4A 4D 33 57 5A 30 30 2E 55 49 49 20 66 6F 72 id FJM3WZ00.UII for 00F2C36C 20 3C 71 61 74 65 73 74 32 31 40 6E 65 74 73 63 61 70 65 <qatest21@netscape 00F2C37F 2E 63 6F 6D 3E 3B 20 54 68 75 2C 20 31 34 20 4F 63 74 20 .com>; Thu, 14 Oct 00F2C392 31 39 39 39 0D 0A 20 20 20 20 20 20 20 20 20 20 31 34 3A 1999.. 14: 00F2C3A5 33 34 3A 31 31 20 2D 30 37 30 30 20 0D 0A 4D 65 73 73 61 34:11 -0700 ..Messa 00F2C3B8 67 65 2D 49 44 3A 20 3C 33 38 30 36 34 43 37 42 2E 31 30 ge-ID: <38064C7B.10 00F2C3CB 36 44 31 45 35 46 40 6E 65 74 73 63 61 70 65 2E 63 6F 6D 6D1E5F@netscape.com 00F2C3DE 3E 0D 0A 44 61 74 65 3A 20 54 68 75 2C 20 31 34 20 4F 63 >..Date: Thu, 14 Oc 00F2C3F1 74 20 31 39 39 39 20 31 34 3A 33 34 3A 35 31 20 2D 30 37 t 1999 14:34:51 -07 00F2C404 30 30 0D 0A 46 72 6F 6D 3A 20 6A 65 66 66 74 40 6E 65 74 00..From: jefft@net 00F2C417 73 63 61 70 65 2E 63 6F 6D 20 28 4A 65 66 66 20 54 73 61 scape.com (Jeff Tsa 00F2C42A 69 29 0D 0A 58 2D 4D 61 69 6C 65 72 3A 20 4D 6F 7A 69 6C i)..X-Mailer: Mozil 00F2C43D 6C 61 20 34 2E 37 20 5B 65 6E 5D 20 28 57 69 6E 4E 54 3B la 4.7 [en] (WinNT; 00F2C450 20 55 29 0D 0A 58 2D 41 63 63 65 70 74 2D 4C 61 6E 67 75 U)..X-Accept-Langu 00F2C463 61 67 65 3A 20 65 6E 2C 7A 68 2D 54 57 2C 7A 68 0D 0A 4D age: en,zh-TW,zh..M 00F2C476 49 4D 45 2D 56 65 72 73 69 6F 6E 3A 20 31 2E 30 0D 0A 54 IME-Version: 1.0..T 00F2C489 6F 3A 20 70 65 74 65 72 20 6D 6F 63 6B 20 74 65 73 74 20 o: peter mock test 00F2C49C 61 63 63 6F 75 6E 74 32 20 3C 71 61 74 65 73 74 32 31 40 account2 <qatest21@ 00F2C4AF 6E 65 74 73 63 61 70 65 2E 63 6F 6D 3E 0D 0A 53 75 62 6A netscape.com>..Subj 00F2C4C2 65 63 74 3A 20 47 49 46 20 69 6D 61 67 65 20 37 32 35 78 ect: GIF image 725x 00F2C4D5 35 31 35 20 70 69 78 65 6C 73 0D 0A 43 6F 6E 74 65 6E 74 515 pixels..Content 00F2C4E8 2D 54 79 70 65 3A 20 6D 75 6C 74 69 70 61 72 74 2F 6D 69 -Type: multipart/mi 00F2C4FB 78 65 64 3B 0D 0A 20 62 6F 75 6E 64 61 72 79 3D 22 2D 2D xed;.. boundary="-- 00F2C50E 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 30 33 34 33 39 33 42 39 42 ----------034393B9B 00F2C521 37 31 37 45 41 41 36 36 34 43 30 46 35 41 46 22 0D 0A 0D 717EAA664C0F5AF"... 00F2C534 0A 54 68 69 73 20 69 73 20 61 20 6D 75 6C 74 69 2D 70 61 .This is a multi-pa 00F2C547 72 74 20 6D 65 73 73 61 67 65 20 69 6E 20 4D 49 4D 45 20 rt message in MIME 00F2C55A 66 6F 72 6D 61 74 2E 0D 0A 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D format...---------- 00F2C56D 2D 2D 2D 2D 30 33 34 33 39 33 42 39 42 37 31 37 45 41 41 ----034393B9B717EAA 00F2C580 36 36 34 43 30 46 35 41 46 0D 0A 43 6F 6E 74 65 6E 74 2D 664C0F5AF..Content- 00F2C593 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 3B 20 63 68 Type: text/html; ch 00F2C5A6 61 72 73 65 74 3D 75 73 2D 61 73 63 69 69 0D 0A 43 6F 6E arset=us-ascii..Con 00F2C5B9 74 65 6E 74 2D 54 72 61 6E 73 66 65 72 2D 45 6E 63 6F 64 tent-Transfer-Encod 00F2C5CC 69 6E 67 3A 20 37 62 69 74 0D 0A 0D 0A 3C 21 64 6F 63 74 ing: 7bit....<!doct 00F2C5DF 79 70 65 20 68 74 6D 6C 20 70 75 62 6C 69 63 20 22 2D 2F ype html public "-/ 00F2C5F2 2F 77 33 63 2F 2F 64 74 64 20 68 74 6D 6C 20 34 2E 30 20 /w3c//dtd html 4.0 00F2C605 74 72 61 6E 73 69 74 69 6F 6E 61 6C 2F 2F 65 6E 22 3E 0D transitional//en">. 00F2C618 0A 3C 68 74 6D 6C 3E 0D 0A 26 6E 62 73 70 3B 0D 0A 3C 62 .<html>..&nbsp;..<b 00F2C62B 72 3E 3C 41 20 48 52 45 46 3D 22 68 74 74 70 3A 2F 2F 62 r><A HREF="http://b 00F2C63E 75 67 7A 69 6C 6C 61 2E 6D 6F 7A 69 6C 6C 61 2E 6F 72 67 ugzilla.mozilla.org 00F2C651 2F 73 68 6F 77 61 74 74 61 63 68 6D 65 6E 74 2E 63 67 69 /showattachment.cgi 00F2C664 3F 61 74 74 61 63 68 5F 69 64 3D 32 31 35 36 22 3E 68 74 ?attach_id=2156">ht 00F2C677 74 70 3A 2F 2F 62 75 67 7A 69 6C 6C 61 2E 6D 6F 7A 69 6C tp://bugzilla.mozil 00F2C68A 6C 61 2E 6F 72 67 2F 73 68 6F 77 61 74 74 61 63 68 6D 65 la.org/showattachme 00F2C69D 6E 74 2E 63 67 69 3F 61 74 74 61 63 68 5F 69 64 3D 32 31 nt.cgi?attach_id=21 00F2C6B0 35 36 3C 2F 41 3E 3C 2F 68 74 6D 6C 3E 0D 0A 0D 0A 2D 2D 56</A></html>....-- 00F2C6C3 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 30 33 34 33 39 33 42 ------------034393B 00F2C6D6 39 42 37 31 37 45 41 41 36 36 34 43 30 46 35 41 46 0D 0A 9B717EAA664C0F5AF.. 00F2C6E9 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 69 6D 61 67 65 Content-Type: image 00F2C6FC 2F 67 69 66 3B 0D 0A 20 6E 61 6D 65 3D 22 73 68 6F 77 61 /gif;.. name="showa 00F2C70F 74 74 61 63 68 6D 65 6E 74 2E 63 67 69 22 0D 0A 43 6F 6E ttachment.cgi"..Con 00F2C722 74 65 6E 74 2D 54 72 61 6E 73 66 65 72 2D 45 6E 63 6F 64 tent-Transfer-Encod 00F2C735 69 6E 67 3A 20 62 61 73 65 36 34 0D 0A 43 6F 6E 74 65 6E ing: base64..Conten 00F2C748 74 2D 44 69 73 70 6F 73 69 74 69 6F 6E 3A 20 69 6E 6C 69 t-Disposition: inli 00F2C75B 6E 65 3B 0D 0A 20 66 69 6C 65 6E 61 6D 65 3D 22 73 68 6F ne;.. filename="sho 00F2C76E 77 61 74 74 61 63 68 6D 65 6E 74 2E 63 67 69 22 0D 0A 0D wattachment.cgi"... 00F2C781 0A 52 30 6C 47 4F 44 64 68 31 51 49 44 41 74 55 41 41 50 .R0lGODdh1QIDAtUAAP 00F2C794 2F 2F 2F 2F 2F 2F 7A 50 2F 2F 6D 63 7A 2F 2F 38 7A 2F 7A //////zP//mcz//8z/z 00F2C7A7 4D 7A 2F 6D 66 2F 4D 2F 38 7A 2F 5A 76 2F 4D 7A 4D 7A 2F Mz/mf/M/8z/Zv/MzMz/ 00F2C7BA 4C 2F 2F 4D 6D 5A 6E 2F 6D 63 7A 4D 2F 32 62 2F 0D 0A 2F L//MmZn/mczM/2b/../ 00F2C7CD 38 7A 4D 7A 4A 6E 6A 7A 4A 6E 2B 4D 38 7A 4D 6D 58 50 2F 8zMzJnjzJn+M8zMmXP/ 00F2C7E0 5A 70 6A 2B 41 50 2B 5A 2F 35 6E 4D 6D 63 79 5A 2F 2B 4F Zpj+AP+Z/5nMmcyZ/+O 00F2C7F3 77 50 44 50 2F 4D 38 79 58 6D 66 39 6D 2F 35 6D 5A 2F 32 wPDP/M8yXmf9m/5mZ/2 00F2C806 72 4D 5A 6A 2F 4D 79 35 6D 5A 7A 4D 78 35 0D 0A 7A 4A 6D rMZj/My5mZzMx5..zJm 00F2C819 5A 6D 63 78 6D 2F 7A 50 4D 4D 32 61 5A 6D 58 4F 5A 5A 76 Zmcxm/zPMM2aZmXOZZv 00F2C82C 38 79 2F 7A 4F 5A 6D 51 44 4D 41 4D 77 7A 2F 35 6C 6D 5A 8y/zOZmQDMAMwz/5lmZ 00F2C83F 70 6C 6D 4D 35 6C 6D 41 47 74 66 6E 47 5A 6D 5A 6D 5A 78 plmM5lmAGtfnGZmZmZx 00F2C852 4B 50 38 41 6D 63 77 41 2F 2F 38 41 0D 0A 2E 0D 0A 00 00 KP8AmcwA//8A....... This is what showed in the memory when we read 1480 bytes from the input stream. Don't know who puts up the "2E 0D 0E". I'll either telnet to the server or using sniffer to monitor the content of the packet.

From the sniffer, the pop3 server did send us "2E 0D 0A". We might be not sending pop3 command correctly.

This is definitely a protocol problem. We are supposely to send RETR command instead of TOP command to retrieve the message. There is a logic to check the downloading message size not exceeding the connection data size limit - 51200. If the message size is greater than that we send TOP instead of RETR. The result is a truncated message. I don't where this 51200 size limit came from. This seems not quiet right to me.

Size limit lifted. nsPop3Protocol.cpp changed. This is the default behavior. However, I am removing the dogfood tag. The real fix is more than lifting the size limit. First, we need to have lib mime support for displaying truncated message url box. Then we need to allow user to click and download the whole message.

I am clearing th [PDT+] flag. We do able to download the large file attachment since I lifted the size limit. The partial download requires not only the protocol to support but also the libmime. This can be a post beta feature.

I am marking this bug as fixed. The problem has been fixed. I am filing another bug for the partial download feature.

Verified as fixed on win, mac, and linux under POP3 using the following builds: ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-11-17-17-M12/sea monkey32.exe ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-11-17-08-M12/netscap e5-mac-M11.sea.bin ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/1999-11-17-17- M12/netscape-i686-pc-linux-gnu.tar.gz