Re: imap_idle
On Tuesday, 13 December 2005 at 16:39, Kyle Wheeler wrote:
> Hiya!
>
> So, I tried out the new IDLE code on my bincimap 1.3.4 server (it's
> brand new, and has bugs in it, so this could be a bincimap problem).
>
> I did a mutt -d 9, and got as far as "Sorting mailbox..." across the
> bottom of the terminal, and there, mutt freezes. Here's the relevant
> section from the ~/.muttdebug0 file:
>
> > a0014 IDLE
> < + idling
> Poll failed, disabling IDLE
> mail_addr_is_user: no, all failed.
> ^-- this line is repeated MANY times
> > DONE
> a0015 STATUS "INBOX/Drafts" (MESSAGES)
> < * BAD Syntax error: "DONE
> < A0015 STATUS "INBOX/DRAFTS" (MESSAGES)"
>
> And that's where the file stops.
>
> If I add "imap_idle=no" to my ~/.muttrc, the problem goes away.
>
> This is on MacOS X 10.4.3, so... it *should* have poll(). What might be
> going wrong here?
The poll call is actually a select call (and it works on my OS X.4.3
development system). I suppose it could fail depending on whether the
connection file descriptor is valid. This could be affected by the use
of $tunnel, SSL, SASL, or some mixture of those, and may also depend
on whether you're using gnutls or openssl. I've been using a raw
connection wrapped by SASL digest-md5.
But the failed poll should be fairly harmless - it should just disable
IDLE and go back to NOOP polls. It looks like binc is exhibiting the
same problem that dovecot does: it wants the DONE\r\n command and the
next IMAP command to be in two different TCP packets (it expects the
client to read the IDLE tagged response before continuing). This
shouldn't be required - the newline at the end of DONE should be
enough. Since the whole point of IDLE for me was to reduce round
trips, I don't want to add another one here. I guess you'll have to
disable imap_idle until binc gets fixed.
I've never seen an untagged BAD response either. I don't think that's
in the RFC.