43 lines
2.0 KiB
Plaintext
43 lines
2.0 KiB
Plaintext
MBOX-Line: From tss at iki.fi Wed Jun 17 09:16:22 2009
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:42 2018
|
|
Subject: [Imap-protocol] Changing capabilities
|
|
In-Reply-To: <B4D8E3E4-A3B1-4F02-B2EA-7C2BE5A38AC2@sabahattin-gucukoglu.com>
|
|
References: <1245181628.21624.808.camel@timo-desktop>
|
|
<B4D8E3E4-A3B1-4F02-B2EA-7C2BE5A38AC2@sabahattin-gucukoglu.com>
|
|
Message-ID: <1245255382.21624.854.camel@timo-desktop>
|
|
|
|
On Wed, 2009-06-17 at 09:30 +0100, Sabahattin Gucukoglu wrote:
|
|
> On 16 Jun 2009, at 20:47, Timo Sirainen wrote:
|
|
> > Has anyone tested how well clients support catching capabilities after
|
|
> > login? I was planning on having Dovecot v2.0 send only very minimal
|
|
> > capabilities before login.
|
|
>
|
|
> Is it standard behaviour to even expect clients to understand
|
|
> capabilities in untagged responses at all? (Or has this just become
|
|
> unspoken convention somehow?)
|
|
|
|
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.
|
|
|
|
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.
|
|
-------------- next part --------------
|
|
A non-text attachment was scrubbed...
|
|
Name: signature.asc
|
|
Type: application/pgp-signature
|
|
Size: 204 bytes
|
|
Desc: This is a digitally signed message part
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20090617/98e1bf7c/attachment.sig>
|