Re: [Imap-protocol] UW-IMAPD and its interpretation of ESEARCH

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
  [email protected]
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol