We are experiencing problems with expunge and message flags with
a certain email client when it performs a specific sequence of
operations with imapd.
The problem with expunge occurs when the email client chooses to
create a separate connection to imapd in addition to one already
existing and in an IDLE state. The second connection is used for
moving a message (from INBOX to a local mailbox) and marking the
message for deletion. The original connection is then used for
expunge.
i.e.
Connection 1: opened, ..., put in IDLE state
Connection 2: opened, message moved from the INBOX to a local
mailbox, message marked for deletion, closed
Connection 1: taken out of IDLE state, messages expunged, ...
The message expunge has no effect and, so far as we can tell,
the reason is that the file size (of INBOX) does not change when
the message is marked for deletion (setting the deleted flag
increases the file size by 1 byte, but this is compensated by
a reduction of one blank space in the X-Keywords line due to a
change in padding). Therefore, the connection doing the expunge
does not know about the flag change, and assumes no changes were
made to the (INBOX) file.
The (related) problem with the message flags occurs if message
flags were changed prior to moving the message (e.g. if a 'recent'
message becomes 'seen' during Connection 1). In that case, the
file will be rewritten after the expunge (by Connection 1),
overwriting the flags set by the message move (Connection 2).
This situation does not occur when a single connection is used
to read, mark for delete, and expunge messages since the internal
state information of that connection is always used to rewrite
the file.
We are running imapd (2002.332) on Windows, and using traditional
UNIX mailbox format for INBOX and would appreciate any
recommendations on how to best handle this situation in imapd.
Forcibly re-parsing the mailbox (INBOX) would probably work,
but I imagine there is a very good reason for the file size check
(optimization) and do not want to break it.
TIA
--
Carl Stehle
--
------------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------
