[fetchmail-users] [PATCH] Re: Bug in imap_idle() with mail servers not supporting "idle"

[Sunil S. <sh...@bo...>]

Quoting from Brendan Lynch's mail on Thu, Mar 02, 2006:
> However I believe the servers is behaving correctly according to the 
> IMAP spec: I have attached an explanation of the secondary problem I am 
> seeing (extra 28 s wait) that I sent to Casper; let me know if you need 
> more info.

Yes, I have now read RFC 3501 section 5.3. This behaviour is correct.

> The key point is that the imap_idle() code when 'faking' IDLE support 
> calls imap_ok() (at line 637) without having issued any tagged command:

...

> Since there is no tagged command outstanding the server will not (and 
> should not) ever send a tagged response.  If we set imap_ok to only 
> return after a tagged response we are guaranteeing it will always only 
> return after a timeout.

...

> This again first does a gen_transact() which results in sending "A0130 
> NOOP" at 17:00:49.  A "RECENT" update is already on its way form the 
> server, so we receive it before the "A0130 NOOP completed" at 17:00:49.  
> In imap_ok() we first process the "* 1 RECENT" notification at line 117, 
> setting recentcount, then (since we ARE waiting a tag) loop and process 
> the NOOP ok.  we then return to gen_transact(), which in turn returns to 
> imap_idle().
> 
> Since setting "recentcount" does not also change the stage, we fail the 
> test at line 633 of imap_idle() and continue to do an extra imap_ok() 
> which sets a 28 second timer at 17:00:49 and does a recv() which times 
> out at 17:01:17.  We then return from imap_idle() to imap_getrange() 
> line 679.  At this point recentcount is set and we exit the "while 
> (recentcount == 0 && do_idle)" loop.
> 
> The wait between 17:00:49 and 17:01:17 was unnecessary, as already had 
> our RECENT notification.  The second part of my fix causes imap_ok() to 
> change the stage to STAGE_FETCH on receipt of a RECENT notification, 
> just as it already did on receipt of a EXISTS notification. This causes 
> the if condition "if (ok != 0 || stage != STAGE_IDLE)" to be met at line 
> 633 of imap_idle() so it immediately exits and does not do the extra 
> unneeded imap_ok() call.

Yes, you have diagnosed the problem correctly and your patch is also
correct. Based on your patch, I have prepared a new patch which does
not modify imap_ok(), but cleans up the code in imap_idle(). Could you
test this patch and see if this patch is acceptable to you? This patch
is identical to the patch I had sent to Casper Gripenberg, except that
comments relating to compliance with RFCs have been updated.

-- 
Sunil Shetye.