The following bug has been CLOSED
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000066
======================================================================
Reported By: ilja
Assigned To: ilja
======================================================================
Project: DBMail
Bug ID: 66
Category: IMAP daemon
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
======================================================================
Date Submitted: 19-Aug-04 14:03 CEST
Last Modified: 25-Aug-04 14:17 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.
----------------------------------------------------------------------
ilja - 23-Aug-04 15:19 CEST
----------------------------------------------------------------------
I'll do the quickfix then:
The counter is reset after MAX_FAULTY_RESPONSES on every correct command.
----------------------------------------------------------------------
ilja - 23-Aug-04 15:20 CEST
----------------------------------------------------------------------
fixed using following method:
if a user enters a valid command, the nfaultyresponses counter is reset to
0.
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
23-Aug-04 14:44ilja Assigned To => ilja
23-Aug-04 14:44ilja Status confirmed => assigned
23-Aug-04 15:19ilja Bugnote Added: 0000187
23-Aug-04 15:20ilja Bugnote Added: 0000188
23-Aug-04 15:20ilja Resolution open => fixed
23-Aug-04 15:20ilja Status assigned => resolved
25-Aug-04 14:17ilja Status resolved => closed
======================================================================
