MBOX-Line: From mrc+imap at panda.com  Sun Jun  5 18:24:50 2011
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:46 2018
Subject: [Imap-protocol] Where to start?
In-Reply-To: <4DEC1C93.24755.853F5AE5@David.Harris.pmail.gen.nz>
References: <4DEBB242.2090200@BusCom.net>,
	<201106051924.p55JOwpG003543@mxout12.cac.washington.edu>,
	<4DEBDFF5.9000301@BusCom.net>
	<4DEC1C93.24755.853F5AE5@David.Harris.pmail.gen.nz>
Message-ID: <alpine.OSX.2.00.1106051813140.809@hsinghsing.panda.com>

On Mon, 6 Jun 2011, David Harris wrote:
> the part that gave me the most trouble was partial fetches of
> arbitrary data: many clients will use this as a "chunking" mechanism,
> but it creates a serious state problem of what you keep between
> commands on the server side (imagine that you have a 20MB
> message and the client wants to retrieve a MIME sub-part from the
> middle of it 1K at a time: if you re-parse and re-extract the sub-part on
> each chunk, you'll absolutely kill your server's performance - you need
> to find some way of caching the sub-part so you can easily return
> subsequent requests for the next chunk).

Good point.  My server implementations (note the plural) keep offsets in
the internal representation of the BODYSTRUCTURE for each body part, even
though these are not reported to the client, for the specific purpose of
avoiding this problem.

> 3: Overall, IMAP part numbering was far and away the hardest thing I
> had to do with the protocol.

Are you prohibited from looking at existing code?  There is a really cute
recursive algorithm in my mtest testbed program that demonstrates the
proper way to do IMAP part numbering.

It's worth spending the time to understand IMAP part numbering.  It seems
ideosyncratic (as David says), but if you think through the issues you'll
see that it makes a great deal of sense.

It's not what you'd come up with at first to descend a MIME structure
tree.  But once you grasp it, you'll realize that it's cleaner and more
concise than the obvious one.

It does take a while though.  It took me a while, with several false
starts, to come up with it.

> From quietly reading this list for many years, I suspect the consensus
> you will get will probably be something along the lines of "all clients are
> poor choices", although I personally think that's a bit harsh. I'd test
> against the clients most likely to be used with your server and be ready
> to accommodate them as required (some accommodation is almost
> inevitable, unfortunately).

The client that is the best test of all is [al]pine.  It uses all of IMAP,
and if you have something wrong in how you do IMAP it will become obvious
pretty quickly.

It would be a very obscure server bug indeed which is not caught by
[al]pine yet caught by some other client.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

