X-OfflineIMAP header was [Re: [PATCH] Avoid Fatal error...]

Philippe LeCavalier support at plecavalier.com
Fri Jan 21 12:39:16 GMT 2011


Don't mean to butt in. Just an attempt to keep the list sane.
Phil
On Fri, 2011-01-21 at 10:56 +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
> _______________________________________________
> OfflineIMAP-project mailing list
> OfflineIMAP-project at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/offlineimap-project
> 
> OfflineIMAP homepage: http://software.complete.org/offlineimap





More information about the OfflineIMAP-project mailing list