User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 Build Identifier: Version 2.0.0.6 (20070728) System Description: Client: Windows XP, actually patches Server: SuSE Enterprise 9, Courier IMAP 4.1.1 After Thunderbird 2.0.0.6 works proper suddenly a sended mail is not copied in to the sent-mail folder. Workaround-1: - The Sending Messages dialog appears 60 minutes, if i take this time. After 60 minutes i received the message: "message Cant be Copied into folder sent-mail" CANCEL OR RETRY - After pressing Cancel, the dialogbox: "Sending of message is failed" The message was sent successfully, but copy to the folder was failed" Would you go back to compose the message? OK or CANCEL - If i choose OK i receive the following messagebox 3 times Warning This Mail Server "mail1.uniklinik-freiburg.de" is not a IMAP-4-Server OK (note: our imap server is a IMAP-4 Server) - Now i get the message compose dialogbox, i can save the message as draft, can open it and may be send another time, sometimes succesfully, sometimes the error repeads Workaround-2 - The Sending Messages dialog appears after some minutes i cancel the copy proccess. - Now i returned to the Thunderbird main window, but now the mousepointer is a hourglass - often i can open the mailfolders by clicking the folder symbols in the left colum, the messages in the right window appears and i i choose a message i get the message text - sometimes this dos not works - i have to close Thunderbird and restart it See the attached dialog Reproducible: Sometimes Steps to Reproduce: 1. Start and wait between some minutes or some hours 2. havent found a way to force the error There are may be other bugreports in the same way: - Bug No. 206408, 298229, 392622, 390136, 380238, 382912, 378735, 376518, ...? We cant migrate to Thunderbird 2.x until this error occured.

Mousepointer appears as an hourglass

Error Messagebox - Message could not copied to folder sent-mail

2. Messagebox - Sending Message failed: Message was sending successfully but copy to folder sent-mail had failed.

This Error Message appears 3 times

Suddenly thunderbird has the described sendind problem, from this moment on, the mouspointer appears as an hourglass, maybe mails are listed and mailtext is shown in the upperwindow, but after a while these funktions also failed. Copy as draft is also impossible

Does the Sent folder exist? Connection problems perhaps? I get the This Mail Server "<server>" is not a IMAP-4-Server error message occasionally when the connection fails.

There are nearly 3.000 Thunderbird Users working with Version 1.5.10, only the Users we have migrated to Version 2.0.0.6 have this problems. We have 5 mail servers (over 5.000 mail accounts) and the problems occurs only with Thunderbird Version 2.x, never mind which server is used. If we are using the 1.5.x Version and the 2.x on the same Client, the Problems we have only with the 2.x. So its most probable there is a problem by thunderbird itselves. (In reply to comment #6) > Does the Sent folder exist? > > Connection problems perhaps? I get the This Mail Server "<server>" is not a > IMAP-4-Server error message occasionally when the connection fails. >

Please prefix bug numbers with "bug" to get them auto-linked, like bug 206408, bug 298229, bug 392622, bug 390136, bug 380238, bug 382912, bug 378735, bug 376518. See esp bug 392622 comment 3. Since you are the server admin(?), maybe you can check the case of those user's sent folders. For trouble shooting, it would be good to get a log for when the error happens. See http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap and use SET NSPR_LOG_MODULES=imap:5,smtp:5

It dont looks like a Problem of name to the folder, because Thunderbird 2.x works fine - i can send mails and copies will be stored in the sent-mail folder. But after a while this error occurs. We can proceed from the assumption that the problem has to be by Thunderbird 2.x, i cant ignore that a) the problem does not exist with Version 1.5.x b) Thunderbird 2.x works for a while, and then the errors appears But i can create a log file on the imap-server for further informations. (In reply to comment #8) > Please prefix bug numbers with "bug" to get them auto-linked, like bug 206408, > bug 298229, bug 392622, bug 390136, bug 380238, bug 382912, bug 378735, bug > 376518. > > See esp bug 392622 comment 3. Since you are the server admin(?), maybe you can > check the case of those user's sent folders. > > For trouble shooting, it would be good to get a log for when the error happens. > See http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap and use > SET NSPR_LOG_MODULES=imap:5,smtp:5 >

I've been seeing this with TB version 3.0a1pre (2008030903) Linux, therefore confirming. I've not been getting an error, though I haven't always waited that long, but it has been doing it at random times (possibly after TB has been left alone a while?). So I've had to cancel out, and that doesn't complete saving the email. This is an imap server as well btw. I'll try and get a log of it sometime soon. Requesting blocking tb 3 as its happened to me enough times to be annoying and could be a usability issue.

I've now had this a few more times and figured out the problem. Steps to reproduce: 1) Start thunderbird, access imap account as normal. 2) Let connection drop (e.g. turn off router for a while). 3) Re-establish connection, access to imap account ok. 4) Send email, email sends, but stops on the "Copying mail to sent folder" dialog. The logs seem to indicate that the connection to the imap server is detected and broken, so it tries to re-initiate. It gets up to the subscribe to the sent folder option (which succeeds) but nothing happens after that.

The Problem seemed to be solved with the new version 2.0.0.12. So i close this bug report now.

(In reply to comment #12) > The Problem seemed to be solved with the new version 2.0.0.12. So i close this > bug report now. > Reopening, I am still seeing this on Trunk at least, I do not believe this has been solved or fixed (see my comment 11). Additionally I think I also reproduced it with saving a message to drafts the other day as well.

assuming the STRs are good, agree this should be fixed.

The problem is solved with version 2.0.0.12, so i close the bug report.

That would have been WORKSFORME, but let's repeat comment 13, and reopen ;) Please don't close it again.

Bug 298229 and Bug 28211 are related.

Mark, are you still seeing this? I tried with the STR, and didn't have a problem.

(In reply to comment #18) > Mark, are you still seeing this? I tried with the STR, and didn't have a > problem. I've just tried again and it seems fine now, so let's close this and see how it goes.

I knew there was something. Try turning off the select this folder for offline use setting - then I can reproduce it.

if that's the case, I don't think many users will run into this since we've changed the default so that all imap folders are selected by default. Taking bug; I'll try to reproduce it when I get a chance.

I can reproduce something similar, to some extent, not every time, but sometimes. I suspect the key is to have several cached connections, and then disconnect the router, so they all become invalid, and then re-connect and send. In some situations, we won't realize the connection is dead (we do check, but that check isn't reliable), and we'll try to run the url. That will eventually fail, and then we'll retry. If you have several cached connections, we will try to use an other cached connection, and that too will fail. We then ask the user if they want to retry, and that also fails. This wouldn't really explain what Mark saw - we shouldn't need to resubscribe to the Sent folder, for example. We could try to treat some network errors as indicators that all the cached connections are bad, and prefer using a new connection over a cached one. But that would be exactly the wrong strategy for the MAXPERIP case, where we really want to use a cached connection because we can't make new ones.

Standard8, a protocol log of your situation might be helpful.

From Standard8's protocol log, the following is happening: the router is disconnected biff comes along, re-uses an existing connection, and gets a timeout error we retry biff, by trying to create a new connection; this time, we get an unknown host error the router is reconnected we try to copy a message to the sent folder, using an existing connection, in the selected state on the trash folder - it gets an 80004004, error abort, because the user cancelled. Then, we kill all the other existing connections because of timeout errors, 804b000e. That's part of shutdown, because we were trying to send a close to the server for each of those. It looks to me like we're simply not getting any response from necko to our APPEND command. This should timeout after 100 seconds. 100 seconds is way too long to wait for this, but it's about right for some other things. We could use a shorter timeout when waiting for the server to respond to the APPEND request; I'd have to go look at how the timeout code works.

Standard8, can you try this patch? It changes the network timeout for APPEND urls to 20 seconds instead of the default 100. I'm a little wary of changing the default 100 for all operations because of the bug where we retry move/copies if they timeout, and some servers take longer when you move/copy a large number of messages.

I think one way or another, this bug will be off the b1 blocker list in a few days. It's not a regression. We'd love to improve this experience for b1, and maybe the timeout change will help. In my experience trying to recreate this, if I power down my router for a very short amount of time, Windows doesn't realize it has lost the connection, and that causes the timeout down the road. If XP realizes the connection has gone down, then our cached connections get killed because we get the offline status notifiation and don't try to use bad connections.

Comment on attachment 348779 [details] [diff] [review] patch to try If this patch actually makes this problem hurt less, then I'm ok with it being a bit of a silly hack.

Comment on attachment 348779 [details] [diff] [review] patch to try This does improve the situation, I think when I tested it just now, for some reason it decided to timeout twice, so it actually took 40 seconds ish to sort itself out. One thought I have had whilst testing this. If we switch sending to the activity manager, then it won't matter so much that we have this hanging will it? So we could potentially leave the timeout as it is, and it'll just clear in the background eventually.

We may have retried with a second bad connection, resulting in two timeouts. Even with the activity manager, I think it's better to have the send succeed sooner rather than later, e.g., if the user wants to shut down the app.

Comment on attachment 348779 [details] [diff] [review] patch to try Ok, let's go with this then. One nit: + if (m_imapAction == nsIImapUrl::nsImapAppendMsgFromFile + || m_imapAction == nsIImapUrl::nsImapAppendDraftFromFile) We normally put the || on the end of the previous line...

fix checked in.

this introduced a regression - bug 466507