36 lines
1.6 KiB
Plaintext
36 lines
1.6 KiB
Plaintext
MBOX-Line: From tss at iki.fi Wed Dec 7 01:55:24 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:47 2018
|
|
Subject: [Imap-protocol] [noob] notification of deleted/expunged messages?
|
|
In-Reply-To: <A891B744-87A2-42A5-9A02-81E212A9AB2E@mac.com>
|
|
References: <A891B744-87A2-42A5-9A02-81E212A9AB2E@mac.com>
|
|
Message-ID: <80779123-5707-46B5-80E9-F90412A013BD@iki.fi>
|
|
|
|
On 7.12.2011, at 11.27, Petite Abeille wrote:
|
|
|
|
> Now a new message arrives, shifting the content of the inbox by one from UID 82542-83541 to UID 82543-83542.
|
|
>
|
|
> How should the server notify the client?
|
|
>
|
|
> Would the following unilateral untagged notification be enough?
|
|
>
|
|
> s: * 1 expunge
|
|
> s: * 1000 exists
|
|
|
|
This is correct, but there are restrictions when you can send EXPUNGE notifications:
|
|
|
|
> An EXPUNGE response MUST NOT be sent when no command is in
|
|
> progress, nor while responding to a FETCH, STORE, or SEARCH
|
|
> command. This rule is necessary to prevent a loss of
|
|
> synchronization of message sequence numbers between client and
|
|
> server. A command is not "in progress" until the complete command
|
|
> has been received; in particular, a command is not "in progress"
|
|
> during the negotiation of command continuation.
|
|
>
|
|
> Note: UID FETCH, UID STORE, and UID SEARCH are different
|
|
> commands from FETCH, STORE, and SEARCH. An EXPUNGE
|
|
> response MAY be sent during a UID command.
|
|
|
|
So in these situations either you can't send a new 1000 EXISTS, or you must temporarily allow more than 1000 messages to be accessible.
|