wasm-demo/demo/ermis-f/imap-protocol/cur/1600095089.22835.mbox:2,S

37 lines
1.5 KiB
Plaintext

MBOX-Line: From tss at iki.fi Wed Jun 17 09:55:10 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.0906170920380.6922@hsinghsing.panda.com>
References: <1245181628.21624.808.camel@timo-desktop>
<B4D8E3E4-A3B1-4F02-B2EA-7C2BE5A38AC2@sabahattin-gucukoglu.com>
<1245255382.21624.854.camel@timo-desktop>
<alpine.OSX.2.00.0906170920380.6922@hsinghsing.panda.com>
Message-ID: <1245257710.21624.873.camel@timo-desktop>
On Wed, 2009-06-17 at 09:36 -0700, Mark Crispin wrote:
> 2) After STARTTLS, the client MUST issue a CAPABILITY command. No form
> of automatic capabilities can be used.
Oh, this was something I had forgotten. I'll modify my workaround
slightly then:
If client issues CAPABILITY command before STARTTLS (i.e. ignored the
CAPABILITY response code in the untagged greeting OK), send untagged
CAPABILITY reply before tagged LOGIN/AUTHENTICATE reply, instead of
using CAPABILITY response code in the tagged reply.
> Put another way, any client that benefits from the workaround is broken.
Sure, but there's no way to get Outlook/OE fixed. At least Thunderbird
v3.0 will understand CAPABILITY response codes.
-------------- 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/e9ba9ba5/attachment.sig>