[Dovecot] Dovecot 2.0.rc3 Capability response
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@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.
On 04.08.2010 12:25, Craig Whitmore wrote:
Timo will know better. Just want to say, that this sentence has been removed in RFC3501.
-- Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252 LAN Management System Developer http://lms.org.pl Roundcube Webmail Developer http://roundcube.net
"A.L.E.C" <alec@alec.pl> writes:
I agree this wording has quite explicitly been removed from RFC 3501.
Maybe Timo can point to some explicit wording which I have been unable to find but my reading of various bits of RFC 3501 (which btw obsoletes 2060 which in turn obsoletes 1730, i.e. 3501 is _the_ reference) seems to suggest that doing a CAPABILITY (or the moral equivalent of recognizing a CAPABILITY response) after both STARTTLS and AUTHENTICATE is in fact necessary. I don't see why it would be important to add these CAPABILITY responses unless the expectation is that the CAPABILITY response is now different as a result of the STARTTLS, AUTHENTICATE or indeed LOGIN.
The case seems clear for STARTTLS; you advertise only non-plaintext AUTH mechanisms and LOGINDISABLED initially and after successful STARTTLS you can advertise plaintext AUTH mechanisms and remove LOGINDISABLED. I must confess I am having trouble untangling the precise meaning of the text related to AUTHENTICATE though.
For reference some selected text from RFC 3501:
6.2.1. STARTTLS Command
[...]
Once [TLS] has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against man-in-
the-middle attacks which alter the capabilities list prior to
STARTTLS. The server MAY advertise different capabilities after
STARTTLS.[...]
6.2.2. AUTHENTICATE Command
[...]
A server MAY include a CAPABILITY response code in the tagged OK
response of a successful AUTHENTICATE command in order to send
capabilities automatically. It is unnecessary for a client to
send a separate CAPABILITY command if it recognizes these
automatic capabilities. This should only be done if a security
layer was not negotiated by the AUTHENTICATE command, because the
tagged OK response as part of an AUTHENTICATE command is not
protected by encryption/integrity checking. [SASL] requires the
client to re-issue a CAPABILITY command in this case.[...]
B. Changes from RFC 2060
[...]
Add optional CAPABILITY response code in the initial OK or PREAUTH.
Add note that server can send an untagged CAPABILITY command as part of the responses to AUTHENTICATE and LOGIN.
Remove statement about it being unnecessary to issue a CAPABILITY command more than once in a connection. That statement is no longer true.
[...]
- Clarify that an untagged CAPABILITY response to an AUTHENTICATE command should only be done if a security layer was not negotiated.
[...]
- Change recommendation of optional automatic capabilities in LOGIN and AUTHENTICATE to use the CAPABILITY response code in the tagged OK. This is more interoperable than an unsolicited untagged CAPABILITY response.
On Wed, 2010-08-04 at 14:04 +0100, pod wrote:
Yes.
Some auth mechanisms like GSSAPI and DIGEST-MD5 can add encryption/integrity protection to the stream. So in case of MITM attacks, the attacker could alter the CAPABILITY list before AUTHENTICATE, but not after it. I think RFC 3501 primarily talks about capability changing because of this.
RFC 3501 isn't fully clear that clients should update their capabilities when a CAPABILITY resp-code is sent on LOGIN, but this does strongly hint that:
Christian Affolter wrote:
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@iki.fi> wrote:
--
Best regards,
Charles
participants (6)
-
A.L.E.C
-
Charles Marcus
-
Christian Affolter
-
Craig Whitmore
-
pod
-
Timo Sirainen