Project

General

Profile

Bug #60148

fetch answer includes EXPUNGE messages

Added by Alex I almost 4 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Richard Hall
Category:
Scalix Server
Target version:
Start date:
12/01/2015
Due date:
01/13/2016
% Done:

100%

Estimated time:
Operation System:
noarch package

Description


a fetch 1:* (UID)
* 2 FETCH (UID 9)
* 1 EXPUNGE
* 2 EXPUNGE
* 2 EXPUNGE
* 1 EXISTS
a NO some of the requested messages no longer exist

problem: according to https://tools.ietf.org/html/rfc3501#section-7.4.1

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.
The update from the EXPUNGE response MUST be recorded by the
client.
also: https://tools.ietf.org/html/rfc3501#section-5.5

A non-obvious ambiguity occurs with commands that permit an untagged
EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
since an untagged EXPUNGE response can invalidate sequence numbers in
a subsequent command. This is not a problem for FETCH, STORE, or
SEARCH commands because servers are prohibited from sending EXPUNGE
responses while any of those commands are in progress. Therefore, if
the client sends any command other than FETCH, STORE, or SEARCH, it
MUST wait for the completion result response before sending a command
with message sequence numbers.

History

#1

Updated by Richard Hall almost 4 years ago

I thought this behaviour had been introduced at 12.5 with the changes to support the in-situ updating of calendar and contact properties using the X-UPDATE command, but it is present in previous releases (eg. old 11.4.6, and 12.1 releases).

Can be easily reproduced using 2 telnet sessions for the same user. selecting the same folder and deleting a msg in one session then fetching info using the second session:

Imap session #1:
----------------
* OK Scalix IMAP server 12.1.1.14700 ready on rho.uk.scalix.com
. login test1 passwd
. OK LOGIN completed, now connected to rho.uk.scalix.com
:
:
. fetch 1:* (flags uid)
* 1 FETCH (FLAGS ($MdnSent) UID 6)
* 2 FETCH (FLAGS ($MdnSent) UID 9)
. OK FETCH completed
. store 1 +flags.silent (\Seen \Deleted) 
. OK STORE completed
. expunge
* 1 EXPUNGE
* 1 EXISTS
. OK EXPUNGE completed

Imap session #2:
----------------
* OK Scalix IMAP server 12.1.1.14700 ready on rho.uk.scalix.com
. login test1 passwd
. OK LOGIN completed, now connected to rho.uk.scalix.com
:
:
. fetch 1:* (flags uid)
* 1 FETCH (FLAGS ($MdnSent) UID 6)
* 2 FETCH (FLAGS ($MdnSent) UID 9)
. OK FETCH completed
. fetch 1:* (flags uid)
* 1 FETCH (FLAGS (\Seen \Deleted $MdnSent) UID 6)
* 2 FETCH (FLAGS ($MdnSent) UID 9)
* 1 FETCH (FLAGS (\Seen \Deleted $MdnSent))                 <-- this also seems strange
. OK FETCH completed
. fetch 1:* (flags uid)
* 2 FETCH (FLAGS ($MdnSent) UID 9)                          <-- other session has expunged a msg at this point
* 1 EXPUNGE
* 1 EXISTS
. NO some of the requested messages no longer exist
#2

Updated by Richard Hall almost 4 years ago

  • Tracker changed from Bug internal to Bug
  • Due date set to 01/13/2016
  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Fix for 12.6 (Bluenose branch):

svn commit

Sending imap41/imap41_fetch.c
Transmitting file data .
Committed revision 14869.

Fix for trunk:

svn commit

Sending imap41/imap41_fetch.c
Transmitting file data .
Committed revision 14870.

#3

Updated by Danny T about 3 years ago

  • Assignee changed from ServerDevsGroup to Richard Hall

Also available in: Atom PDF