Subject: message state preservation in COPY and APPEND operations

From: Mark Crispin <[email-masked]>
Date: Sun, 11 Jul 1993 14:20:40 -0700 (PDT)

BACKGROUND:

The issue of message state (flags) preservation in COPY and APPEND operations
has come up again.  This also relates to the behavior of c-client's
mail_copy(), mail_move(), and mail_append() operations.

The problem is that when messages are copied into a mailbox by one of these
operations, their external state is not preserved.  That is, their internal
date, user flags (a.k.a. keywords), and system flags (deleted, seen, answered,
and flagged) are not preserved.

In general, what happens is that the copy receives the current date/time as
the internal date, and all NIL user and system flags.  In the past, some early
versions of c-client made some attempt at preservation, although this has
pretty much been eliminated in the name of consistency.  An egregious
exception is that a copy/move (but not an append) of a message in the bezerk
(/usr/spool/mail) format preserves the original date of the message as an
implementation artifact.

Arguably, this behavior is justified; the copy of the message is a separate
instance of the message, and the state could be thought of as being associated
with the instance instead of with the message.  For example, you can define
the internal date as being ``when the message was placed in this mailbox'' as
opposed to ``when the user received this message''.

However, to end users of applications such as Pine, the loss of seen status
when a message is copied from one folder to another is a bug.

PROBLEMS WITH PRESERVING STATUS:

In the case of user flags (keywords), in c-client they are only implemented in
the tenex (mail.txt) format, and as implemented are represented as one of 30
binary states whose interpretation as a flag name is per-user and possibly
per-mailbox.

In the case of system flags, there is no clear concensus of what is ``right''
and what is not.  Generally, the idea of flag preservation has revolved around
the seen flag.  The answered flag is another candidate for preservation, the
flagged (urgent) less so.  Generally the deleted flag is felt *not* to be a
candidate for preservation.

A more serious problem is that there is no mechanism at all for preserving or
transmitting flags or internal dates via an IMAP APPEND operation.

POINTS TO PONDER:

Should c-client attempt to preserve message status when copying messages to
other folders?

If so, what do we do about nasty things such as keywords (which may not make
any sense in the target mailbox) and possible ``should not preserve'' flags
such as deleted?  Can we explain what gets preserved and what does not get
preserved in a fashion that mere mortals can understand?  [Remember, the
current definition is more or less ``never preserved''].

How do we solve the APPEND problem?  It seems that perhaps there needs to be a
new form of APPEND that includes internal date and flags arguments.  Is this
worth doing, considering the interoperability costs it would entail?

Discussion solicited.

-- Mark --

---

From: John Gardiner Myers <[email-masked]>
Date: Sun, 11 Jul 1993 21:09:21 -0400 (EDT)

INTERNALDATE should most definitely *not* be preserved.  Any
implementation which does so violates RFC 1176, which explictly
defines it as "the date and time the message was written to the
mailbox."

As for preserving flags, the implementation should either preserve all
flags it can (except \RECENT, which is magic) or none.  I see no
reason to make \DELETED a special case.  We shouldn't try to
second-guess what the user really wants.

A client could probably follow an APPEND with a SELECT/SEARCH/STORE
FLAGS in order to transmit flags.  Problems with this approach include
a window where the default flags are visible, difficulty in finding
the right message, and interaction with /RECENT.

-- 
_.John G. Myers		Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 11 Jul 1993 22:59:43 -0700 (PDT)

Yes, and the fact that the mailbox the message is being appened to is
probably not even open for the flag setting operation.  For some
implementations were memory is in short supply, the cost of opening
another mailbox would make doing this problematic. 

I think one of the important questions is how many implementations would 
break if APPEND was changed, or replaced with a different one. 

LL