mozilla stalls fetching content of particular mails, possibly due to 8bit data



MailNews Core
Networking: IMAP
16 years ago
9 years ago


(Reporter: Blu3, Assigned: Cavin Song)


Firefox Tracking Flags

(Not tracked)




(2 attachments, 2 obsolete attachments)

5.03 KB, message/rfc822
23.78 KB, message/rfc822


16 years ago
Moz mail hangs while trying to fetch the content of a particular email [email
and IMAP log located at URL].  I suspect it may be due to the 8bit data in the
Subject or From headers.  Kryptolus loaded the example email in a debug build
and will post some stack traces.  I'm using build 2002 0413 07 on Linux.  IMAP
server is UW and SSL is enabled.

Once that particular email is attempted, moz mail is useless for that mailbox
and everything must be restarted.  No crash, just stall. Note, only that
particular mailbox is affected.  Other mailboxes can be browsed and operated on

Comment 1

16 years ago
I'll hold off on the stack a bit.
The email consists of a *lot* of nested tables.
The problem goes away if you remove the charset from meta.

Further email will follow shortly.
Trying to make a testcase.

Comment 2

16 years ago
41 seconds to render on 1.5ghz machine ...
I'll hold off confirming until I create a minimal test case

Comment 3

16 years ago
8 nested tables with a form inside the deepest level
removing 'marginheight' and 'marginwidth' from the root table causes the message
to be rendered instantly

will attach the 'somewhat' simplified message (it's still rather large)

Comment 4

16 years ago
Just to clarify, the initial problem with this email is during the IMAP
fetch procedure on startup.  There are 761 emails in my INBOX, this particular
one is #740.  Moz starts fetching new emails, gets up to #740, and stalls.

Moz isn't trying to render a message body just yet.

Comment 5

16 years ago
Created attachment 79836 [details]
evil mail message

Comment 6

16 years ago
can you attach an imap log?

Comment 7

16 years ago
IMAP log is at


Comment 8

16 years ago
Looking at the log it does indeed look like an 8 bit character parsing issue o
our end. cavin loves these 8 bit bugs. re-assigning.
Assignee: mscott → cavin
Ever confirmed: true

Comment 9

16 years ago
Would someone -please- do something about this.  Even a hack that displays raw
data would be fine.  Totally stalling access to the mailbox is unacceptable.
Severity: normal → major

Comment 10

16 years ago
Created attachment 82669 [details]
8bit in headers, ex #1

Comment 11

16 years ago
Created attachment 82670 [details]
8bit in headers, ex #2


16 years ago
Attachment #82669 - Attachment mime type: application/octet-stream → message/rfc822


16 years ago
Attachment #82670 - Attachment mime type: application/octet-stream → message/rfc822

Comment 12

16 years ago
Viewing the offending emails in mozilla works fine, loading them in the mailbox
breaks messenger.

Comment 13

16 years ago
I could not reproduce the problem using message from I sent the
message to an imap account and I saw garbage chars in both the From: and
Subject: headers but the body text showed the right Korean chars. I copied the
message to a local folder and it worked fine as well.

Comment 14

16 years ago
Created attachment 82808 [details]
yet another borken mail

That one works fine.  Odd, I must have attached the wrong one.	I'm attaching
another email that it does stall on.  Simply append it to $mailbox.

Attachment #82669 - Attachment is obsolete: true
Attachment #82670 - Attachment is obsolete: true

Comment 15

16 years ago
I still could not reproduce the problem using message from

I compared the my log against the one from comment #6 and the downloaded headers 
are all the same. The difference is that the command used to download the header 
in the log from comment #6 is:

  15 UID fetch 2728:2750 (UID RFC822.SIZE BODY.PEEK[])

and the server response is:

  * 740 FETCH (UID 2728 RFC822.SIZE 24273 BODY[] {24273}

whereas mine is:


and the server response is:

  * 2 FETCH (FLAGS (\Seen) UID 2 RFC822.SIZE 25045 BODY[HEADER] {1195}

Note that mine does not try to load the message body yet (ie, it uses 
BODY.PEEK[HEADER] instead of BODY.PEEK[]). I'm running a build from this week so 
I think some fixes might have been made to fix the fetch command for similar 

David, are you still running the build from 04/13/02? Can you try the latest 
build to see if the behavior changes. Can you also attach an IMAP log if it 
still does not work?  Thanks.

Comment 16

16 years ago
Ok, latest build tested, 5/11 08.  Still have problems.  I put the original
email I'm using ( in a folder,
tried loading it, no go.  I've updated my mozbugs page
( and here is the URL to the IMAP

I've added some comments inline w/ the logfile indicating where I was doing
things.  Here's the summary of the unmodified log file:

startup, 463 lines
copy eml file
load bluelist folder
now have 499 lines
clicked on broken email
now have 520 lines
clicked on INBOX again
now have 565 lines


15 years ago
QA Contact: huang → gchan
Product: MailNews → Core

Comment 17

10 years ago
i believe the rewrite that dealt with embedded NULLs also fixed this.  this bug is WFM now.
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.