MBOX-Line: From brong at fastmail.fm  Mon Oct 31 23:31:40 2011
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] BODY.PEEK[section]<origin.size> FETCH response
In-Reply-To: <D96D7BAA-894A-41DC-8349-752E737C7A3B@iki.fi>
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>
	<D96D7BAA-894A-41DC-8349-752E737C7A3B@iki.fi>
Message-ID: <20111101063140.GA5353@brong.net>

On Tue, Nov 01, 2011 at 08:06:29AM +0200, Timo Sirainen wrote:
> 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.

How do you handle a message with a mix of LF and CRLF in the original?

Bron.

