[Dovecot] Dovecot 2.0.rc3 Capability response

[pod]

"A.L.E.C" <alec at 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

[...]

   77) Add optional CAPABILITY response code in the initial OK or
   PREAUTH.

   78) Add note that server can send an untagged CAPABILITY command as
   part of the responses to AUTHENTICATE and LOGIN.

   79) Remove statement about it being unnecessary to issue a CAPABILITY
   command more than once in a connection.  That statement is no longer
   true.

[...]

   83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
   command should only be done if a security layer was not negotiated.

[...]

   91) 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.