Re: [Imap-protocol] UW-IMAPD and its interpretation of ESEARCH
Alexey Melnikov <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[email protected]> |
On 6 Jun 2013, at 21:15, Jan Kundrát <[email protected]> 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 _______________________________________________ Imap-protocol mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol