On Mon, 01 Jul 2002 10:03:38 -0700, Mike Oliver wrote:
> When I see the last
> four of a chunk equal to crlf + crlf or "--" + crlf, I assume the message
> is ended and parse the message into an object and store it and I send a
> tag SP OK APPEND Completed
> otherwise I send another "+ Ready" and another chunk comes down.
This is completely wrong.
The client will tell you *exactly* how many octets it will send in the literal
in the APPEND command. For example, in the command:
tag APPEND blurdybloop {2314}
there are 2314 octets in the message. You must send "+ Ready" and then read
*exactly* 2314 octets (no more, no less), then you must send "tag OK done".
> Netscape appears to concatenate another command at the end of the message
> chunk
> tag select "parent path" for the parent where the message is
> intended...
Netscape is merely sending another command without waiting for the OK. It is
allowed to do this. IMAP is asynchronous except in the cases where it would
result in an ambiguity.
> So do I need to parse the first chunk for header lines and pull out the
> boundary string and detect that as well?
No. What appears in the message is totally irrelevant. You must read
literals correctly -- by that, I mean you must use the size count and read
exactly that many octets.
Looking inside the message text for MIME context is not only more complicated
and (as you've discovered) quite unreliable, it is also a terrible layering
violation. At the IMAP level, it doesn't know MIME from a dime or slime or
crime.
What you're doing is even worse, since you are assuming there is no nested
MIME content. Take a look at
ftp://ftp.cac.washington.edu/mail/mime/torture-test.mbox
After you shudder in horror (it *is* a perverse torture of MIME), do what
needs to be done in order to make your server handle it.
