[imapfilter-devel] IDLE and 'connection reset by peer'

[david mirabito]

Interesting to know, I wasn't aware of the 30 minute mark being part of the standard.

I've applied your patch and here's the output: 
(note the error is actually in socket_secure_read() .. I've changed the message in secure_socket_write())

Let me know if there's anything you'd like me to test.

 - DavidM

$ time imapfilter -v -d
S (4): * OK The Microsoft Exchange IMAP4 service is rC (4): 1000 NOOP
S (4): 1000 OK NOOP completed.
C (4): 1001 CAPABILITY
S (4): 1001 OK CAPABILITY completed.
C (4): 1002 STARTTLS
S (4): 1002 OK Begin TLS negotiation now.
C (4): 1003 CAPABILITY
S (4): 1003 OK CAPABILITY completed.
C (4): 1004 LOGIN "davidm at email.com" *
S (4): 1004 OK LOGIN completed.
C (4): 1005 NAMESPACE
S (4): 1005 OK NAMESPACE completed.
C (4): 1006 STATUS "INBOX" (MESSAGES RECENT UNSEEN)
S (4): 1006 OK STATUS completed.
5890 messages, 0 recent, 0 unseen, in davidm at email.com@exchange.postoffice.net/INBOX.
C (4): 1007 SELECT "INBOX"
S (4): 1007 OK [READ-WRITE] SELECT completed.
C (4): 1008 UID SEARCH ALL HEADER From "<mothra at email.com>"
S (4): 1008 OK SEARCH completed.
<snip other searches>
C (4): 100F IDLE
imapfilter: reading data; violation of protocol

real    5m6.643s
user    0m0.020s
sys     0m0.010s


On 20/01/2010, at 10:57 AM, Lefteris Chatzimparmpas wrote:

> On Wed, Jan 20, 2010 at 10:22:57AM +1100, david mirabito wrote:
>> I did some digging and found where the read on the socket after IDLE
>> is sent has a hardcoded timeout on the select of 29 minutes,
>> independent of the global timeout setting (as I believe it should be).
>> The attached patch adds an optional argument to the enter_idle() lua
>> function (which defaults to 29*60 if not presented, or 0 is passed)
>> and uses that as the timeout instead. With a value of 300, it seems
>> the timeout and re-sending the IDLE is enough to act as a keepalive by
>> iteself. I have successfully been using this for a little over 12
>> hours now, with no disconnect.
> 
> That's interesting.  The 29 minutes select() timeout is there (and
> hard-coded) because the IMAP RFC specifies that servers MUST have an
> idle timeout of at least 30 minutes, and thus 29 minutes between
> refreshing IDLE is enough.  Apparently this server doesn't respect that.
> 
> Also, the global timeout option is there for general timeouts, ie. when
> there is a network problem and some socket function "hangs".
> 
> What we can do is add an IDLE-specific global timeout option, so it will
> configurable the current 29 minutes timeout, to work around
> non-compliant servers.
> 
> But still, please, try the patch, without your changes, I'd like to see
> what's the outcome.
>