On Tuesday, December 13 at 01:50 PM, quoth Brendan Cully:
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.
I don't use a tunnel either. I'm attaching the output of mutt -D. mutt -v says:
-USE_POP +USE_IMAP +USE_SMTP -USE_GSS -USE_SSL +USE_GNUTLS +USE_SASL I'd like to be able to use the IDLE feature... what's the next step to figuring out what's going on?
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).
I doubt it's being picky about which packets things are in -- bincimap runs via tcpserver (i.e. it doesn't have control over it's own connection).
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.
I'll send this along to the binc devel team and see if they have any idea what's up.
~Kyle --The longer I live the more I see that I am never wrong about anything, and that all the pains that I have so humbly taken to verify my notions have only wasted my time.
-- George Bernard Shaw
Attachment:
pgpTw1CvAgVRp.pgp
Description: PGP signature