35 lines
2.0 KiB
Plaintext
35 lines
2.0 KiB
Plaintext
MBOX-Line: From alexey.melnikov at isode.com Fri Jun 7 00:22:06 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Alexey Melnikov <alexey.melnikov@isode.com>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] UW-IMAPD and its interpretation of ESEARCH
|
|
In-Reply-To: <b046c657-52ae-4aae-98bd-3bd9e4937cce@flaska.net>
|
|
References: <b046c657-52ae-4aae-98bd-3bd9e4937cce@flaska.net>
|
|
Message-ID: <1945792A-24F7-4F88-ACCE-279167C04BA0@isode.com>
|
|
|
|
On 6 Jun 2013, at 21:15, Jan Kundr?t <jkt@flaska.net> wrote:
|
|
|
|
> Hi,
|
|
> one of my users has reported [1] that his IMAP server (UW-IMAPD, reporting as "2007e.404" in the initial greetings) is using the wrong [2] interpretation of the ESEARCH extension -- always reporting the UIDs as "min:max", effectively removing the huge benefit of that extension.
|
|
>
|
|
> What is the least damaging way to work around this? Here's a couple of ideas:
|
|
>
|
|
> a) Detect ESEARCH response passed as min:max. When the number of messages exceeds what EXISTS reports, blacklist the ESEARCH extension and try once again using plain SEARCH.
|
|
>
|
|
> b) Resort to ugly user-agent-sniffing-alike and blacklist ESEARCH preemptively when the initial greetings contains the "IMAP4rev1 2007e.404 at" string *and* the "SCAN" capability is present.
|
|
>
|
|
> 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.
|
|
|
|
> Is there some inherent drawback in -- at least temporarily -- going with b) that I might be missing? It's an obsolete, unmaintained server with not that great market share, so implementing extra workarounds just for it are not terribly high on my list of priorities...
|
|
>
|
|
> With kind regards,
|
|
> Jan
|
|
>
|
|
> [1] https://bugs.kde.org/show_bug.cgi?id=320828
|
|
> [2] http://www.ietf.org/mail-archive/web/imapext/current/msg00477.html
|
|
|
|
|