Subject: New mail?

From: "Russ Atkind" <[email-masked]>
Date: Sun, 10 May 1998 19:43:08 -0400

I'm not sure if this is tread-upon ground, but lots of people seem to have
different ideas about what constitues new mail.

Mulberry:  It's new if it's \Recent AND \Unseen
Pine:      It's new if it's \Unseen
chkmail:   It's new if it's \Recent

Can anyone offer some thoughts on the relative merits and/or pointer(s) to
thoughts that have already been offered -- particularly when taking into
account situations that arise through multi-access?

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 May 1998 08:43:56 -0400 (Eastern Daylight Time)

On Sun, 10 May 1998 19:43:08 -0400 Russ Atkind 
<[email-masked]> wrote:

>...

The spec is, of course, painfully clear (section 4.4.4, page 
39): "NEW  Messages that have the \Recent flag set but not the 
\Seen flag.  This is functionally equivalent to '(RECENT 
UNSEEN)'" 

Of course, if an MUA decides to confuse its users with 
different uses of the same terminology, for any of historical 
reasons, a desire to lock people in, or plain perversity, that 
is its perogative.

    john

---

From: "Cyrus Daboo" <[email-masked]>
Date: Mon, 11 May 1998 10:50:13 -0400

> account situations that arise through multi-access?  

The biggest issue about how to handle these flags is to recognise that
\Recent is set for any new message that appears in a mailbox - including
ones that are added as a result of a COPY or APPEND operation. Thus if a
user copies a message they have read from their INBOX to another mailbox it
will appear as (\Recent \Seen), since the \Seen flag state is preserved
during the copy. Similarly, through protocol, the \Seen flag can be
explicitly set during the APPEND command if the client so desires. Thus its
reasonable to assume that 'newly delivered' mail will have only the \Recent
and not the \Seen flag. Thus we use a different visual marker/display style
for messages that are (\Recent) and (\Recent \Seen) or just (\Seen).

Of course things get more complicated in a shared environment, and this
crucially depends on how the server is setup to handle flags for multiple
users on the same mailbox. The \Recent flag should be per user (i.e. one
user opening a mailbox does not remove the \Recent flag for any other users
who might later do the same). The ACL extension allows for a bit to toggle
the per user state of the \Seen flag.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cyrus Daboo                                 <mailto:[email-masked]>
Cyrusoft International, Inc.                  <http://www.cyrusoft.com>
Voice: +1 412 605 0499                             Fax: +1 412 605 0705
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     Proud Purveyors of Mulberry: Internet Mail from the Ground Up
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Mark Crispin <[email-masked]>
Date: Mon, 11 May 1998 10:14:46 -0700 (PDT)

On Mon, 11 May 1998 08:43:56 -0400 (Eastern Daylight Time), John C Klensin
> \Seen flag.  This is functionally equivalent to '(RECENT

To play devil's advocate here:

The issue of whether a message is "new" or "not new" is a user interface
issue.  The definition of the "NEW" SEARCH criterion is based upon what the
author of the IMAP specification thinks is "new message status" (as opposed to
"recent message status" or "unseen message status") and does not necessarily
reflect what the designers of other user interfaces think.

One should be careful to infer user interface semantics from protocol tokens.
"NEW" is the same as "BLURDYBLOOP" -- it is something for another computer to
recognize.  Great evil has happened in inferring semantics from a protocol
token above and beyond that.

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 May 1998 15:58:26 -0400 (Eastern Daylight Time)

> token above and beyond that.

Full and complete agreement on this.  I was trying to suggest 
much the same thing in my closing comment in the earlier message.
If a mailbox can be access in an interleaved way by clients 
belong to different users, or even two different clients or 
client machines belonging to the same user, there is a huge 
potential for these flags deteriorating into near-uselessness.

My personal guess is that, as we gain experience with some of 
the combinations you and Barry point out, we will see clients 
that make local, extra-protocol, arrangements to deal with these 
issues in interesting ways and servers that offer special hooks 
for them.  If some of them work, they might even evolve into 
protocol extensions.

Interestingly, it was a variation on this issue that led me to 
ask the question about dates: in principle, if I can capture the 
arrival date-time (to adequately high precision) of the most 
recent message on a particular LIST or FETCH command, then an 
SEARCH AFTER-DATETIME facility (again, to adequately high 
precision) could be used to simulate "all messages received 
since the last message seen by _this_ client".  Sometimes, that 
is just what is wanted.   And, of course, sometimes it isn't.

   john