[fetchmail-devel] Re: BUG (?) fetchmail 6.3.2 hangs with 'idle' on OpenBSD

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

Quoting from Casper Gripenberg's mail on Tue, Feb 28, 2006:
> Ok. Here's what happens with your patch:
> 
> fetchmail: IMAP> A0014 NOOP
> fetchmail: IMAP< A0014 OK NOOP completed
> fetchmail: IMAP> A0015 NOOP
> fetchmail: IMAP< * 1 EXISTS
> fetchmail: IMAP< * 1 RECENT
> fetchmail: IMAP< A0015 OK NOOP completed
> fetchmail: 1 message waiting after re-poll
> fetchmail: IMAP> A0016 SEARCH UNSEEN NOT DELETED
> fetchmail: IMAP< * SEARCH 1
> fetchmail: 1 is unseen
> ...
> 
> To me it looks like you are deliberately sleeping instead
> of "NOOP":ing. To get the EXISTS message to appear after
> the NOOP, right? In that sense I like my fix better, because
> it returns the mails immidiately. Your fix introduces an 
> unnecessary delay(?), but in the debug output it does
> now looks like everything is working like it should. 

Well, I am still "NOOP"ing. There is a problem in the current code.
What is happening is that gen_transact() is being followed by
imap_ok(). Internally, gen_transact() calls gen_recv() which calls
imap_ok(). So, imap_ok() is being called twice! The second call to
imap_ok() is incorrect as there is actually no "tag" to compare. So,
replacing imap_ok() by sleep() is the right thing to do.

As far as the delay part goes, even with IMAP servers supporting IDLE,
a delay of one minute is expected as IMAP servers checkpoint the
folder every one minute or so. Of course, it will actually depend on
the IMAP server configuration and implementation, but the point is
that a small delay is acceptable. Here, the maximum delay will be 28
seconds, which should be acceptable.

Could you log to syslog and send the output (with your patch)? I want
to see the time aspect of this. In particular, I want to see if there
is a delay between the "NOOP" response and the "EXISTS" response. If
there is a delay, then your average delay will actually be 14 seconds.

The problem with your patch is that it forces recentcount to be equal
to count. You have a simple setup where all mails are always
downloaded and deleted from the server. In this scenario, the number
before EXISTS and RECENT will always be equal. However, there are
people who have a setup where some seen mails are there on the
mailserver and fetchmail is running with "no fetchall". So, forcing
recentcount to count is not correct.

Note that your server is sending the "EXISTS" response asynchronously,
but fetchmail requires the "RECENT" response to come out of the idle
loop. Your server is anyway sending "RECENT" only as a reply to the
next "NOOP" command. So, as far as fetchmail is concerned, there is no
delay anyway.

-- 
Sunil Shetye.