MBOX-Line: From brong at fastmail.fm  Sun Nov  6 13:31:24 2011
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] [noob] select & unseen?
In-Reply-To: <C61A1BDF-03DD-4ED9-BFCA-C6183F07DD3E@mac.com>
References: <C61A1BDF-03DD-4ED9-BFCA-C6183F07DD3E@mac.com>
Message-ID: <20111106213124.GA27889@brong.net>

On Sun, Nov 06, 2011 at 09:15:34PM +0100, Petite Abeille wrote:
> Given a mailbox containing only \Seen messages, what kind of UNSEEN response is SELECT supposed to return?
> 
> Looking at, say, dovecot implementation, it doesn't return any UNSEEN data if all messages are \Seen:
> 
> 	if (status.first_unseen_seq != 0) {
> 		client_send_line(client,
> 			t_strdup_printf("* OK [UNSEEN %u] First unseen.",
> 					status.first_unseen_seq));
> 	}

Cyrus does the same:

    if (state->firstnotseen)
	prot_printf(state->out, "* OK [UNSEEN %u] Ok\r\n",
		    state->firstnotseen);

> On the other hand, the spec for SELECT seems to mandate returning all the data: "the server MUST send the following untagged data".
> 
> What gives?

rfc3501:

         OK [UNSEEN <n>]
                     The message sequence number of the first unseen
                     message in the mailbox.  If this is missing, the
                     client can not make any assumptions about the first
                     unseen message in the mailbox, and needs to issue a
                     SEARCH command if it wants to find it.

Indeed.  Well, that's bloody useless.

   34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
   responses in SELECT and EXAMINE.  They are required now, but
   weren't in older versions.

   76) Clarify the mandatory nature of the SELECT data responses.

Ok - I think I've deciphered it.  You MUST NOT select mailboxes
unless they have unseen messages in them.  Problem solved.

Bron.

