A BUGNOTE has been added to this bug. ====================================================================== http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000066 ====================================================================== Reported By: ilja Assigned To: ====================================================================== Project: DBMail Bug ID: 66 Category: IMAP daemon Reproducibility: always Severity: minor Priority: normal Status: confirmed ====================================================================== Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 23-Aug-04 06:36 CEST ====================================================================== Summary: imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed.
This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. ====================================================================== ---------------------------------------------------------------------- aaron - 19-Aug-04 20:21 CEST ---------------------------------------------------------------------- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. ---------------------------------------------------------------------- ilja - 20-Aug-04 12:32 CEST ---------------------------------------------------------------------- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? ---------------------------------------------------------------------- ilja - 20-Aug-04 13:58 CEST ---------------------------------------------------------------------- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. ---------------------------------------------------------------------- aaron - 20-Aug-04 18:13 CEST ---------------------------------------------------------------------- Maybe we should do the quick-fix in that case. I think it still makes sense to disconnect after a several garbage commands in a row. ---------------------------------------------------------------------- danweber - 23-Aug-04 01:46 CEST ---------------------------------------------------------------------- I had a similar problem with this in Mozilla Thunderbird and Outlook clients. This seems to still be unresolved. ---------------------------------------------------------------------- aaron - 23-Aug-04 06:36 CEST ---------------------------------------------------------------------- Dan, is this unresolved with the suggested fix applied, or just in current CVS? I don't think that any fix is in CVS at this time. Bug History Date Modified Username Field Change ====================================================================== 19-Aug-04 14:03ilja New Bug 19-Aug-04 20:21aaron Bugnote Added: 0000170 20-Aug-04 12:32ilja Bugnote Added: 0000171 20-Aug-04 13:58ilja Bugnote Added: 0000172 20-Aug-04 14:56ilja Status new => confirmed 20-Aug-04 18:13aaron Bugnote Added: 0000178 23-Aug-04 01:46danweber Bugnote Added: 0000179 23-Aug-04 06:36aaron Bugnote Added: 0000180 ======================================================================