User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 For some type of messages, the problem in Bug #83396 still exists: i try to copy a very simple text message from a Exchange server to a Cyrus IMAP server, and every time the error message (from Cyrus) is: "Message contains bare newlines". I will attache a complete tcpdump of the session. Reproducible: Always Steps to Reproduce: Copy the message in the attachment below from one (Exchange?) IMAP Server to a Cyrus IMAP server. Actual Results: The error message "Message contains bare newlines" is displayed. Expected Results: The mail should have been moved from the Exchange Folder to the Cyrus Folder.

Cyrus is strict about RFC compliance for message structure. This probably isn't really a mozilla bug; Mozilla could probably rewrite non-compliant messages to fix the issue, but the issue isn't caused by Mozilla. Rather, Exchange is accepting and delivering invalid messages into its mail store (gee, who would've thought!). I *think* the error message refers to the following text from RFC2822: " Messages are divided into lines of characters. A line is a series of characters that is delimited with the two characters carriage-return and line-feed; that is, the carriage return (CR) character (ASCII value 13) followed immediately by the line feed (LF) character (ASCII value 10). (The carriage-return/line-feed pair is usually written in this document as "CRLF".) " IMO this is NOTABUG.

I'm seeing this same behavior in a somewhat different environment. In this case, Seamonkey 1.0.5 on Linux connecting to an iPlanet IMAP server. The SeaMonkey changelogs claim they included bug fix #83396 in 1.0.1. If that's the case, then it seems that bug fix didn't actually solve the problem. While Thunderbird may not be causing the badly formatted message, it is trying to submit it back into an IMAP server, and that's not good behavior, particularly since this problem occurs on at least two IMAP implementations (Cyrus, as noted, and iPlanet).

I see this sending messages via SMTP and IMAP. After sending it cannot copy sended massage to "Sent" folder. Is this the same problem?

yes, sounds like the same problem. How do you write these messages that it can't send?

Dunno... Just writing as a normal message. Sometimes appears this message. It started about 3-8 weeks ago I believe.

The first 2 words are cyrillic, but txt does not allows UTF. A file was attached to the mail.

are you using the plain text compose window? Does this ever happen with the html compose window?

Yep, plain text. I believe it hapends wheb I attach a file... But I'm not 100% sure, since in 20070629 build it hapened just once and there was an attachment.

Are you running on linux, mac, or windows? My theory is that it's not due to attachments, but that's only if you're running on linux or mac...

Eugene, could you attach the above message to this bug? I would be nice to have a testcase. We need the whole message with all headers. Thanks.

I'm on Windows. I'll try to repro it and post a full message here.

http://menelon.ee/private/mozilla/message.zip Here is the complete message caused this error message. In attace were 2 pics.

(In reply to comment #1) > tcpdump trace of the IMAP exchange Newline in mail data in this trace is [CRLF] except two [LF] only lines in next part. > savegroup: Offsite_SA completed (oberbirnbach Succeeded)[CRLF] > [LF] > --- Successful Save Sets ---[CRLF] > [LF] Original mail data stream from Exchange Server seems to contain mixed [CRLF] and [LF]. Is mixed newline char(s) permitted? If mixed, Tb should convert single [LF] to [CRLF] or newline of system when saving in local mail box file or temporary file? (If line mode I/O, [CRLF]/[LF]/[CR] is usually removed by OS when file read.) (So I guess that Tb uses binary mode file I/O. ) I think Thunderbird is better to consider [LF] only or [CR] only line as null line when transfer, even if mixture of [CRLF] / [LF] / [CR] is not permitted.

(In reply to comment #4) > I see this sending messages via SMTP and IMAP. After sending it cannot copy > sended massage to "Sent" folder. Isn't newline of your signature file [LF] only or [CR] only?

Wada, I have no idea You are talking about... I attached a complete message that caused this message. I cannot help You else, but testing...

IMAP servers are not supposed to return mixed lines - they're supposed to return full CRLF terminated lines. Eugene, is the problem reproduceable with the message you attached? WADA is talking about the tcpdump attachment, not your attached message. I'm not convinced the original problem and yours are the same, actually.

I sent an e-mail with .jpg attached. Got the same error. Pressed "return to compose window" and changed the e-mail to one of mine. After that the message was copied without any errors... :-/ Maybe I could do some logs? How could that be done?

To David Bienvenu: Will your patch for Bug 320102 work when [LF] from Exchange Server case(orginal problem of this bug)?

Got a message that I can reproduce this bug with. Also got a IMAP log. David: Can I help in an way?

The last I see is this: 348[31911b0]: AAAAABAAUAAAAAAAAAAAEBQAAAAQAAAAFAABAQAFBQWAbB//2Q== 348[31911b0]: 3191a88:m00.opasia.dk:A:SendData: 348[31911b0]: ReadNextLine [stream=3054ea0 nb=37 needmore=0] 348[31911b0]: 3191a88:m00.opasia.dk:A:CreateNewLineFromSocket: 9 NO Message contains bare newlines is the problem the 348[31911b0]: 3191a88:m00.opasia.dk:A:SendData: ? David: Does it mean that it sends an empty line?

Using version 3.0a1pre (2008010204) and also any previous version, First, save sent messages is enabled for all accounts I used on Sent folder imap account. When I send message through imap everything goes as it should. When I try send message through my account which is not imap and if message contains attachment, than I got, message sent, but error copying to sent folder bare newlines. Than, return to compose window, save message to drafts on local folder, close that window, copy message to sent folder on imap account works. Really strange, but annoying. Maybe it will be helpful in debugging.

Adding some words in bug summary, for ease of search.

Can anyone reproduce this with a 3.0b1 build?

Henrik, can you still reproduce this? I might need access to the server(s) that can reproduce it...

(In reply to comment #27) > Henrik, can you still reproduce this? I might need access to the server(s) that > can reproduce it... Sorry but I dont have access to that server anymore.

I can reproduce this on our corporate mail server.