Suppose that message of sequence number 1 is unseen.
The client issue the command:
C: tag fetch 1 body[]
and the server fetches the message but for some reasons
it can not flag the message as seen (e.g., rename of a file failes).
What should the server respond:
0. whatever, the server is
IMHO the following clarification
--- Mark Crispin [EMAIL PROTECTED] wrote:
A UID is NOT sent in the following cases:
unsolicited FETCH responses
should be explicitly stated in the next version
of the IMAP specification.
First, it is hard (at least for me) to infer this
rule from the
What should an IMAP server respond to the command
C: 123\r\n?
In my opinion an untagged BAD response is correct:
S: * BAD parsing error
and a tagged one is wrong:
S: 123 BAD parsing error.
Any comments?
Marcel
--
-
For
--- Rob Siemborski [EMAIL PROTECTED] wrote:
C1: a1 lock_the_selected_mailbox
S : a1 OK mailbox is yours
[snip]
C2, of course, wins in this case if it just gets and holds the mailbox
lock first. In fact, in this case C1 has *no* chance of ever deleting the
message if it loses the first
Thanks for prompt responses!
Marcel
Hi,
Assuming a mailbox having at least 2 messages,
and two IMAP clients selecting it, is the following
client(s)/server interaction correct or not? Can
someone point the errors?
c1: a store 1 +flags (\Deleted)
s : * 1 FETCH (FLAGS (\Deleted) UID 3)
s : a OK store
c2: aa store 2 +flags.silent
Hi everybody,
I have some questions regarding IMAP.
First, it seems that RFC 3501 is missing the definition of 'CHAR'.
More precisely, in RFC 2060 I found that
QUOTED_CHAR ::= any TEXT_CHAR except quoted_specials / \ quoted_specials
TEXT_CHAR ::= any CHAR except CR and LF
CHAR
