72 lines
3.0 KiB
Plaintext
72 lines
3.0 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Fri Jun 7 23:39:00 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] UW-IMAPD and its interpretation of ESEARCH
|
|
In-Reply-To: <20130608061048.GE3533@arlut.utexas.edu>
|
|
References: <b046c657-52ae-4aae-98bd-3bd9e4937cce@flaska.net>
|
|
<20130608061048.GE3533@arlut.utexas.edu>
|
|
Message-ID: <1370673540.28336.140661241407785.7767A035@webmail.messagingengine.com>
|
|
|
|
On Sat, Jun 8, 2013, at 04:10 PM, Jonathan Abbey wrote:
|
|
> 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.
|
|
|
|
I think in Jan's case as a client author, there's often a limited amount
|
|
that you can do to get servers fixed. Sure this path will lead to the
|
|
bugfixes appearing sometime in the next 2-3 years once it gets accepted
|
|
upstream, packaged by distributions, and finally slipstreamed onto
|
|
everyone's servers in the next round of stable updates.
|
|
|
|
Even as a server author, you wouldn't believe the resistance to updates.
|
|
"it's not in Debian stable, we're not using it". So plenty of my 2 year
|
|
old Cyrus bugs are still out there in the real world. Unless it's a
|
|
security issue, good luck getting it fixed quickly.
|
|
|
|
Hence: workarounds.
|
|
|
|
Bron.
|
|
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|