31 lines
1.3 KiB
Plaintext
31 lines
1.3 KiB
Plaintext
MBOX-Line: From dave at cridland.net Fri Jun 7 01:01:09 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Dave Cridland <dave@cridland.net>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] UW-IMAPD and its interpretation of ESEARCH
|
|
In-Reply-To: <1945792A-24F7-4F88-ACCE-279167C04BA0@isode.com>
|
|
References: <b046c657-52ae-4aae-98bd-3bd9e4937cce@flaska.net>
|
|
<1945792A-24F7-4F88-ACCE-279167C04BA0@isode.com>
|
|
Message-ID: <CAKHUCzwy3dS2Z8S2TgdCF-SCqE0wyTB7OwbY9uWa9P_3tHk6eQ@mail.gmail.com>
|
|
|
|
On Fri, Jun 7, 2013 at 8:22 AM, Alexey Melnikov
|
|
<alexey.melnikov@isode.com>wrote:
|
|
|
|
> On 6 Jun 2013, at 21:15, Jan Kundr?t <jkt@flaska.net> wrote:
|
|
> > The option b) looks like a reasonable stopgap measure with a very
|
|
> limited potential for false positives. It is also implementable very
|
|
> quickly within my client. The option a) will require a bit more work, but
|
|
> it looks like something more "robust" than b).
|
|
>
|
|
> Option a) looks quite unreliable (and dangerous) to me.
|
|
> I hope newer versions of UW don't suffer from this.
|
|
>
|
|
>
|
|
Yes, go for (b); it's what I'd do. (In fact, Inky possible already does
|
|
this).
|
|
|
|
I might see if I can knock out an RFC 4731 bis which clarifies this.
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130607/dd8a8f15/attachment.html>
|