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