Hi I have a question regarding the IMAP CAPABILITY command behavior of Dovecot 2.0.rc3. While connecting to a Dovecot 1.2.4 server and requesting the supported capabilities, Dovecot returns all capabilities: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready. a1 CAPABILITY * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH ACL RIGHTS=texk QUOTA AUTH=PLAIN AUTH=CRAM-MD5 a1 OK Capability completed. Doing the same on 2.0.rc3, will return only a limited set of supported capabilities: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready. a1 CAPABILITY * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN a1 OK Capability completed. However after a user has logged in, Dovecot 2.0.rc3 returns all supported capabilities: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready. a1 login user at example.com pass a1 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 ACL RIGHTS=texk] Logged in a2 CAPABILITY * 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 ACL RIGHTS=texk a2 OK Capability completed So what's the idea behind the change of this behavior? Is it planned to support different capabilities per user in the future? The reason behind my question is, that the Open-Xchange IMAP client implementation relies on the presence of the ACL capability presented before the actual login took place. Thanks for any clarifications. Regards Christian
> > Doing the same on 2.0.rc3, will return only a limited set of supported > capabilities:Looking at the RFC.. and if dovecot is doing this then its going against the RFC and doing it wrong. As it says "This listing of capabilities is not dependent upon connection state or user." http://tools.ietf.org/search/rfc1730#section-6.1.1 http://tools.ietf.org/search/rfc2060#section-6.1.1 The CAPABILITY command requests a listing of capabilities that the server supports. The server MUST send a single untagged CAPABILITY response with "IMAP4" as the first listed capability before the (tagged) OK response. This listing of capabilities is not dependent upon connection state or user. It is therefore not necessary to issue a CAPABILITY command more than once in a session.> > So what's the idea behind the change of this behavior? Is it planned to > support different capabilities per user in the future? > > The reason behind my question is, that the Open-Xchange IMAP client > implementation relies on the presence of the ACL capability presented > before the actual login took place. > > Thanks for any clarifications. > > Regards > Christian > >
Christian Affolter wrote:> Hi > > I have a question regarding the IMAP CAPABILITY command behavior of > Dovecot 2.0.rc3. > > While connecting to a Dovecot 1.2.4 server and requesting the supported > capabilities, Dovecot returns all capabilities:Timo's last response to this - and there have been a few others since this changes made (yes, it was intentional, and yes, per user capabilities are a future possibility): On 2010-04-07 9:38 PM, Timo Sirainen <tss at iki.fi> wrote:> This is pretty much intentional, because v1.x used to do horrible > horrible things to get the capability line. I was hoping to avoid that > in v2.0. This works for the most commonly used IMAP clients, so I don't > think I'm going to change this. It's time to get the clients fixed > instead. :) Besides, it's possible to support per-user capabilities, and > presenting capabilities before login makes this impossible. > > Dovecot v2.0 presents capabilities in two possible ways, depending on if > client sent a CAPABILITY command: > > a) the right way (use CAPABILITY imap resp code): > > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] 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] Logged in > > b) the wrong way (use untagged CAPABILITY), which is required to make it > work with Outlook etc.: > > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready. > a capability > * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN > a OK Capability completed. > b login user pass > * 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 > b OK Logged in-- Best regards, Charles