wasm-demo/demo/ermis-f/imap-protocol/cur/1600095025.22671.mbox:2,S

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>