K-9 expects the IMAP Server to present IDLE upon connection rather than verifying its capabilities after login. If it can not detect IDLE in the initial greeting it will disable the push mode.

This was tested with the latest Dovecot build and discussed with the author here:

http://www.dovecot.org/list/dovecot/2010-February/046991.html

Tested on K-9 2.403

And the important part is that the updated capabilities are pushed to client automatically. Here's an example session:

• OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=DIGEST-MD5] Dovecot ready. x login user pass x OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA] Logged in

Some other newer servers also behave in a similar way.

I'm working on implementing this change. However, the behavior of Dovecot v2.0 Beta differs from that described above. The updated capabilities are being returned in an UNTAGGED response to the LOGIN command, not the TAGGED response. This is very easy to handle. However, Dovecot 1.2 returns updated capabilities in the TAGGED OK response to the LOGIN command, which is a little harder to handle. From the RFC: A server MAY send capabilities automatically, by using the CAPABILITY response code in the initial PREAUTH or OK responses, and by sending an updated CAPABILITY response code in the tagged OK response as part of a successful authentication. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities. From that text, it appears the Dovecot 2.0 implementation is incorrect. The untagged CAPABILITY response should not be sent in response to the LOGIN command.

I guess in that test you sent a CAPABILITY command before authentication? That's Dovecot's workaround to force some other clients to understand the updated capability (such as Outlook, so that workaround can't really go anywhere). If you don't send CAPABILITY command, it works as shown above. If you send CAPABILITY, Dovecot assumes your client doesn't understand CAPABILITY resp-code and then it sends the untagged CAPABILITY instead.

Anyway I don't really see why a client couldn't update its capabilities any time it sees one of:

• CAPABILITY ..
• OK [CAPABILITY ..] tag OK [CAPABILITY ..]

Yes, K-9 is sending CAPABILITY before authentication, in order to test for STARTTLS capability. (Old code I didn't write.)

In fact, I am just now coding as you suggest, which is fine with me. However, perhaps you should send the updated capabilities in the TAGGED OK response to LOGIN. I'm concerned that other clients may not handle the UNTAGGED response to LOGIN.

Actually, I'm not sure when the second one would be sent: * OK [CAPABILITY] which I'm interpreting as an untagged OK with a capability list. I wasn't planning on handling that possibility, but I guess I can.

Oh, I see. It is sent in response to the initial connection.

If you also handle the * OK [CAPABILITY] in banner, you save one round trip by not having to send CAPABILITY command and wait for its reply. Then you'll also get the expected tagged login response from Dovecot.

Perhaps Dovecot should send both * CAPABILITY and tagged OK [CAPABILITY] in the workaround-mode, but I think I'll delay making that change until I find a client for which it's really needed.

Thanks, Timo, for your help. I will code K-9 to handle the capabilities in the banner to save the round trip, fall back on sending CAPABILITY if I don't get them in the banner, and handle the updated capabilities in the LOGIN response in either tagged or untagged responses. That will hopefully handle all cases!

This issue was closed by revision r1484.

r1484 | danapple0 | 2010-02-27 11:34:38 -0600 (Sat, 27 Feb 2010) | 17 lines Changed paths: M /k9mail/trunk/src/com/fsck/k9/mail/store/ImapStore.java

Fixes Issue 1252

Handle CAPABILITY response in following cases: 1) When sent as part of the banner, no longer sends explicit CAPABILITY command

2) When sent as an UNTAGGED response to LOGIN, updates stored capabilities.

3) When sent as part of the TAGGED response to LOGIN, updates stored capabilities.

Due to odd implementation of the CRAM-MD5 authentication, the capability updates will not happen as part of the CRAM-MD5 authentication.