A BUGNOTE has been added to this bug.
======================================================================
http://www.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:                     new
======================================================================
Date Submitted:             19-Aug-04 14:03 CEST
Last Modified:              20-Aug-04 13:58 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..

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                       
======================================================================

Reply via email to