Closed Bug 210376 Opened 21 years ago Closed 16 years ago

Cannot move a message if it is over at least 213K

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: taj, Assigned: Bienvenu)

Details

Attachments

(6 files)

Log of trying to move message from local to IMAP
30.47 KB, text/plain
Details
Log of selecting the message
51.99 KB, text/plain
Details
Log message of selecting message w/ 1.5 trunk
54.88 KB, text/plain
Details
Selecting and moving message
291.71 KB, text/plain
Details
Moving of two messages failing
48.97 KB, text/plain
Details
Attachment not showing w/ virus
143.35 KB, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030612
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030612

I recieved a virus a while back through email. Since I'm using Mozilla MailNews,
I didn't get infected and just hit delete. When I was moving my trash from my
IMAP server to my hard drive, it kept stopping at that one email with a virus. I
would have to restart the whole Mozilla (MailNews and whatever else I had open,
eg the Browser).

Reproducible: Always

Steps to Reproduce:
1. Go to an IMAP folder (this _could_ affect other protocols, but I haven't
tested it).
2. Try to move a few messages with a large message selected as well (you can
also select a single message). I had 213K, but it might be able to be smaller.
Actual Results:  
Mozilla stopped moving messages at the large message.

Expected Results:  
Mozilla should have kept moving messages.
Most likely the virus message has an embedded null, and it has nothing to do
with the size of the message. What IMAP server are you using? IMAP servers are
not supposed to send embedded nulls according to the IMAP RFC but some versions
of some servers do.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am using the Outblaze (www.outblaze.com) IMAP server through Linuxmail
(www.linuxmail.org). Here are the full headers (w/o message):

Return-Path: <jlvarga@cox.net>
Delivered-To: tmorton:linuxmail.org@linuxmail.org
Received: (qmail 14839 invoked by uid 0); 19 Jun 2003 18:00:42 -0000
Received: from unknown (HELO spf5-2.us4.outblaze.com) (205.158.62.147)
  by 205-158-62-130.outblaze.com with SMTP; 19 Jun 2003 18:00:42 -0000
Received: from fed1mtao02.cox.net (fed1mtao02.cox.net [68.6.19.243])
	by spf5-2.us4.outblaze.com (Postfix) with ESMTP id AF58019A75A
	for <tmorton@linuxmail.org>; Thu, 19 Jun 2003 18:04:00 +0000 (GMT)
Received: from lukErcaB ([68.5.121.116]) by fed1mtao02.cox.net
          (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP
          id <20030619180350.DHOE20281.fed1mtao02.cox.net@lukErcaB>;
          Thu, 19 Jun 2003 14:03:50 -0400
From: "MS Network Security Division" <muxfjseuzjqltpycsw@updates.microsoft.net>
To: "MS User"@spf5-2.us4.outblaze.com
SUBJECT: Microsoft Security Pack.
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="OUxuVkvAjzTGrp"
Message-Id: <20030619180350.DHOE20281.fed1mtao02.cox.net@lukErcaB>
Date: Thu, 19 Jun 2003 14:03:58 -0400

--OUxuVkvAjzTGrp
Content-Type: multipart/alternative; boundary="CySZqoqfxEnlmTLrT"

--CySZqoqfxEnlmTLrT
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

What should I look for to tell if it has an embedded null?

I can send the virus over if you want ;-). Don't worry, it doens't execute
unless you run MS Outlook (and I assume you don't).
Here's what you can do. Generate an imap protocol log by following these
instructions:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

You want to generate a log of selecting the virus message and trying to copy it
to a local folder and then attach the log to this bug or e-mail it to me. The
embedded null is most likely in the message body.

Sending me the message won't help because our IMAP server will not allow the
embedded null, since it's illegal. I'd like to make our code more tolerant of
embedded nulls, at least in the message body, but without a server that will
generate them, it's hard to test :-)


Aarg!! I deleted the message, sorry :-(. Is there any file that might still have
it. I haven't restarted Mozilla yet.
If you deleted it from your inbox, it might still be in your inbox, but just
with the deleted flag set. What you can do is start up Mozilla, and switch your
imap server settings to "when I delete messages, mark them as deleted", instead
of "move them to the trash". Then, click on your inbox, and see if the message
is still there. However, if you have "expunge inbox on exit", it might already
be gone. If it's still there but with a big red x, you can "undelete" it by just
pressing delete again.
Thank you! I got the message. Here is a log of trying to move it from local to
the inbox on my IMAP server. It failed. It also failed trying to move from
Trash on IMAP to local, but suceeded on moving from IMAP Inbox to local trash.
Weird.
I'll be gone for 3 days FYI. No email.
before you go, can you attach a log of just reading the message in your imap
inbox? thx!
Back. There is a log of reading it and moving it up (and there was one before,
too, though)
OK, the log that's attached doesn't show the reading of a message (this could be
because you have the INBOX configured for offline use, and we've already
downloaded the message body). But it's more likely that it's just a log of
moving a message from a local folder to an imap folder. What I was hoping to see
was a log of that message getting selected in an imap folder, so I can see the
contents of the message.

Also, could you try a 1.5 trunk build from yesterday or today? I fixed our
handling of IMAP syntax errors (e.g., the server returns the message incorrectly
because of embedded nulls in the message).
Here is selecting the message on the IMAP server with 1.4 rc2. I'm on dialup
(38KBps), so I'll download todays build and send in a log.
Attachment #126301 - Attachment is obsolete: true
Attachment #126301 - Attachment is obsolete: false
Here is the log generated by selecting the message with 1.5 trunk (build
2003062608). OK. So it also got my mail ;-). Ignore the first section...
OK, one more try (those logs look fine so I can't see the problem from them :-( )

Can you attach a log where you do the following:

1. Select the problem message.
2. Move it to a local folder.

I'm not sure it'll show anything different, but since that was the original
problem scenario, it's worth a try. Thx!
This is the log of selecting and moving the message. Once with it being the
only one being moved, the other time with another message selected. It didn't
hang this time. The reason I tried moving another message is because it caused
the move to fail. Using 2003062608. Maybe you fixed it?
The new log is zipped up so I can upload it. Sorry :-(. I wish I had some server
space with my ISP...
OK. Here is a log using 2003062608. I selected and attempted to move (to a
local folder) two messages. It didn't work.
OK, thx, that last log is interesting. We're trying to read two messages and 
nothing's coming back from the server, because those two messages don't exist 
in the folder. In fact, the Trash is really empty - all the messages in it are 
deleted, according to the server. I'm not sure why we're letting you select 
them in the UI in the first place.
Weird. From the web interface of my mail system, they don't show up. Weird.
This is another log of trying to view a message with 2003062608. It shows up,
but not the attachment. I can see the message. Any ideas?
are you accessing your inbox with web mail at the same time as you access it
with Mozilla? That can cause problems, though it still wouldn't explain what I
see in the log.
No, I am not. I am not accessing the mail interface when I am connected to the
server via Mail. It was when I was booted into Linux that I checked the web mail
interface.
This looks like it might be a problem with the server - we ask for the body
structure of the message, and the server starts complaining and returning
untagged OK responses. Those should be ignored by the parser, I think, but it is
odd.

16 UID fetch 1056724485 (BODYSTRUCTURE)

-734181[23c3580]: ReadNextLine [stream=23c31d8 nb=0 needmore=1]
-734181[23c3580]: ReadNextLine [stream=23c31d8 nb=79 needmore=0]
-734181[23c3580]:
23c2650:linuxmail.outblaze.com:S-INBOX:CreateNewLineFromSocket: * OK [PARSE]
Must use comma to separate addresses: mailerautomat recipient <>

-734181[23c3580]: ReadNextLine [stream=23c31d8 nb=32 needmore=0]
-734181[23c3580]:
23c2650:linuxmail.outblaze.com:S-INBOX:CreateNewLineFromSocket: * OK [PARSE]
Missing parameter

-734181[23c3580]: ReadNextLine [stream=23c31d8 nb=265 needmore=0]
-734181[23c3580]:
23c2650:linuxmail.outblaze.com:S-INBOX:CreateNewLineFromSocket: * 50 FETCH (UID
1056724485 BODYSTRUCTURE (("TEXT" "HTML" ("CHARSET" "US-ASCII") NIL NIL
"QUOTED-PRINTABLE" 203 6 NIL NIL NIL)("AUDIO" "X-WAV" ("NAME" "XfbKnd.exe")
"<uvbmrsh>" NIL "BASE64" 212994 NIL NIL NIL) "ALTERNATIVE" ("BOUNDARY"
"UNfZZuUqxbjNwhY") NIL NIL))

-734181[23c3580]: ReadNextLine [stream=23c31d8 nb=27 needmore=0]
-734181[23c3580]:
23c2650:linuxmail.outblaze.com:S-INBOX:CreateNewLineFromSocket: 16 OK UID FETCH
completed
Product: MailNews → Core
David, I think reporter Taj is gone. Should the "null" issue be followed up on?
QA Contact: grylchan → networking.imap
No, I think that's handled in other bugs. It looks like this really was a server issue.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: