IMAP capabilities incorrectly assumed with IMAP proxy environment

[mbowie]

We run a number of IMAP servers behind some perdition proxy servers. Different IMAP backends have different CAPABILITY values depending on their specific application and in some cases IMAP distribution.

At the moment, RoundCube appears to take the CAPABILITY value as reported by the proxy when it connects, rather than the value reported by the backend server it's ultimately proxied to. As a result, users which were directed to a Cyrus IMAP backends were unable to create folders, since Cyrus was not detected by RC and thus the correct naming convention was not applied.

To work around this, we've temporarily added an additional perdition proxy which reports the same CAPABILITY list as the Cyrus servers in question, which resolves the issue.

Having not tried it in practice, I'd imagine that while the initial CAPABILITY is suitable for establishing that IMAP is available, a second CAPABILITY statement after LOGIN would ensure that the correct server is recognized.

[alec]

So, I think we need some 'imap_proxy' option to disable reading of initial capability response.

[mbowie]

Not knowing the IMAP4 RFC all that well, I think it depends on the purpose of checking CAPABILITY prior to LOGIN. If there's no harm in moving it to after login, then there's no need to add a directive.

On the other hand, if CAPABILITY before LOGIN is required, does it add too much overhead to call it twice? That would give a "Just Works(tm)" solution in both cases. Then again, perhaps there just aren't that many people using a setup of this nature.

Whatever form it takes, sounds like a great idea. ;-)

[alec]

The purpose of reading "greeting" capabilities is a performance. If you disable "greeting" capabilities on server side it will be readed after login. Dovecot has got such option.

[alec]

I've readed this again and I'm not sure how this should be fixed. Could you provide IMAP conversation listing from Roundcube with imap_debug=true (0.3-stable)?

[mbowie]

The transition to 0.3-stable is still on my action list; although I should get to in the next two weeks.

I'll certainly post the requested debug as soon as it's done.

[mbowie]

Rather embarrassing that it's taken me this long to get to, but here are my results.

Note that the behavior is actually determined by the CAPABILITY response sent at login... changing the string during the session does not have any effect.

These are the relevant logs/imap entries for each circumstance. My process was to login, go to "Settings" then "Folders" and add a folder named "Test"... as you'll see, it was successful if we munge the proxy's response or connect directly to a backend; but using the native proxy response, it fails to identify the naming structure.

Just to be reiterate, in this case we're unable to set the CAPABILITY override for our proxies in production since several of our backends support different capabilities and the proxy doesn't know which backend it will be connecting to until after the user authenticates.

Without the injected CAPABILITY string:

[21-Dec-2009 22:21:38 +0000]: S: * OK IMAP4 Ready hostname.tld 0001f30a
[21-Dec-2009 22:21:38 +0000]: C: cp01 CAPABILITY
[21-Dec-2009 22:21:38 +0000]: S: * CAPABILITY IMAP4 IMAP4REV1 STARTTLS
[21-Dec-2009 22:21:38 +0000]: S: cp01 OK CAPABILITY
[21-Dec-2009 22:21:38 +0000]: C: a001 LOGIN "foo" "bar"
[21-Dec-2009 22:21:38 +0000]: S: a001 OK You are so in
[21-Dec-2009 22:21:38 +0000]: C: c CREATE "Test"
[21-Dec-2009 22:21:38 +0000]: S: c NO Permission denied

With extended CAPABILITY string set:

[22-Dec-2009 13:21:53 +0000]: S: * OK IMAP4 Ready hostname.tld 000238c9
[22-Dec-2009 13:21:53 +0000]: C: cp01 CAPABILITY
[22-Dec-2009 13:21:53 +0000]: S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE URLAUTH
[22-Dec-2009 13:21:53 +0000]: S: cp01 OK CAPABILITY
[22-Dec-2009 13:21:53 +0000]: C: a001 LOGIN "foo" "bar"
[22-Dec-2009 13:21:53 +0000]: S: a001 OK You are so in
[22-Dec-2009 13:21:53 +0000]: C: c CREATE "INBOX.Test"
[22-Dec-2009 13:21:53 +0000]: S: c OK Completed
[22-Dec-2009 13:21:53 +0000]: C: sub1 SUBSCRIBE "INBOX.Test"
[22-Dec-2009 13:21:53 +0000]: S: sub1 OK Completed
[22-Dec-2009 13:21:53 +0000]: C: lmb LIST "INBOX." "*"

Direct to an internal IMAP backend:

[21-Dec-2009 22:42:19 +0000]: S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN SASL-IR] hostname.tld Cyrus IMAP v2.x.x server ready
[21-Dec-2009 22:42:19 +0000]: C: cp01 CAPABILITY
[21-Dec-2009 22:42:19 +0000]: S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE URLAUTH
[21-Dec-2009 22:42:19 +0000]: S: cp01 OK Completed
[21-Dec-2009 22:42:19 +0000]: C: a001 LOGIN "foo" "bar"
[21-Dec-2009 22:42:19 +0000]: S: a001 OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE URLAUTH] User logged in
[21-Dec-2009 22:42:19 +0000]: C: c CREATE "INBOX.Test"
[21-Dec-2009 22:42:19 +0000]: S: c OK Completed
[21-Dec-2009 22:42:19 +0000]: C: sub1 SUBSCRIBE "INBOX.Test"
[21-Dec-2009 22:42:19 +0000]: S: sub1 OK Completed
[21-Dec-2009 22:42:19 +0000]: C: lmb LIST "INBOX." "*"

[alec]

Added 'imap_force_caps' option in [d8c440c0].