User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030313 Galeon/1.3.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Messages disappear from IMAP inbox, not found anymore by Pine (functions correctly). In destination folder some of moved messages appear and the rest will have subject, sender and body empty and their date is 1.1.1970 2:00 am. I haven't found way to get those messages back, so I'am losing valuable data! Reproducible: Sometimes Steps to Reproduce: 1. Have a lot of mail in Inbox folder of IMAP account. 2. Select them all. 3. Move selected messages by mouse to a local folder. Actual Results: Messages disappeared from IMAP Inbox. In destination folder there was some of the messages. The rest were having subject, sender and body empty and date 1.1.1970 2:00 pm. Expected Results: All the messages should have appeared to local folder as they were in IMAP inbox. Local folders are in directory D:\Mail. This also happened with Mozilla 1.3.1. I noticed this recently. Before that the same setup worked correctly. Might be server problem too. Not tested with other email clients.

Reporter: could you try this using a recent nightly build from <http://ftp.mozilla.org/pub/mozilla/nightly/latest/> ? If it works, please resolve this bug as WFM. Thanks !

Mozilla 1.5b [Mozilla/5.0 (Windows; U; Windows NT5.1; en-US; rv:1.5b) Gecko/20030821] seems to work correctly so far. Server is Washington IMAP 4 running on Sun Netra 1, Solaris 2.6 (according to our administrators)

This bug was never gone. I just could not reproduce it for a while. But now it is back and worse than before. It is now reproduced in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Additional information: I now always COPY mail from IMAP to local Temp to check if they are copied correctly. If copying is okay, I move them from temp to local inbox and delete them from imap inbox. Otherwise I would have lost quite many mails. If the error happens with certain collection of inbox messages, trying immediately again does not help. It produces exactly same result in destination. I can sometimes work around this by selecting smaller collection of mails and copy them separately. Sometimes copying every message separately is needed to workaround this bug, sometimes even that doesn't help. Then usually restarting Mozilla helps. Sometimes copying does not copy the whole mail (there is wrong number in Size-column). For example some JPEG attachments are missing pixel lines from the bottom. So I have to carefully check every time that the whole mail has been copied - very tricky. I have also noticed that saving attachments of messages in IMAP INBOX sometimes result a partial file saved (file size is smaller than it should). I have not been able to reproduce this with MS Outlook Express with exactly the same mail mesages in exactly same IMAP server so I thing the failure is in Mozilla Mail rather than in server. I really hope this can be fixed, otherwise I have to consider swithing to old fashioned POP-protocol or completely switch my mail client.

Heikki, can you try a 1.6 trunk build from tomorrow and let me know if it still happens with that build? Also, if it does, an imap protocol log could be useful: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap you can mail it to me if it's too big or too private to attach to this bug. thx, - david

I now repeated the bug with 1.6a: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031028. In the attachment zip files there are screenshots of the copy operation results - this time both two mail messages were corrupted. In the zip file there is also a imap log file of that same copy operation in screenshots. My companys email-server and mail addresses have been cencored both in screenshots and logfile (find and replaced with "ourcompany.com"). I hope it doesn't prevent finding the bug.

please see previous attachment

there's something weird going on with the server here: 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: * 2 FETCH (UID 423 RFC822.SIZE 1236926 BODY[]<0> {12288} the server tells us that the message is 1236926 bytes long but as we fetch the message in chunks, part way through the message, the server stops giving us data: 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:SendData: 27 UID fetch 423 (UID RFC822.SIZE BODY[]<167936.28672>) 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=59 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: * 2 FETCH (UID 423 RFC822.SIZE 1236926 BODY[]<167936> "") 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=27 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: 27 OK UID FETCH completed 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:SendData: 28 UID fetch 423 (UID RFC822.SIZE BODY[]<196608.30720>) 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=59 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: * 2 FETCH (UID 423 RFC822.SIZE 1236926 BODY[]<196608> "") 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=27 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: 28 OK UID FETCH completed 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:SendData: 29 UID fetch 423 (UID RFC822.SIZE BODY[]<227328.32768>) 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=59 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: * 2 FETCH (UID 423 RFC822.SIZE 1236926 BODY[]<227328> "") 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=27 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: 29 OK UID FETCH completed 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:SendData: 30 UID fetch 423 (UID RFC822.SIZE BODY[]<260096.34816>) 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=59 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: * 2 FETCH (UID 423 RFC822.SIZE 1236926 BODY[]<260096> "") 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=27 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: 30 OK UID FETCH completed 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:SendData: 31 UID fetch 423 (UID RFC822.SIZE BODY[]<294912.36864>) 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=59 needmore=0] But, but, but, you say, this works on other clients. That might be because other clients don't fetch messages in chunks. To be honest, we shouldn't be fetching this message in chunks either because the fetch is to copy the message to another folder, which should just fetch the whole message. Here's one thing to try: set the per server pref fetch_by_chunks to false so something like user_pref("mail.server.hostname.fetch_by_chunks", false); then shutdown and restart and try this again. I suspect the messages are corrupt on the server, so I'm not sure this will help, but it's worth a try (and generating a new log of what happens with this pref set would be informative). If that helps, I'll try to figure out why we're still fetching by chunks when copying to another folder. Thx, please let me know what happens.

I take back some of what I said - things are even worse on your server. The first entries in the log were just from clicking on the messages. The entries in the log to copy the messages to the local folders show that the server isn't giving us any data at all. Is it possible that this imap server (what is the server, btw?) doesn't handle .PEEK at all? 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:ProcessCurrentURL:imap://hke@mailserver.ourcompany.com:143/fetch%3EUID%3E/INBOX%3E422:423: = currentUrl 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:SendData: 54 UID fetch 422:423 (UID RFC822.SIZE BODY.PEEK[]) 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=48 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: * 1 FETCH (UID 422 RFC822.SIZE 8303 BODY[] "") 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:STREAM:OPEN Size: 8303: Begin Message Download Stream 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:STREAM:CLOSE: Normal Message End Download Stream 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=51 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: * 2 FETCH (UID 423 RFC822.SIZE 1236926 BODY[] "") 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:STREAM:OPEN Size: 1236926: Begin Message Download Stream 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:STREAM:CLOSE: Normal Message End Download Stream 2560[22b9fa8]: ReadNextLine [stream=21e56c0 nb=27 needmore=0] 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:CreateNewLineFromSocket: 54 OK UID FETCH completed 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:ProcessCurrentURL: entering 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:ProcessCurrentURL:imap://hke@mailserver.ourcompany.com:143/select%3E/INBOX: = currentUrl 2560[22b9fa8]: 2297890:mailserver.ourcompany.com:S-INBOX:SendData: 55 noop

I have run into the same problem. I created some new folders today and started moving mail into it. Suddenly I realized the mail was NOT being moved...here is the scenario... 1. Search for some messages I want to move (ie: type metreon in the search box) 2. Select all the messages that pop up 3. Drag and drop them into the folder (messages disappear) 4. Search for "metreon" in inbox again, messages reappear. 5. Look in the folder I dragged them to, messages are not there. This was on the tail end of a session where I moved and deleted a lot of mail (about 400 messages). After this happened I looked around and discovered some of the mail I had moved was simply GONE, it didn't exist in any folders anywhere. This seems like a very SERIOUS problem. I'm running on an IMAP server provided by Lotus Notes...sorry the log files were not turned on at the time but I'm turning them on now. Not sure if I can repeat the failure or not. This is on Mozilla 1.5 (mozilla-i686-pc-linux-gnu-1.5-sea.tar.gz) with EnigMail as the only plug-in. It's on RedHat 8.0 Linux. The (redhat) version of mozilla is still installed but is in a totally different directory and hasn't been used since 1.5 was installed.

FYI...I haven't been able to reproduce the error yet, but in case it is useful here is the server version information from the IMAP server log. 98310[911a868]: ImapThreadMainLoop entering [this=9111e78] 16384[80bee10]: 9111e78:imap.server.i.use.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN 98310[911a868]: 9111e78:imap.server.i.use.com:NA:ProcessCurrentURL: entering 98310[911a868]: 9111e78:imap.server.i.use.com:NA:ProcessCurrentURL: creating nsInputStreamPump 98310[911a868]: 9111e78:imap.server.i.use.com:NA:ProcessCurrentURL: setting IMAP_CONNECTION_IS_OPEN 98310[911a868]: ReadNextLine [stream=911aed0 nb=0 needmore=1] 98310[911a868]: ReadNextLine [stream=911aed0 nb=73 needmore=0] 98310[911a868]: 9111e78:imap.server.i.use.com:NA:CreateNewLineFromSocket: * OK Domino IMAP4 Server 5012HF37 ready Thu, 6 Nov 2003 17:49:47 -0800^M 98310[911a868]: 9111e78:imap.server.i.use.com:NA:SendData: 1 capability^M 98310[911a868]: ReadNextLine [stream=911aed0 nb=0 needmore=1] 98310[911a868]: ReadNextLine [stream=911aed0 nb=55 needmore=0] 98310[911a868]: 9111e78:imap.server.i.use.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 AUTH=LOGIN AUTH-LOGIN LITERAL+^M 98310[911a868]: ReadNextLine [stream=911aed0 nb=27 needmore=0] 98310[911a868]: 9111e78:imap.server.i.use.com:NA:CreateNewLineFromSocket: 1 OK CAPABILITY completed^M 98310[911a868]: 9111e78:imap.server.i.use.com:NA:SendData: 2 authenticate login^M 98310[911a868]: ReadNextLine [stream=911aed0 nb=0 needmore=1] 98310[911a868]: ReadNextLine [stream=911aed0 nb=16 needmore=0] 98310[911a868]: 9111e78:imap.server.i.use.com:NA:CreateNewLineFromSocket: + VXNlcm5hbWU=^M 98310[911a868]: 9111e78:imap.server.i.use.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information) 98310[911a868]: ReadNextLine [stream=911aed0 nb=0 needmore=1] 98310[911a868]: ReadNextLine [stream=911aed0 nb=16 needmore=0] 98310[911a868]: 9111e78:imap.server.i.use.com:NA:CreateNewLineFromSocket: + UGFzc3dvcmQ=^M 98310[911a868]: 9111e78:imap.server.i.use.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information) 98310[911a868]: ReadNextLine [stream=911aed0 nb=0 needmore=1] 98310[911a868]: ReadNextLine [stream=911aed0 nb=29 needmore=0] 98310[911a868]: 9111e78:imap.server.i.use.com:NA:CreateNewLineFromSocket: 2 OK AUTHENTICATE completed^M 98310[911a868]: 9111e78:imap.server.i.use.com:A:SendData: 3 lsub "" "*"^M

I added this line: 'user_pref("mail.server.server1.fetch_by_chunks", false);' to C:\Documents and Settings\myaccount\Application Data\Mozilla\Profiles\myaccount\abc123.slt\prefs.js -file as the last line of user_pref("mail.server.server1 -lines. And gues what - I could NOT reproduce the bug anymore with exactly the same mail messages. So keeping that line there seems to solve this problems so far! So you was right, David. Thanks! Now opening the mail with big JPEG attachment takes longer time and it becomes visible as a whole. Previously it just loaded the upper part of that JPEG (as you can see from the screenshot (comment #6). Our server is mentioned in comment #2, but I don't know version. So what state should this bug be given now?

It's still a server bug, but just to be sure, could you attach a log of opening/copying that message with that fetch_by_chunks pref set the way you have it now? thx.

I just noticed that this bug refers to copying from IMAP folders to a local folder. My problem was copying from an IMAP folder to another IMAP folder. Is this likely to be the same issue? Also, all the messages I lost were relatively small ones (one or two K, no enclosures) Would you recommend I also set the "fetch by chunks" option to false? Is there any way to test for a server for this problem without actually having to lose mail in the process? Or for that matter, is there a way to check other mail clients to see what mode they are using? Greg

Greg, if you were copying messages between folders on the same server, that's really a server issue. Copying messages between folders on a server works the same on all imap clients, I would think, since it just uses a Copy command followed by STORE of the deleted flag. There's no message fetching involved.

David, I'm not an IMAP expert, but what if the copy failed and the store of the deleted flag did not? Would this normally generate an error message of some kind or could it happen silently? This might explain the other behavior I mentioned in comment 9, where I would copy a message from one folder to another, look in the new folder, not see it, then look in the old one to find it still there. If both the copy and store silently failed, this would be the result. It may be our mailserver was going bonkers. I found it kind of surprising that this sort of error could happen without an error message of some kind from somewhere. I'd really like to try and confirm if this problem was a server glitch or some kind of client incompatibility issue (like the fetch-by-chunks thing) so we would know if it's safe to use the Mozilla mail client. If Mozilla mail would normally generate error messages in a case like this (I didn't see any) then it seems likely the server is at fault.

if the copy failed, the server should tell us. If the server told us the copy failed, we should both put up the message returned by the server, and not do the store of the deleted flag. If the server fails silently, then all bets are off :-( To find out what's going on, I can't think of anything besides generating a client-side protocol log and see if the server is returning any kind of error. That would require being able to reproduce the problem, though.

David, I should have a backup copy of my E-Mail by monday, I will attempt to reproduce the error and let you know. I already have Mozilla logging turned on. For what it's worth, our Lotus admin says the only log files they have are error logs and she was not notified of any errors occuring during the time I had my problems. If it's of any help, my inbox is big (4400 messages) and I was doing search operations followed by select, drag and drop in new folder when it happened. I'll tell you if I can reproduce the thing.

Here is a log produced with fetch_by_chunks=false -setting. Mail messages are the same and same sequence is performed with UI as in my previous log. Client is also the same Mozilla 1.6a Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031028. I deleted over 60000 similar lines concerning fetching the big JPEG attachment in another mail. I think the best way to deal with this bug/feature is to add some kind of server bug detection to Mozilla Mail - if possible - and inform the user about the bug in the server and automatically go to fetch_by_chunks=false -mode. Losing mail is something people do not want to happen and they surely consider swithing email-client if this kind of bug happens only with certain mail client. BTW, why is mozilla mail copying messages in chunks?

I don't believe it's a problem in general with that server - just your particular installation or even just your mailbox on that server. As I said before, we're not using fetch by chunks for message copying; we're using peek, as you can see from the log. We're using fetch by chunks to display messages, and from the log it looks like you're displaying the messages before copying them. All I can guess from the log is that fetching a message by chunks and then using PEEK on it is getting your server confused such that it can't copy any data. If you turn off fetching by chunks, and then collapse the message pane by clicking on the splitter between the message pane and the thread pane, and then select the messages you want to copy and copy them, does it work then? If my theory is right, that should work, because you didn't display the messages before copying them, because the message pane was collapsed. There is a bug in the mozilla imap code, however. We should notice that we're not getting any data back from our requests and abort the copy operation. Ideally, when fetching by chunks, we should also notice that we're not getting any data back and fall back to normal fetching. I'm not sure if that would help your situation, however (it's hard to reason about what might happen with your server because it seems so broken - just the act of fetching by chunks seems to get it confused and I'm not sure that going back and fetching the whole message would help...). I could be misreading the logs, but I don't think so. I'm willing to try to make these changes but it would be really helpful if you could help test since I don't have access to a server that's doing this...

I removed fetch_by_chunks=false -line from prefs.js-file and did the test you mentioned (collapsing message pane before contacting server) and the result was that copying worked fine as you predicted. This can be achieved also by clicking Inbox folder in the folders-pane and then pressing Ctrl+A (select all) -> message contents are not shown before copying. In fact this was the method I used in comment #3 (paragraph 3) when I talked about need to restart Mozilla before copying went okay. So this seems to confirm your theory. I can test your patch, just tell me which version to download. :)

is everything here a server issue (and thus not mozilla)?

I don't know if the problem still exists. I lost my confidence to the setup and switched to POP protocol, and did not have those problems anymore. Now our company has switched to Exchange server so I'am not able to test the IMAP server anymore. But my opinion: This should be fixed in the Mozilla Mail/Thunderbird, because the operation fails silently and data is lost. So when this bug happens it causes BIG DAMAGE! At least the user should be given a warning that the server is not working properly. At the same time MS Outlook Express did not have any problems with the particular server. I'am still using Thunderbird with IMAP account in another server for my personal email and I haven't had any problems with it.

This bug is still present in Thunderbird 2.0.0.12, and in Seamonkey 1.1.8. I have encountered this one with two different mail servers, one of them being a University server where I do not think that it is a server issue. The symptoms are the same as described above: When moving mails (several hundred) from an IMAP to a local folder, the mails are removed from IMAP, but the local folder only contains empty messages, dated either to the current time of day (no date/month/year) or to something in 1969/1970. This is an extremely severe bug, since it results in immediate data loss of all mails that are being moved. I suggest it should be listed in the "known problems" section of the release notes.

Another update: I tried setting user_pref("mail.server.server1.fetch_by_chunks", false) in the prefs.js of Thunderbird, and it did not help - the problem still occurs. It is hard to reproduce, since with the same set of mails, sometimes the copying works, and sometimes it does not. I do not see a pattern yet.

Hi, more details on this bug - it does not only appear when moving mails from IMAP to Local Folders, but also when moving mails between IMAP folders on the same account. It appeared when I was deleting mail on an IMAP account (i.e., moving mail to the Trash folder), after going online again, the trash contained "empty" emails dated December 31, 1969, 7:00pm (I am in the NY time zone, so this would be January 1, 1970 GMT, I guess). I am not sure if the mails were already there before I went online, I did only notice that after going online again. It seems that something weird is going on here, as if the IMAP "Move Mail" command is not used, but some manual copying is happening instead. This bug is reallyproblematic for me, if there is any way I can help getting it fixed, let me know. It is also hard to reproduce, I only encountered it when moving lots of mail.

(In reply to comment #25) > Another update: I tried setting > user_pref("mail.server.server1.fetch_by_chunks", false) > in the prefs.js of Thunderbird, and it did not help - the problem still occurs. You typed "server1" in "...server1..." part? "server1" is usually for pseudo account of "Local Folders". Put correct server number for your IMAP account in "...server1..." part. (In reply to comment #26) > but also when moving mails between IMAP folders on the same account. >(snip) > It seems that something weird is going on here, as if the IMAP "Move Mail" > command is not used To Henning Schnoor: What do you mean by 'IMAP "Move Mail" command'? I can't find it in RFC for IMAP : http://www.faqs.org/rfcs/rfc3501.html AFAIK, "Move of a mail between 2 mail folders of same IMAP account" is (1) FETCH, (2) COPY to another folder, (3) flag as \Deleted(by STATUS etc.), and (4) finally EXPUNGE when requested. Have you checked IMAP protcol log? > the trash contained "empty" emails dated December 31, 1969, 7:00pm > (I am in the NY time zone, so this would be January 1, 1970 GMT, I guess). This is similar phenomenon to one when Bug 368112 / Bug 405440 on manual move. Bug 368112 : verified1.8.1.4 i.e. fixed by Tb 2.0.0.4 Bug 405440 : verified1.8.1.12 i,e. fixed by Tb 2.0.0.12 Similar phenomenon is also observed when Bug 398498 occurs(copy&move by message filter fails. still open). Your case sounds to be "Move failure due to incorrect RFC822.SIZE by your IMAP server. And perhaps longer RFC822.SIZE case as written in comment #7, because Bug 92111 (for MS Exchange) or Bug 390795 (for non Exchange) usually occurs if shorter RFC822.SIZE.

Hi WADA, thanks for taking the time to look into this. I checked that the number of the server refers to the real mail server I am using, my servers seem to be numbered in a different way for some reason. What I meant with "Move Mail" command is that when you move a mail in Thunderbird, the program does not simply seem copy the message into the destination folder - when on a slow internet connection and moving messages with large attachments, it takes faster than a re-upload would. Therefore I concluded that the client simply tells the mail server to move the message, without complete down+upload. I have looked into the bugs you mentioned, and I do not believe this is the same issue (though very possibly very related) for the following reasons: 1. The above bugs do not mention the "fake messages" dated 1970 to appear, 2. I have encountered this problem on two different servers using different software (one commercial server, and one university mail server), so I do not believe that this is a server issue, 3. My problem is not related to attachments, in appears also when moving very small messages (though I have encountered the attachment problem as well), 4. Two of the bugs mentioned above have been verified fixed in Thunderbird 2.0.0.12, which is the version I am using (and used to create the profile with that leads to these problems). I will try to get some IMAP logs for the problem, but since the bug is hard to reproduce, I am unsure if this will work out. Thanks for your time, Henning

You might also try TB 3.0 beta 3.

I have not been able to reproduce this using the current beta of TB3, but the bug is difficult to reproduce even with TB2. Has there been any work on this bug that went into TB3? Thanks, Henning

(In reply to comment #30) > I have not been able to reproduce this using the current beta of TB3, but the > bug is difficult to reproduce even with TB2. Has there been any work on this > bug that went into TB3? I can think of one bug recently fixed that may help, but it's not in beta 3. So if the problem was hard to recreate, I would suggest keeping this open until after TB3 ships. bienvenu & wada may be able to give more detail.

bienvenu, WFM per comment 30? Or is something still needed per comment 19: "There is a bug in the mozilla imap code, however. We should notice that we're not getting any data back from our requests and abort the copy operation. Ideally, when fetching by chunks, we should also notice that we're not getting any data back and fall back to normal fetching.

bienvenu, ping (comment 32)

(In reply to Wayne Mery (:wsmwk) from comment #33) > bienvenu, ping (comment 32) This is a fairly broken server not implementing the IMAP RFC correctly, not returning data we ask for, and not returning an error either. I tried copying an imap message to a local folder and it didn't fetch by chunks, even though it was a large message, so I suspect that issue is fixed.

so I believe you are saying this is invalid