[PATCH] Re: Avoid Fatal error: Word too long from Cyrus IMAP servers by chunking fetch.

[Nicolas Sebrecht]

The git log don't give more clue. So, let's ask John (cc'ed).

On Fri, Jan 21, 2011 at 10:56:28AM +0100, Sebastian Spaeth wrote:
> On Fri, 21 Jan 2011 10:03:24 +0100, Sebastian Spaeth <sebastian at sspaeth.de> wrote:
> > On Thu, 20 Jan 2011 18:06:03 -0500, "Edward Z. Yang" <ezyang at MIT.EDU> wrote:
> > > I'm personally very displeased with the X-OfflineIMAP header that is
> > > added :-P
> 
> And I wwas so much bothered by it, that I actually dug deeper in the
> code. It seems we add a random header, so that when we APPEND a new
> message to an imap server, we can later FETCH it to get the UID that the
> server assigned to it, right?
> 
> It is useless to argue about IMAPs stupid default API here, and inserting
> that header might still be needed in *some* cases. But in many , ie
> most, cases it might not, and would indeed doing so hurts our
> performance because we waste efforts.
> 
> RFC3214 (UIDPLUS exctension) defines a new reply APPENDUID as a response
> to an APPEND which gives back the UID without the need for more
> fudging. It's been introduced 2006 or so and most recent server releases
> seem to support UIDPLUS, so we should just be supporting this.
> 
> My mail providers' Courier certainly supports it. UWimap & dovecot seem
> to  support it too.
> 
> So, what we could do, is checking the imapobj.capabilities for "UIDPLUS"
> and if it contains that, we don't fudge headers but rely on the
> APPENDUID response.
> 
> Am I missing something obvious here? Do we need that header for a
> different purpose too?
> 
> Sebastian



-- 
Nicolas Sebrecht