30 lines
1.7 KiB
Plaintext
30 lines
1.7 KiB
Plaintext
MBOX-Line: From jkt at flaska.net Thu Jun 6 13:15:32 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] UW-IMAPD and its interpretation of ESEARCH
|
|
Message-ID: <b046c657-52ae-4aae-98bd-3bd9e4937cce@flaska.net>
|
|
|
|
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).
|
|
|
|
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
|
|
|
|
--
|
|
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
|
|
|