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.
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
Summary: Mail headers are not decoded with XMail+Courier IMAP server (possible newline problem) → IMAP Mail headers are not decoded correctly on windows platform (possible newline problem)
A test account would be great, thx. And yes, it does look the same as bug 139367.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Status: NEW → ASSIGNED
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.
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 ;-) )
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.
Created attachment 126908 [details] [diff] [review] 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?
fix checked in for CRCRLF case on Windows.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.