"A.L.E.C" alec@alec.pl writes:
On 04.08.2010 12:25, Craig Whitmore wrote:
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
Timo will know better. Just want to say, that this sentence has been removed in RFC3501.
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.