[Imap-protocol] Where to start?

David Harris David.Harris at pmail.gen.nz
Sun Jun 5 17:17:23 PDT 2011

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!


-- David --

------------------ David Harris -+- Pegasus Mail ----------------------
Box 5451, Dunedin, New Zealand | e-mail: David.Harris at 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."

More information about the Imap-protocol mailing list