MBOX-Line: From tss at iki.fi  Mon Oct 31 23:06:29 2011
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] BODY.PEEK[section]<origin.size> FETCH response
In-Reply-To: <CABa8R6vJGTa+VH-TOgXhCSpX5N1HZTBBqisDhPY9Metz5864JQ@mail.gmail.com>
References: <8F0DA5FA-FB07-4AFA-9C58-8F0927998343@ghoti.org>
	<alpine.OSX.2.00.1110301823210.9034@hsinghsing.panda.com>
	<CABa8R6uyrHJ6AqQoGfMcLztG-zovaVK4FEFep8ibpYc2-6b7ig@mail.gmail.com>
	<alpine.OSX.2.00.1110311352000.9034@hsinghsing.panda.com>
	<CABa8R6ugaAADsrvaS1Nnau5bi7k9728b+x00NcG1Nbxfk9xwsA@mail.gmail.com>
	<alpine.OSX.2.00.1110311455120.9034@hsinghsing.panda.com>
	<CABa8R6vJGTa+VH-TOgXhCSpX5N1HZTBBqisDhPY9Metz5864JQ@mail.gmail.com>
Message-ID: <D96D7BAA-894A-41DC-8349-752E737C7A3B@iki.fi>

On 1.11.2011, at 1.14, Brandon Long wrote:

> If we are violating guarantees that cause malfunctions, it would be
> good to know that.  The only one I know of is that under some
> circumstances, alpine wants some combination of the header + body to
> equal something, and due to our LF->CRLF shenanigans, that can be
> violated.  I'm not happy with it, but I have no good way to fix it,
> either.  Whether its an important guarantee, well, it hasn't seemed to
> have affected anyone who removed the check.

Dovecot also stores messages with LFs and has no trouble exporting them as if they were CRLFs. I think the only actual (performance) problem with it is .. well, actually the topic of this thread :) A partial fetch from a non-zero offset requires some scanning to find out the LF-only-offset. But luckily all clients just fetch the blocks in increasing order from zero offset, so this isn't such an important problem.


