Hi, On 03 Apr 2003 03:29:39 +0300, Timo Sirainen <[EMAIL PROTECTED]> wrote... > The way my server does it is that it accepts UIDs even for messages that > client hasn't been notified yet, but '*' in messagesets still refers to > the last notified message.
This behavior will cause more harm than good. It does sound reasonable; however, when the mailbox contains messages for which an exists notification has not been sent, sending a fetch response for such a message will cause your server to generate illegal protocol because the FETCH response will include the message number which in some cases will be greater than the previously reported EXISTS value. The server is never permitted to send FETCH responses for messages about which the client has not been notified. Likewise, it is an error for the client to be asking for them. It would be better to send the EXISTS and RECENT updates just before sending the FETCH response. A server should never generate bad protocol as a work around for a client problem. ## Initial condition C: a1 select inbox S: * 5 EXISTS S: * 0 RECENT S: * OK [UIDVALIDITY 1049334097] UID validity status S: * OK [UIDNEXT 50] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) S: * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags S: * OK [UNSEEN 1] first unseen message in INBOX S: a1 OK [READ-WRITE] SELECT completed ## Case 1 C: a2 UID FETCH 50 UID S: * 6 EXISTS S: * 1 RECENT S: * 6 FETCH (UID 50) S: a2 OK UID FETCH Completed ## Case 2 C: a2 UID FETCH 50 UID S: * 6 FETCH (UID 50) S: a2 OK UID FETCH completed ## Case 3 C: a2 UID FETCH 50 UID S: a2 OK UID FETCH completed You seem to be proposing a Case 2 scenario. The 6 in the Case 2 FETCH response is illegal because the client has not been told that there are at least 6 messages. It only knows about 5. --- Commentary --- >From the IMAP server's point of view a "client" is the remote connection end-point and not necessarily the program maintaining the end-point. We generally equate "IMAP client" with "some program" like Pine, OE or Eudora; however, that is not actually the case. A program which opens two connections to the IMAP server is maintaining two separate, independent and very distinct IMAP clients. The server has no way to know that any particular collection of connections have been somehow munged together into a single "client" by the program. The idea that a program can have a pool of client connections to the server is wrong. It is wrong because each client connection has a separate state which must be maintained independently of any other client connection state. Just because a program can create two client connections and select the same mailbox so that two client connection states happen to be very similar at some point in time doesn't somehow cause the client connections to become identical and thereby interchangable. The client connections still have separate states. Regards, Mark Keasling <[EMAIL PROTECTED]>
