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

[Sebastian Spaeth]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110121/f8ff2c97/attachment-0001.sig>