67 lines
2.8 KiB
Plaintext
67 lines
2.8 KiB
Plaintext
MBOX-Line: From jonabbey at arlut.utexas.edu Fri Jun 7 23:10:48 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Jonathan Abbey <jonabbey@arlut.utexas.edu>
|
|
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: <20130608061048.GE3533@arlut.utexas.edu>
|
|
|
|
On Thu, 06 Jun 2013 15:15:32 -0500, Jan Kundr?t 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).
|
|
|
|
|
| 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...
|
|
|
|
Take a look at Panda IMAP at
|
|
|
|
http://github.com/jonabey/panda-imap
|
|
|
|
that repo includes the very last version of Mark Crispin's personal
|
|
fork of UW IMAP that he did after he was laid off from UW. I know he
|
|
fixed a lot of non-security related stuff in his code that was never
|
|
back-ported into UW IMAP.
|
|
|
|
If it turns out that the bug you're describing is still in this code,
|
|
I'd be happy to work on fixing it / accepting patches to fix it.
|
|
|
|
Thanks,
|
|
|
|
Jon
|
|
|
|
--
|
|
-------------------------------------------------------------------------------
|
|
Jonathan Abbey jonabbey@arlut.utexas.edu
|
|
Applied Research Laboratories The University of Texas at Austin
|
|
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg
|
|
-------------- next part --------------
|
|
A non-text attachment was scrubbed...
|
|
Name: not available
|
|
Type: application/pgp-signature
|
|
Size: 205 bytes
|
|
Desc: not available
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130608/3175e9e4/attachment.sig>
|