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

On 5 Jun 2011 at 12:58, Lynn W. Taylor wrote:

> Search (#10) is the one that worries the most.  Some of that is the same 
> reason that COPY doesn't bother me.  Glad it can be left to last, and 
> wish it could be left out.

Lynn, first off, good luck with this. I admire your confidence and 
enthusiasm, but I suspect you will find the job quite a bit bigger than 
you expect. 

To me, IMAP seems as much a matter of mindset as it is of code - you 
*must* think in much the same the way the people who have written 
the IMAP RFCs over the years have thought, or you will inevitably fall 
afoul of details that might not at first glance be obvious - a good 
example, for instance, is that spaces are syntactically crucial 
throughout much of the IMAP command structure (especially in 
BODYSTRUCTURE): for many programmers accustomed to other 
environments, spaces are not much more than decoration, but you 
can't think this way in IMAP.

The absolute golden rule of IMAP is "read the BNF". It can be tortuous, 
but in over a decade of working with IMAP (and I do not consider 
myself in any way an expert or a model for others), I have never found 
a case where spending the time working my way through the BNF 
maze did not answer a syntactic question, however thorny it might 
have seemed.

Pete's list was a very, very good one - I found myself nodding in 
memory and agreement as I read through it. I won't labour the point by 
repeating things he has said, but I would make three observations:

1: He's absolutely right about the parser. If you don't have a robust, 
high-quality RFC2822 and RFC2045 (MIME) parser, you're shot before 
you start.

2: FETCH is full of traps, even if they don't appear to be traps at first 
glance: 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).

3: Overall, IMAP part numbering was far and away the hardest thing I 
had to do with the protocol. In my case, I had well-established parsing 
and message management and I had to shoe-horn IMAP's slightly 
idiosyncratic part numbering (I'm sure I'll get a lecture for that 
statement, but I'm allowed my opinions) into it. Because the part 
numbering is implied, not explicit, it's absolutely crucial that you 
understand how it works, and how your parsing engine is going to 
cope with it.

> I'm not in a position to specify clients.  I'll likely do my initial 
> testing with Thunderbird unless someone warns me that it's a poor choice.

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).

Good luck!

Cheers!

-- David --

------------------ David Harris -+- Pegasus Mail ----------------------
Box 5451, Dunedin, New Zealand | e-mail: David.Harris@pmail.gen.nz
           Phone: +64 3 453-6880 | Fax: +64 3 453-6612

Seen on the menu of a Swiss Restaurant:
   "Our wines leave you nothing to hope for."




