93 lines
4.0 KiB
Plaintext
93 lines
4.0 KiB
Plaintext
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."
|
|
|
|
|
|
|
|
|