60 lines
2.5 KiB
Plaintext
60 lines
2.5 KiB
Plaintext
MBOX-Line: From MRC at CAC.Washington.EDU Thu Aug 31 17:45:42 2006
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <MRC@CAC.Washington.EDU>
|
|
Date: Fri Jun 8 12:34:37 2018
|
|
Subject: [Imap-protocol] changed capabilities after login
|
|
In-Reply-To: <20060901002118.GB16606@ventoux.cs.ubc.ca>
|
|
References: <20060901002118.GB16606@ventoux.cs.ubc.ca>
|
|
Message-ID: <Pine.WNT.4.65.0608311723400.2392@Tomobiki-Cho.CAC.Washington.EDU>
|
|
|
|
On Thu, 31 Aug 2006, Brendan Cully wrote:
|
|
> Is it kosher for the server to silently drop support for a
|
|
> previously-advertised capability?
|
|
|
|
The short answer is yes.
|
|
|
|
Longer answer:
|
|
|
|
Although RFC 3501 doesn't go out and say so directly, a client should
|
|
obtain a new capability list after a successful authentication as well as
|
|
after a successful TLS negotiation.
|
|
|
|
One reason is that a server may choose, in Not Authenticated state, not to
|
|
disclose capabilities which are only of use in Authenticated state.
|
|
|
|
For example, prior to authentication UW imapd auto-announces only those
|
|
capabilities which are useful in Not Authenticates state, and after
|
|
authentication auto-announces only those capabilities which are useful in
|
|
Authenticated and Selected states. The only common capabilities in these
|
|
two sets are IMAP4REV1 and LITERAL+.
|
|
|
|
The untagged CAPABILITY response to a CAPABILITY command always announces
|
|
all capabilities in UW imapd. Mirapoint, on the other hand, seems to
|
|
suppress inappropriate capabilities.
|
|
|
|
Another reason is that there may be differential capabilities depending
|
|
upon the userid that authenticated. Anonymous is an obvious example of a
|
|
userid that may have more limited capabilities than other userids.
|
|
|
|
I sympathize with the desire to reduce RTTs; that's why I added
|
|
auto-announce when I observed that STARTTLS resulted in three RTTs just
|
|
for CAPABILITY. With auto-announce, only one CAPABILITY command is needed
|
|
(after the STARTTLS). However, in the case you mentioned, I don't see how
|
|
it can be avoided; the Mirapoint server doesn't auto-announce.
|
|
|
|
The Mirapoint server has one strange behavior; it only announces
|
|
LOGIN-REFERRALS after authentication. Since that's only useful prior to
|
|
authentication, it seems a bit strange.
|
|
|
|
The Mirapoint server could also avoid the "revoked capability" problem by
|
|
not advertising ACL until after authentication. However, that would still
|
|
cause a problem for your client if it does not re-issue the CAPABILITY
|
|
command after authentication.
|
|
|
|
-- Mark --
|
|
|
|
http://staff.washington.edu/mrc
|
|
Science does not emerge from voting, party politics, or public debate.
|
|
Si vis pacem, para bellum.
|
|
|