39 lines
1.6 KiB
Plaintext
39 lines
1.6 KiB
Plaintext
MBOX-Line: From tss at iki.fi Tue Jun 16 13:12:43 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: <alpine.OSX.2.00.0906161258240.4967@hsinghsing.panda.com>
|
|
References: <1245181628.21624.808.camel@timo-desktop>
|
|
<alpine.OSX.2.00.0906161258240.4967@hsinghsing.panda.com>
|
|
Message-ID: <1245183163.21624.814.camel@timo-desktop>
|
|
|
|
On Tue, 2009-06-16 at 13:00 -0700, Mark Crispin wrote:
|
|
> On Tue, 16 Jun 2009, 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.
|
|
>
|
|
> I've done this for a long time with implicit capabilities.
|
|
|
|
You mean with those [CAPABILITY ..] response codes? But do you also
|
|
return reduced capabilities when replying to a CAPABILITY command before
|
|
login? That's the main change I'm hoping to make, because in some setups
|
|
the list of capabilities isn't known before knowing the username.
|
|
|
|
> > Note that in b) case it's sending untagged CAPABILITY reply. This seems
|
|
> > to help a lot of clients.
|
|
>
|
|
> I don't know if you care, but that would break an IMAP2 client.
|
|
> Hopefully, nobody is still using Pine 3.xx ...
|
|
|
|
I'd rather break Pine 3.xx than Thunderbird, Outlook and OE. :)
|
|
|
|
-------------- 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/20090616/b340482b/attachment.sig>
|