Closed Bug 216442 Opened 21 years ago Closed 13 years ago

group move of messages from IMAP Inbox to local folder loses mails. fetching a message by chunks and then using PEEK on it confuses server

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: heikki.a.keranen, Assigned: Bienvenu)

References

Details

(Keywords: dataloss)

Attachments

(3 files)

IMAP log and screenshots after copy operation
134.44 KB, application/octet-stream
Details
Screenshots after copy operation
191.10 KB, application/octet-stream
Details
log when fetch_by_chunks=false
15.03 KB, application/octet-stream
Details 
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)
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Status: NEW → ASSIGNED
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. :)
Product: MailNews → Core
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.
Status: ASSIGNED → NEW
Keywords: dataloss
OS: Windows XP → All
QA Contact: grylchan → networking.imap
Hardware: PC → All
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
Product: Core → MailNews Core
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)
Summary: group move of messages from IMAP Inbox to local folder loses mails → group move of messages from IMAP Inbox to local folder loses mails. fetching a message by chunks and then using PEEK on it confuses server
(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
Status: NEW → RESOLVED
Closed: 21 years ago → 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: