210800 - IMAP Mail headers are not decoded correctly on windows platform (possible newline problem)

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Michel Wyraz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.4) Gecko/20030612
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.4) Gecko/20030612

I am using XMail MTA with Courier IMAP as IMAP addon. When i'm using Mozilla
(including newest Release: 1.4RC3) the Headers of all IMAP mails are shown
within the body. Only the first line is decoded - so i think it's a newline
Problem. Maybe the server sends \r\n instead of \n as newline (or some other
sequence). I'm not sure if it's a server problem. But Mozilla is the only client
where that bug occurs. The Bug is very similar to
http://bugzilla.mozilla.org/show_bug.cgi?id=139367 but it occurs on every mail here.
I can create a test IMAP account restritedt to the developers who fix the
problem. Just send me a mail.

Reproducible: Always

Steps to Reproduce:
1. I create a new IMAP account or use an existing and send some mails to there
2. I add this account to Mozilla Mail
3. I check Mail
4. the bug occurs on every mail

Actual Results:  
the first line of the header is decoded. when this line contains the subject,
the inbox shows the subject. then it contains the sender, this is shown in the
inbox message list. but all other inbox fields are emtpy.

Expected Results:  
decode the whole header until a newline occurs

I set this problem to major serverity since this makes IMAP completely unusable
in some cases.

Comment 1

[Michel Wyraz]

i checked this out with windows 2000 and linux both using the latest mozilla
(1.4rc3):
on win2k the bug also occurs
on linux it don't

Comment 2

[David :Bienvenu]

A test account would be great, thx. And yes, it does look the same as bug 139367.

Comment 3

[David :Bienvenu]

We're getting 0x0d 0x0d 0x0a as the line terminator - the msglib base code is
returning that as a single line to the imap parsing code, which should be
treating that as a single line - I'm not sure where the problem occurs, but it
looks like it's somewhere in the imap parser.

Comment 4

[Michel Wyraz]

today i discovered that the bug occurs on some mails on linux also. only mails
with attachments seems to be concerned. i copied one of this mails into the test
account.

Comment 5

[Michel Wyraz]

the problem with the mails with attachment seems to be a different: the header
data is shown within the mail list so the header is decoded. it may be a mime
decoding problem. i'll add a new bug for this (or search an existing one ;-) )

Comment 6

[David :Bienvenu]

actually, now that I think about it, it's probably not the imap code that's at
fault - it's probably the header parser code, and the mime code that's not
dealing with the funky line endings on Windows. We may need to strip the line
endings in the core imap code right before we give the lines to the core msglib
code. I could try to fix the mime code, but that's a bit daunting.

Comment 7

[David :Bienvenu]

Attachment: proposed fix

this fixes the problem on windows. However, with this fix, I now see the mime
problem. I wonder if the message displays correctly on other imap clients?

Comment 8

[David :Bienvenu]

fix checked in for CRCRLF case on Windows.