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

[Matthias A. <mat...@gm...>]

Sunil Shetye <sh...@bo...> writes:

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

I wonder. This code is ESR's original 

-----
r3829 | esr | 2003-07-22 04:32:07 +0200 (Di, 22 Jul 2003) | 2 lines

Support faked IDLE.
-----

(straight from SVN)

and has apparently never worked.

So right, gen_transact() followed by imap_ok() deserves more commentary
than just:

  3829        esr       /* wait (briefly) for an unsolicited status update */
  3829        esr       ok = imap_ok(sock, NULL);
  3829        esr       /* again, this is new mail or an error */
  3829        esr       if (ok != PS_IDLETIMEOUT)
  3829        esr           return(ok);

It appears that letting imap_ok time out is deliberate here, this is in
line with setting the timeout to 28 seconds and ignoring
PS_IDLETIMEOUT.

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

So the only question that remains is if fetchmail loses an entirely
asynchronous RECENT reply, or will pick it up next time waiting for the
tagged NOOP response, right?

-- 
Matthias Andree