MBOX-Line: From mrc+uw at panda.com  Wed Jun 17 09:36:54 2009
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+uw@panda.com>
Date: Fri Jun  8 12:34:42 2018
Subject: [Imap-protocol] Changing capabilities
In-Reply-To: <1245255382.21624.854.camel@timo-desktop>
References: <1245181628.21624.808.camel@timo-desktop>
	<B4D8E3E4-A3B1-4F02-B2EA-7C2BE5A38AC2@sabahattin-gucukoglu.com>
	<1245255382.21624.854.camel@timo-desktop>
Message-ID: <alpine.OSX.2.00.0906170920380.6922@hsinghsing.panda.com>

On Wed, 17 Jun 2009, Timo Sirainen wrote:
> Well, RFC 3501 mentions automatically sent capabilities in a few places,
> like:
>> A server MAY send capabilities automatically, by using the
>>       CAPABILITY response code in the initial PREAUTH or OK responses,
>>       and by sending an updated CAPABILITY response code in the tagged
>>       OK response as part of a successful authentication.  It is
>>       unnecessary for a client to send a separate CAPABILITY command if
>>       it recognizes these automatic capabilities.

Note that it says "CAPABILITY response code", not "untagged CAPABILITY 
response"

> So I guess it's preferred to send CAPABILITY response code in response
> codes instead of untagged CAPABILITY, and this is also what Dovecot does
> as long as client doesn't ignore them by requesting the CAPABILITY
> again. The untagged CAPABILITY sending is only a workaround to many
> commonly used clients.

UW IMAP once sent automatic untagged CAPABILITY responses, and I had 
complaints of numerous clients puking over it.  Some were IMAP2 (and thus 
this was expected), but others were supposedly IMAP4 capable.

It was for this reason that the CAPABILITY response code came into being.

This was 10 or so years ago.  The clients which had problems may be 
extinct by now.

RFC 3501 requires that a client get new capabilities after STARTTLS (page 
27), and strongly indicates that also be done after AUTHENTICATE (page 29) 
and LOGIN (page 31).  SASL requires that a client get new capabilities 
after an AUTHENTICATE command that negotiates a security layer.

What this all means:
  1) The client must acquire capabilities at:
     . session start
     . after the tagged OK for a STARTTLS command
     . after the tagged OK for an AUTHENTICATE command that negotiates a
       security layer
     . at or after the tagged OK for an AUTHENTICATE command that does not
       negotiate a security layer
     . at or after the tagged OK for a LOGIN command
  2) After STARTTLS, the client MUST issue a CAPABILITY command.  No form
     of automatic capabilities can be used.
  3) After AUTHENTICATE that negotiates a security layer, the client MUST
     issue a CAPABILITY command.  No form of automatic capabilities can be
     used.
  4) If the server includes a CAPABILITY response code in the initial
     untagged OK or PREAUTH greeting, or in the tagged OK from an
     AUTHENTICATE command (that does NOT negotiate a security layer) or
     LOGIN command, the client can use those capabilities and not need to
     issue a CAPABILITY command.

Put another way, any client that benefits from the workaround is broken.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

